Когда AI-агент отвечает клиенту неправильно, деньги обычно тратят на смену модели, хотя ошибка чаще сидит в документах, из которых он ответ достаёт. AI находит ответ в документах через поиск: вопрос превращается в запрос, система достаёт несколько подходящих фрагментов, и модель пересказывает их своими словами — такой подход называют RAG, генерацией с опорой на поиск. Почти любая претензия к качеству ответов объясняется сбоем на одном конкретном шаге этой цепочки. Разберу, где что ломается, что чинить в первую очередь и как проверить базу документов на контрольном наборе вопросов, прежде чем платить за настройку.
Модель не вспоминает ответ, а пересказывает найденное
Агент не «читает все ваши документы» перед каждым ответом — это было бы медленно и технически невозможно на сколько-нибудь большой базе. Вместо этого работает поиск: система находит несколько наиболее подходящих фрагментов и передаёт их модели вместе с вопросом.
Последовательность такая: вопрос клиента превращается в поисковый запрос, по нему находятся фрагменты документов, найденное передаётся модели с инструкцией «отвечай только по этому», модель формулирует ответ человеческим языком.
Модель не вспоминает ответ — она пересказывает найденный фрагмент. Если фрагмент не найден или найден не тот, ответ будет неверным независимо от того, насколько хороша сама модель.
Для бюджета проекта из этого следует неудобная вещь: переход на более дорогую модель почти не лечит неверные ответы, если причина в поиске или в документах. Хорошая модель просто перескажет не тот фрагмент убедительнее.
Нарезка документов: где теряется оговорка
Целый документ на сорок страниц как единица поиска бесполезен: в нём есть ответы на десятки разных вопросов. Поэтому документы разбивают на куски по нескольку абзацев.
Размер куска — предмет настройки, и обе крайности вредны. Слишком мелкие фрагменты теряют контекст: условие оторвано от оговорки, которая шла абзацем ниже. Слишком крупные размывают смысл: в одном куске лежат три разные темы, и поиск не понимает, к какой он относится.
Самый дорогой вариант первой ошибки — оторванное исключение. «Возврат возможен в течение срока, указанного в договоре» попадает в один фрагмент, «кроме товаров, изготовленных на заказ» — в следующий. Агент уверенно обещает возврат там, где его нет, и спорить потом приходится уже с клиентом, а не с системой.
Поиск по смыслу находит и лишнее
Поиск идёт не по совпадению слов, а по смыслу. Вопрос «можно ли вернуть, если не подошло» найдёт фрагмент про возврат товара надлежащего качества, даже если слова «вернуть» в нём нет.
Это одновременно сильная и слабая сторона. Сильная — клиенту не нужно угадывать формулировку из документа. Слабая — если в базе лежат два похожих по смыслу документа, например прошлогодние и действующие условия доставки, поиск может вытащить не тот, и ничто в ответе не подскажет, что он устарел.
Право на незнание задаётся при сборке ответа
Найденные фрагменты передаются модели вместе с вопросом и инструкцией отвечать строго по ним. Модель формулирует связный ответ, а не выдаёт кусок текста дословно — именно поэтому агент звучит как человек, а не как справочник.
Здесь же задаётся право на незнание: если во фрагментах ответа нет, модель должна сказать об этом и передать вопрос человеку, а не достраивать из общих представлений. Без явной инструкции она достроит — почему модели так устроены, разобрано в статье о том, почему AI выдумывает. Я считаю эту настройку обязательной для любого агента, который говорит с клиентами: честное «уточню у специалиста» стоит компании минуту оператора, уверенная выдумка — спор и иногда деньги.
Где механизм ломается
| Симптом | Где сбой | Что чинить |
|---|---|---|
| Отвечает не про то | Поиск вытащил не тот фрагмент | Убрать дубли и противоречия в документах |
| Ответ верный, но неполный | Фрагменты слишком мелкие | Увеличить размер куска или связать соседние |
| Уверенно выдумывает | Нет права на незнание | Задать инструкцию признавать отсутствие ответа |
| Говорит устаревшее | Документ в базе не обновлён | Наладить регулярное обновление |
| Отвечает по-разному на один вопрос | В базе противоречащие документы | Оставить один источник правды |
Последняя строка встречается чаще всего и выглядит мистикой: сегодня агент говорит одно, завтра другое, воспроизвести невозможно. Причина прозаична — поиск попеременно находит то один документ, то другой.
Почему качество ответов начинается с документов
Из механизма следует вывод, неприятный для тех, кто рассчитывал решить всё настройкой модели: качество ответов определяется прежде всего состоянием документов. Модель может пересказать только то, что нашлось.
Отсюда практический порядок работ: сначала привести документы в порядок — убрать дубли, устранить противоречия, дописать недостающее, — и только потом заниматься настройкой поведения. Обратный порядок даёт хорошо звучащие неверные ответы.
Почему поиск не находит очевидное
Частая и обидная ситуация: ответ в документе есть, человек находит его за секунду, а система отвечает, что не знает. Причина почти всегда в расхождении языка.
Клиенты и документы говорят разными словами. В регламенте написано «расторжение договора в одностороннем порядке», клиент спрашивает «как отказаться и вернуть деньги». Человек понимает, что это одно и то же, потому что знает предметную область; поиск опирается на близость формулировок, и на большом разрыве промахивается.
Лечится это со стороны документов, а не поиска. К разделу добавляются формулировки, которыми пользуются клиенты, — прямо в текст или отдельным списком синонимов. Собрать их можно из тех же обращений: реальные вопросы за месяц дают готовый словарь.
Как писать документы, чтобы по ним искалось
Материалы, написанные для человека, и материалы, пригодные для поиска, различаются в нескольких деталях, и переделка обычно занимает меньше времени, чем настройка системы.
Первое — самодостаточность раздела. Абзац, начинающийся с «в этом случае», бесполезен, если найден отдельно от предыдущего. Каждый смысловой блок должен быть понятен сам по себе, с явным указанием, о чём речь. Второе — один вопрос, один раздел: если ответ размазан по трём местам, поиск найдёт одно из них.
Третье — заголовки в форме вопроса или явного утверждения. «Возврат товара надлежащего качества» работает лучше, чем «Раздел 4.2». И четвёртое — убрать дубли: два раздела об одном и том же гарантируют, что рано или поздно будет найден устаревший.
Сколько фрагментов передавать модели
Настройка, которая незаметно определяет качество: сколько найденных кусков уходит в ответ. Оба крайних варианта плохи, и обычно система настроена по умолчанию, а не под задачу.
Мало фрагментов — ответ получается неполным: нужная деталь была в четвёртом по релевантности куске, а передали три. Много — модель получает противоречивый и разнородный материал, начинает выбирать между ним и чаще ошибается, а стоимость обращения растёт.
Подбирается это на контрольном наборе: прогнать одни и те же вопросы при разном числе фрагментов и сравнить долю полных и верных ответов. Обычно кривая имеет явный максимум, и он редко совпадает с настройкой по умолчанию.
Вопросы, ответ на которые собирается из нескольких мест
Отдельный класс, на котором механизм поиска работает хуже всего: вопрос требует соединить сведения из разных документов. «Сколько будет стоить доставка в мой город при заказе на такую-то сумму» — это тариф из одного места, условие бесплатной доставки из другого, зона из третьего.
Поиск устроен так, что ищет похожее на вопрос целиком, а ни один из трёх фрагментов на весь вопрос не похож. Результат — уверенный ответ по одному из аспектов и молчание об остальных.
Практических обхода два. Первый — свести часто сочетаемые сведения в один раздел: не ссылка на тарифы из условий, а таблица, где всё вместе. Второй — на уровне сценария разбить составной вопрос на части и искать по каждой отдельно. Первый дешевле и работает почти всегда, поэтому начинать стоит с него.
Контрольный набор вопросов вместо впечатлений
Качество ответов по документам нельзя оценить, «пообщавшись с агентом полчаса»: приятные ответы на удачные вопросы создают ложную уверенность. Нужен контрольный набор, и собрать его можно за день.
- Реальные вопросы, а не придуманные. Возьмите два десятка вопросов из переписки и звонков за последний месяц — с опечатками и бытовыми формулировками, как их задают клиенты.
- Эталон рядом с каждым вопросом. Для каждого вопроса выпишите, в каком документе и разделе лежит правильный ответ. Проверяйте не «похоже ли на правду», а совпадает ли ответ с этим разделом.
- Вопросы без ответа. Добавьте несколько вопросов, ответа на которые в документах заведомо нет. Правильное поведение — признание незнания и передача человеку.
- Одна мысль разными словами. Задайте часть вопросов трижды в разных формулировках.
На один и тот же вопрос, заданный трижды разными словами, агент даёт один и тот же по сути ответ. Расхождение означает, что в базе лежит больше одного источника правды.
Метрика здесь простая — доля ответов, совпавших с эталоном, и доля честных «не знаю» на вопросах без ответа. Этот же набор прогоняется после каждой правки документов и настроек: если доля верных ответов не растёт, правка не помогла, как бы разумно она ни выглядела. Подробнее о приёмке агента до запуска — в разборе тестирования.
Когда агент по документам не нужен
Поиск по документам решает конкретную задачу — отвечать на вопросы, ответ на которые где-то записан. Там, где задача другая, он не нужен или не окупится.
Если клиенты задают три десятка одних и тех же вопросов, хорошо написанная страница ответов на сайте и простой бот с кнопками обойдутся дешевле и ошибаться не будут вовсе. Если вопрос — «где мой заказ» или «сколько у меня бонусов», ответ лежит не в документах, а в учётной системе, и нужна интеграция, а не поиск. Если документы меняются каждую неделю и у них нет владельца, агент будет честно пересказывать устаревшее, и никакая настройка этого не исправит. И если цена ошибки высокая — юридическая консультация, условия кредита, дозировка, — агент может готовить черновик ответа, но отвечать клиенту без проверки человеком ему не стоит.
Поэтому в 404ai разговор о таком агенте начинают не с модели, а с документов: что есть в письменном виде, где противоречия и дубли и сколько работы до рабочей базы знаний. Иногда честный вывод этой проверки — сначала навести порядок в регламентах силами компании, а агента обсуждать потом.
Что следует из того, как AI находит ответ в документах
Главное следствие для решения: бюджет проекта стоит делить не между «моделями подешевле и подороже», а между документами и настройкой — и документы идут первыми. Что именно класть в базу и чего нельзя, разобрано в статье о базе знаний AI-агента; почему это не заменяется обучением модели — в материале про дообучение и базу знаний. Проверить свою готовность можно до разговора с любым подрядчиком: возьмите десять самых частых вопросов клиентов и найдите на каждый один-единственный раздел в ваших документах. Если на какой-то вопрос разделов два или ни одного, именно там агент и будет ошибаться.
