Как научить ИИ отвечать «не знаю», когда в базе нет ответа

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

Главное условие: одновременно нужно уменьшать две ошибки — ложный ответ и избыточный отказ. Если снижать только первую, ассистент превратится в постоянное «не знаю». После статьи вы сможете описать, когда ответа действительно нет, настроить четыре реакции ассистента и собрать контрольную выборку для проверки на ваших обращениях.

Когда ответа действительно нет

Фраза «в базе нет ответа» может описывать как минимум четыре разные ситуации. Правильная реакция зависит от того, какая именно произошла.

Нет документа. Вопрос касается темы, которую база знаний не покрывает. Например, клиент спрашивает о доставке в страну, с которой компания не работает, а в документах об этом ничего не сказано.

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

Конфликт версий. Найдены два документа с разными ответами: старые и новые правила либо общая политика и исключение для отдельного региона. Без правила приоритета модель может выбрать один из них наугад или смешать оба.

Ограничение прав. Система должна применять права доступа на этапе поиска и не передавать модели недоступные фрагменты. Ответ пользователю не должен подтверждать, существует ли конкретный документ, или раскрывать его содержание. Ассистент может нейтрально объяснить, как обратиться к ответственному за доступ.

Полезно, чтобы система различала эти состояния технически, а не только по формулировке модели. Например, поиск может возвращать не только фрагменты, но и признаки: сколько фрагментов найдено, есть ли документы разных версий и сколько результатов отфильтровано по правам. Тогда решение о реакции принимается не только «на вкус» модели.

Проверка доказательств

Ключевая идея: отвечать можно, только если найден фрагмент, который относится именно к заданному вопросу. Тематического сходства недостаточно.

В большинстве систем RAG поиск основан на сходстве: он находит фрагменты, близкие по смыслу к запросу. Но близость не равна ответу. На вопрос «Можно ли вернуть товар после 30 дней, если им пользовались?» поиск легко найдёт фрагмент о возврате в течение 14 дней. Тема та же, но ответа на конкретный вопрос в этом фрагменте нет.

Поэтому полезно разделять два этапа проверки:

1. Найден ли релевантный контекст? Есть ли среди фрагментов относящиеся к вопросу? Здесь оценивается качество поиска.
2. Опирается ли ответ на контекст? Подтверждается ли каждое утверждение найденными фрагментами, а не общими знаниями модели? Здесь оценивается верность ответа источнику.

Практические приёмы:

• Попросите модель сначала найти цитату. Инструкция вроде «приведи фрагмент, который прямо отвечает на вопрос; если такого нет, отметь это» делает отсутствие доказательств явным.
• Структурированный результат. Ответ возвращается с полями: статус (ответ, уточнение, ограничение, передача человеку), текст и ID использованных фрагментов. Код может проверить, что для статуса «ответ» есть хотя бы одна ссылка на фрагмент. Но структура не доказывает, что модель выбрала статус правильно.
• Отдельная проверка соответствия. Для критичных тем можно добавить второй шаг, который проверяет, содержатся ли утверждения ответа в приведённых фрагментах.

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

Отдельно о порогах сходства. Число от векторного поиска показывает близость текстов в определённом представлении, а не вероятность того, что фрагмент содержит правильный ответ. Универсального порога нет: он зависит от модели эмбеддингов, языка, стиля документов и способа их разбиения. Порог можно использовать как один из сигналов, но настраивать его следует на своих данных.

Четыре реакции

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

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

Уточнить. Вопрос неоднозначен, и ответ зависит от детали, которую можно спросить. Например, правила различаются для физических и юридических лиц, но из вопроса неясно, кто спрашивает. Уточнение часто полезнее отказа: оно превращает «не знаю» в «смогу ответить, если вы сообщите вот это».

Назвать ограничение. Документ есть, но не охватывает случай. Ассистент честно сообщает, что известно, а что нет: «В правилах описан возврат в течение 14 дней для неиспользованных товаров. Условия для использованных товаров не найдены».

Передать человеку. Ответа нет, уточнение не помогает, а вопрос важен. Ассистент передаёт его ответственному сотруднику вместе с контекстом, чтобы клиенту не пришлось повторять всё сначала.

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

Как сформулировать полезный отказ

Плохое «не знаю» завершает разговор. Полезное «не знаю» даёт человеку следующий шаг.

В полезном отказе три элемента:

1. Что именно не найдено. Не общее «я не могу помочь», а конкретное: «в доступных документах нет условия для такого случая».
2. Что известно рядом, если это уместно. Известное общее правило с ясной оговоркой, что оно может не относиться к конкретному случаю.
3. Следующий шаг. Какую деталь уточнить, кому передать вопрос и что произойдёт дальше.

Учебный пример ответа:

«В доступных правилах нет условия для этого случая. Уточните, пожалуйста, тип договора: стандартный или корпоративный. Если правило не найдётся, мы передадим вопрос специалисту».

Чего следует избегать:

• Выдуманной уверенности. Клиент воспринимает слова «вероятно» или «обычно» перед неподтверждённым документом предположением как ответ.
• Раскрытия закрытой информации. Отказ из-за прав не должен намекать на содержание документа: «Я не могу сказать, что согласно приказу об увольнении...» уже раскрывает информацию.
• Обещаний того, чего система не делает. Если передача человеку не настроена или у неё нет срока ответа, не пишите «с вами свяжутся в течение часа».

Две группы ошибок

Любая настройка поведения «не знаю» меняет баланс между двумя ошибками.

Ложный ответ. Ассистент отвечает, хотя доказательств нет или они неверны. Цена зависит от темы: неточность в общем описании продукта менее вредна, чем ошибочное условие договора или неправильная сумма возврата.

Избыточный отказ. Ассистент говорит «не знаю», хотя ответ есть в документах. Это тоже имеет цену: клиент идёт к оператору, нагрузка не снижается, доверие к ассистенту падает.

Исследования способности моделей воздерживаться от ответа показывают, что даже мощным моделям это даётся непросто, а отдельные стратегии промптинга (строгие инструкции, пошаговое рассуждение) могут улучшить результат. Значит, промпт важен, но сам задачу не решает. Результат нужно измерять на собственных данных.

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

Настройка по реальным обращениям

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

Учебная контрольная выборка из 100 вопросов

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

Как работать с выборкой:

1. Собирайте вопросы из реальных обращений, а не придумывайте удобные. Самые ценные — вопросы, на которых ассистент уже ошибался.
2. Разметку выполняет человек, знающий процесс; он также фиксирует, почему правильна именно эта реакция.
3. Меняйте по одному правилу и сравнивайте результат на той же выборке.
4. Не добавляйте примеры из контрольной выборки в промпт, иначе проверяется запоминание.
5. Пересматривайте выборку при изменении документов, продуктов или типичных вопросов клиентов.

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

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

Последний пункт часто приносит наибольшую практическую пользу. Собранные в статистику честные ответы «не знаю» показывают, какие знания компании не задокументированы, и помогают решить, что описать в первую очередь.

Вывод

Надёжное «не знаю» складывается из нескольких частей: различения причин отсутствия ответа, проверки доказательств, четырёх реакций вместо одной и измерения обеих групп ошибок. Самооценка уверенности модели и порог сходства — сигналы, а не гарантии.

Что можно сделать в своём процессе:

1. Соберите 100 реальных вопросов в четырёх группах: с ответом, без ответа, с конфликтом документов и с ограничением прав.
2. Для каждого запишите правильную реакцию: ответить, уточнить, назвать ограничение или передать человеку.
3. Настройте ассистента возвращать статус реакции и ссылки на использованные фрагменты; в коде проверяйте, что у ответа есть хотя бы одна такая ссылка.
4. Определите правило приоритета конфликтующих документов и путь передачи человеку вместе с контекстом.
5. Прогоните выборку и отдельно посчитайте ложные ответы, избыточные отказы и утечки закрытой информации.
6. Меняйте правила по одному и повторяйте прогон. Пересматривайте выборку вместе с изменениями документов.

Если вам важно, чтобы ассистент честно отвечал по документам компании, команда BotLabs может обсудить это с вами на 15-минутной консультации. Разберём, какие вопросы задают чаще всего, где возникают ложные ответы и избыточные отказы, а также с какой контрольной выборки начать. Следующим шагом определим, что проверить на ваших реальных обращениях.

Часто задаваемые вопросы