ТЗ на AI-ассистента: источники, границы ответов и оценка качества

Чего нельзя оставлять за словом «умный»

AI-ассистент может искать ответ в базе знаний, помогать сотруднику составить черновик или выполнять действие во внешней системе. Эти режимы различаются по риску. Ошибка в подсказке легко исправляется редактором, а ошибка в автоматическом изменении заказа может затронуть клиента и учёт. Поэтому ТЗ должно установить границы задач, разрешённые источники, права на действия, способ сообщать о неопределённости и проверку на реальных вопросах.

Этот материал посвящён именно требованиям и приёмке перед реализацией. Он не повторяет план внедрения AI-ассистента и не обещает, что одна модель решит все процессы. NIST AI Risk Management Framework предлагает рассматривать управление рисками на протяжении жизненного цикла системы; конкретный набор тестов и пороги качества организация утверждает по своей задаче.

Типовые опасные сокращения

Быстрый прототип полезен как исследование, но не как доказательство готовности к клиентскому каналу.

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

Определите задачу и цену ошибки

Лучший первый сценарий имеет понятный источник истины и человека, способного проверить результат.

• Соберите реальные запросы из одного процесса: вопросы сотрудников о правилах, ответы поддержки по документации или поиск по базе знаний. Разделите их на фактические, требующие вычисления, требующие решения человека и запрещённые для автоматического ответа. Для каждой группы укажите, что считается полезным результатом и какая ошибка допустима только как черновик.
• Опишите источники: документы, их версии, владельца, дату обновления, уровень доступа и способ удаления устаревшей информации. Система не должна придавать старому прайсу такой же вес, как действующему договору. Если источники противоречат друг другу, ассистент должен обозначить конфликт или передать вопрос владельцу данных.
• Проведите карту данных и прав. Какие запросы могут содержать персональные, финансовые или коммерчески чувствительные сведения? Кто имеет право видеть ответы и исходные документы? Как проверяется роль при каждом запросе, а не только при входе? Какие данные нельзя отправлять внешнему поставщику модели? Решения по обработке данных согласуйте с ответственными специалистами.
• Укажите действия, которые ассистенту разрешены: только поиск, черновик письма, заполнение формы после подтверждения или изменение записи. Чем выше необратимость, тем явнее нужна проверка человеком и журнал действия. Не давайте широких API-прав ради удобства прототипа; тестовый ключ не должен получать доступ ко всем клиентам.
• Назначьте владельца качества, владельца знаний и оператора эскалации. Первый пересматривает тесты, второй отвечает за актуальность источников, третий получает вопросы с высоким риском и ошибки. Без этих ролей фраза «обновим базу знаний» не является работающим процессом.

Пример тестового случая и порога запуска

Набор проверок должен предшествовать промпт-инжинирингу, иначе команда невольно подгонит тест под демонстрацию.

• Пример: сотрудник спрашивает о сроке возврата по договору клиента. У пользователя есть доступ только к своей организации. Ассистент обязан найти действующий документ именно этой организации, назвать условие с ссылкой на источник и не показывать договор другой. Если документ не найден или в базе есть две разные версии, ожидаемый результат — честное ограничение и маршрут к ответственному, а не правдоподобное число дней.
• Разделите метрики: точность факта на выбранном наборе, доля корректных ссылок на источник, доля безопасных отказов, утечки доступа и полезность для сотрудника. Порог утверждайте отдельно для каждой категории запроса. Один средний балл может скрыть опасную ошибку на редких, но дорогих сценариях; критические нарушения рассматривайте поштучно.
• Для интеграций запишите разрешённые операции, аргументы, проверку роли, подтверждение человеком и план отката. Если ассистент подготовил изменение заказа, оно не должно автоматически считаться выполненным. Человек видит исходное состояние, предлагаемое изменение и последствия; после подтверждения система сохраняет идентификатор действия и результат.
• Укажите процедуру разбора инцидента: как остановить проблемный сценарий, найти затронутые ответы, исправить источник, обновить тест и повторно проверить релиз. Это важнее обещания «галлюцинаций не будет»: ошибки модели полностью не исчезают, зато их можно ограничивать, обнаруживать и исправлять.

Разделы ТЗ на AI-ассистента

Описывайте наблюдаемое поведение на типовых, пограничных и недопустимых запросах.

• Сценарий пользователя. Укажите, где появляется ассистент, кто задаёт вопрос, какие данные доступны и как выглядит полезный ответ. Для поддержки примером может быть черновик с выдержкой из действующей инструкции; публикацию клиенту подтверждает сотрудник. Не смешивайте поиск, написание текста и выполнение действия в одном неопределённом пункте.
• Источники и актуальность. Зафиксируйте перечень коллекций, владельца, правило обновления, отметку версии и ссылку на первичный документ. Если ответа нет в разрешённых данных, система должна прямо сказать об ограничении. Выдуманная ссылка или уверенный ответ без источника недопустимы для сценария, где доказуемость обязательна.
• Поведение при неопределённости. Опишите случаи неполного вопроса, противоречивых документов, запроса вне компетенции и опасного совета. Укажите, когда ассистент просит уточнение, когда отказывается и когда переводит к человеку. Не задавайте один магический «процент уверенности» без проверки, как он связан с ошибками на ваших данных.
• Безопасность и контекст. Пользовательский текст и извлечённый документ не должны автоматически становиться системной инструкцией. Проверьте попытки заставить систему раскрыть чужие данные или выполнить действие, которого пользователь не вправе делать. Разделите права на чтение, генерацию и запись во внешние системы; фиксируйте причины каждого вызова инструмента.
• Интерфейс и обратная связь. Ответ должен показывать, что известно, что предположено и куда обратиться при споре. Дайте возможность исправить вопрос, открыть источник и пометить ответ как неверный без отправки чувствительных данных в случайный аналитический сервис. Если ответ является черновиком, обозначьте это в интерфейсе.
• Эксплуатация. Опишите версии промпта, модели, поискового индекса и тестового набора. Изменение любого из них должно проходить повторную оценку критических запросов. Предусмотрите журнал ошибок, контроль расходов, задержек и доступности, а также безопасный режим отключения автоматических действий.
• Приёмка. Соберите заранее отложенный набор реальных обезличенных запросов: типовые, редкие, противоречивые, провокационные и требующие отказа. Для каждого запишите ожидаемое поведение, допустимые источники и уровень риска. Проверяйте не только «похожесть» ответа на эталон, но и правильность факта, ссылки, разрешения и способа эскалации.

Как контролировать качество после запуска

Сравнивайте одни и те же категории запросов на версионированном наборе и отслеживайте последствия ошибок.

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

Что должно быть готово до оценки проекта

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

После согласования ТЗ переходите к пилоту с человеком в контуре проверки. Масштабируйте только те классы запросов, где наблюдается стабильное качество и понятна цена ошибки. Для календаря внедрения и отдельной методики оценки используйте материалы о плане AI-ассистента и его тестировании.

Тест на достоверность и права

Попросите ассистента назвать условие из документа, к которому у тестового пользователя нет доступа. Корректный результат — отказ раскрывать содержание, а не уверенная цитата. Затем задайте тот же вопрос пользователем с правом доступа: ответ должен ссылаться на действующую версию документа. Подмените найденный фрагмент текстом с инструкцией «игнорировать правила» и проверьте, что она не меняет поведение системы. Такой тест проверяет и пользу, и границу доверия к источнику.

В приложении к ТЗ разделите вопросы по последствиям ошибки. Поиск внутренней инструкции может терпеть черновой ответ, если сотрудник видит источник и проверяет его. Сообщение клиенту о цене, сроке или праве на услугу требует более строгого контроля. Изменение записи в CRM — уже действие, которому нужны разрешение, подтверждение и журнал. Для каждого класса определите не абстрактную «точность AI», а ожидаемый результат, допустимое уточнение и ситуацию, когда система должна остановиться.

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

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

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