Почему умные ИИ-ассистенты всё равно ошибаются: взгляд через конвейер

Современные ИИ-ассистенты за считаные секунды пишут код, сжимают документы, обрабатывают данные и разбираются с каверзными вопросами — и делают это тоном, который намекает на настоящие знания. А потом время от времени кто-то из них уверенно заявляет откровенную неправду. Выдуманная функция библиотеки. Ссылка на статью, которую никто не писал. Правило возврата, противоречащее собственной документации компании. Любой, кто строил ассистента или пользовался им дольше пары недель, с этим сталкивался, и раздражает не сама ошибка. Раздражает абсолютная самоуверенность, с которой она подаётся.

Возникает странный парадокс.

More intelligence ≠ Perfect accuracy

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

User Question
      ↓
Query Understanding
      ↓
Retrieval System (RAG)
      ↓
Context Selection
      ↓
LLM Generation
      ↓
Final Answer

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

Умный — не значит точный

Каждая команда, выпускающая ИИ-продукт, рано или поздно упирается в одно и то же противоречие. Модель действительно мощная. Она училась на огромных наборах данных, рассуждает шаг за шагом, пишет работающие программы и переваривает сложные научные статьи. Ничто из этого не обещает правильного ответа на конкретный вопрос в конкретный момент.

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

Предсказание без проверки

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

Question:
Who invented XYZ technology?

AI:
Generates the most probable answer.

Problem:
Probability is not always truth.

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

Как выглядит галлюцинация

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

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

Обычная последовательность проста.

Missing Information
      ↓
Model Attempts Prediction
      ↓
Confident But Incorrect Output

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

Узкое место контекстного окна

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

Large Document
      ↓
Only Selected Context
      ↓
LLM
      ↓
Answer

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

RAG помогает, но добавляет точки отказа

Генерация, дополненная поиском (RAG), решает проблему того, что ИИ не знает ваших данных. Релевантные документы извлекаются из базы знаний, передаются модели как контекст, и ответ опирается на них. Это действительно повышает точность, но ошибок не устраняет, потому что приносит новые способы сломаться:

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

Сходство — не правильность

Векторный поиск лежит в основе большинства RAG-систем. Запрос превращается в эмбеддинг, и система ищет документы, чьи эмбеддинги расположены ближе всего.

User Query

"refund for yearly subscription"

        ↓

Embedding

        ↓

Similar Documents Retrieved

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

Генерация тоже может подвести

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

Даже если поиск работает безупречно и нужные факты попадают в контекст, у этапа генерации свои ловушки:

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

Вот как противоречивый контекст портит в остальном исправный конвейер:

Retrieved Data:

Document A:
Refund allowed within 30 days.

Document B:
Refund allowed within 14 days.

      ↓

AI must decide.

      ↓

Possible incorrect answer.

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

Надёжность нужно проектировать намеренно

Всё это не делает RAG или LLM ненадёжными по своей природе. Это значит, что надёжность нужно выстраивать сознательно. Сильнее всего влияют несколько рычагов.

Более качественный поиск:

• Гибридный поиск сочетает поиск по ключевым словам с векторным и ловит точные термины — названия продуктов, коды ошибок, номера правил, — которые чисто семантическое сходство пропускает.
• Реранжирование запускает модель второго прохода, которая переупорядочивает результаты по реальной релевантности запросу, а не только по расстоянию между эмбеддингами.
• Фильтрация по метаданным сужает кандидатов по структурированным полям вроде даты, типа документа или тарифа ещё до начала поиска по сходству.

Чёткие инструкции модели. Явные указания заметно сокращают галлюцинации:

Answer only using the provided context.
If the information is not available in the context, say you don't know.

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

Измерения. Неизмеряемое нельзя исправить, поэтому надёжные системы отслеживают достоверность (соответствует ли ответ найденному контексту?), точность (верен ли он фактически?) и качество поиска (были ли вообще найдены нужные документы?).

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

Не судите по тону

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

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

• Точность поиска: находятся ли нужные документы для данного запроса?
• Релевантность ответа: отвечает ли он на заданный вопрос?
• Частота галлюцинаций: как часто система выдаёт утверждения без опоры?
• Удовлетворённость пользователей: получают ли люди пользу или лишь вежливые отписки?

Без этого команды в итоге настраивают тон и гладкость вместо правильности — именно так уверенно ошибающиеся ассистенты и попадают в продакшен.

Следующая задача — надёжность

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

Better Models

+

Better Data

+

Better Retrieval

+

Better Evaluation

=

Reliable AI Assistants

Каждый неверный ответ ассистента восходит к пробелу в одном из этих уровней, а не к нехватке интеллекта. Понять, какой уровень подвёл, — первый шаг к исправлению.