Сценарии использования, которые можно оценить

Выберите одну повторяемую задачу и соберите небольшой набор репрезентативных входных данных, включая неоднозначные запросы и случаи с отсутствующей информацией. Определите, кто проверяет выходные данные и что делает ответ приемлемым.

Используйте эти сценарии для определения своих собственных критериев приемки. Прочтите как это работает, ознакомьтесь с FAQ и просмотрите обработку данных перед вводом чувствительных материалов. Проверьте статус сервиса перед запуском рабочей нагрузки.

Доступ к ИИ требует входа в систему, одного подтвержденного пополнения на сумму не менее USD 100, авторизованного API-ключа и достаточного доступного кредита для запроса. Каждое последующее пополнение также имеет минимум USD 100; меньшие остатки остаются пригодными для использования, если они покрывают запрос. Для кредита требуется проверка транзакции. Проверьте статус сервиса на доступность моделей перед отправкой трафика.

Для службы поддержки или внутренней справочной службы предоставьте утвержденные факты, недавний разговор и четкий стиль написания; полезным результатом будет ответ, который можно проверить.

Если в мастер-классе указаны часы приема со вторника по пятницу, а клиент спрашивает о воскресенье, ответ должен объяснить, что воскресенье не входит в указанные часы, и рекомендовать подтвердить доступность. Не следует обещать запись на прием.

Проверка качества: проверяйте каждое фактическое утверждение, сохраняйте соответствующий контекст разговора и отмечайте недостающую информацию. Отправку сообщений и бронирование оставляйте за своим этапом проверки. Начните с рецепта чат-бота и руководства по Open WebUI, затем проверьте выбранное развертывание перед использованием.

Для помощника по инвентаризации предоставьте соответствующий код, задачу и допустимые определения инструментов. Запросите уровень запасов для SKU keyboard и проверьте, как приложение обрабатывает отсутствующий SKU.

Ожидаемое поведение: предложите допустимый вызов get_stock с проверенными аргументами, используйте возвращенные данные в ответе и объясните проверку отсутствующих входных данных. Ваше приложение решает, выполняется ли вызов; требуйте проверки разрешений и явного просмотра перед изменениями файлов, командами или внешними действиями.

Проверка качества: отклоняйте неизвестные инструменты, неожиданные аргументы и неавторизованные действия, а также тестируйте отсутствующие или некорректные входные данные. Следуйте рецепту ограниченного инструмента и конфигурации Cline; проверьте возможности развертывания перед включением инструментов.

Для внутреннего помощника по знаниям ваше приложение предоставляет коллекцию документов и поисковую систему, затем передает выбранные отрывки со стабильными идентификаторами источников модели. WeightsAPI в настоящее время не предоставляет эмбеддинги; рецепт RAG использует простой пример лексического ранжирования.

Если источник S1 требует одобрения менеджера, а источник S2 говорит, что срочные запросы проходят тот же процесс, ответ о срочном доступе должен ссылаться на оба источника и сохранять требование одобрения. Он не должен выдумывать срок одобрения.

Проверка качества: подтвердите, что соответствующие отрывки были извлечены, каждая ссылка подтверждает свое утверждение, а отсутствие доказательств приводит к явному ограничению. Обеспечьте соблюдение прав доступа к документам на уровне поискового слоя и тестируйте вопросы, на которые коллекция не может ответить.

Используйте доступное развертывание для сравнения моделей-кандидатов с одинаковыми входными данными и сопоставимыми настройками. Оценивайте фактическую точность, следование инструкциям, цитирование и допустимые аргументы инструментов; записывайте входные и выходные токены вместе со временем до первого токена и временем завершения.

Используйте текущую таблицу цен с фактическим использованием, включая повторяющийся контекст и повторные попытки. Установите бюджеты ключей, ограничьте количество повторных попыток и сохраните путь отката. Переключайте трафик только после прохождения ваших собственных критериев приемки.