Почему LLM выдумывает даже с RAG и что чинить вместо промптов

Знакомая история: бэкенд-разработчик по имени Диви ушёл в тему LLM с головой — LangChain, LangGraph, CrewAI, AutoGen, все виды памяти, RAG-пайплайны и промпты длиннее иных файлов с кодом. Модель всё равно выдумывала. А GitHub постепенно превращался в кладбище недоделанных чат-ботов.

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

Смена инструмента не лечит

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

Разница принципиальная. База знаний хранит факты и отдаёт их по запросу. Модель ничего не хранит: она достраивает наиболее правдоподобное продолжение. Нет нужного факта в контексте — правдоподобное продолжение всё равно появится. Просто выдуманное. Вот и вся галлюцинация в бытовом виде.

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

Обзоры фреймворков и «лучшие практики» проверяйте на своих данных. Чужой пайплайн редко воспроизводится один в один, и дело тут не в версии библиотеки.

Чаще всего течёт на этапе поиска

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

Дальше два приёма, которые он называет как рабочие: гибридный поиск (объединяем выдачу двух способов) и рерanking (отдельная модель переставляет верхушку списка, оценивая пару «запрос — фрагмент» целиком, а не по отдельности).

Чек-лист: где именно сломалось

1. Проверка глазами модели. Положите нужный фрагмент прямо в контекст руками. Ответ стал верным? Значит, проблема на стороне поиска, модель тут ни при чём.
2. Посмотрите на сырую выдачу. Попадает ли правильный кусок в верхние позиции вообще? Не попадает — начинайте с гибридного поиска и рерanking, фреймворк подождёт.
3. Требуйте ссылку на источник. Пусть модель называет id или цитирует фрагмент, которым пользовалась. Проверка ответа превращается в механическую операцию.
4. Оставьте право сказать «в контексте этого нет». Без явного разрешения модель будет додумывать — это дешевле, чем признать незнание.
5. Логируйте, что реально ушло в промпт. На этом шаге половина разборов галлюцинаций заканчивается: в контекст уехало не то, что вы думали.

Когда вся эта машинерия лишняя

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

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

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