RAG

RAG (Retrieval-Augmented Generation, генерация с дополненным поиском) — способ заставить языковую модель отвечать по вашим данным. Перед тем как модель начнёт писать ответ, система находит в базе знаний несколько подходящих фрагментов и подкладывает их в запрос. Модель отвечает уже не по памяти, а по тексту, который у неё перед глазами.

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

Как это работает?

Два контура: один готовит данные заранее, второй работает на каждом запросе.

Подготовка (один раз и при обновлениях):

• Нарезка на фрагменты. Документы режутся на куски по 200–800 слов. Слишком крупные фрагменты размывают смысл при поиске, слишком мелкие теряют контекст.
• Эмбеддинги. Каждый фрагмент превращается в вектор — числовое представление смысла. Близкие по смыслу тексты дают близкие векторы, даже если слова разные.
• Индекс. Векторы складываются в базу с поиском по близости (pgvector, Qdrant, Weaviate и подобные).

Ответ (на каждый вопрос):

• Вопрос пользователя превращается в вектор тем же способом.
• Из базы достаются N ближайших фрагментов — обычно 3–10.
• Фрагменты вставляются в запрос к модели с инструкцией «отвечай только по приведённым материалам, если ответа нет — так и скажи».
• Ответ возвращается пользователю вместе со ссылками на использованные фрагменты.

Пример с числами

Компания перевела первую линию поддержки на RAG поверх базы из 4 200 статей и решённых тикетов. Что получилось за квартал:

Важная цифра здесь последняя. 12% эскалаций — это доля случаев, где ответ не устроил, и именно она показывает реальное качество. Разбор этих 12% дал понятный вывод: почти все промахи пришлись на вопросы, ответ на которые лежал в таблицах внутри PDF — при нарезке таблицы разваливались и теряли заголовки колонок. Починили нарезку, а не модель.

Чем RAG отличается от дообучения модели?

Практическое правило: если вопрос «модель не знает наших фактов» — это RAG. Если «модель знает, но отвечает не в том формате и не тем тоном» — это дообучение или просто хорошая инструкция в промпте.

Где чаще всего ошибаются?

• Вкладываться в модель вместо поиска. В подавляющем большинстве неудачных внедрений виноват не генератор, а retrieval: нужный фрагмент просто не попал в выдачу. Сначала измеряйте долю запросов, где правильный фрагмент оказался в топ-N.
• Нарезка без учёта структуры. Резать по 500 символов подряд — значит рвать таблицы и списки посередине. Резать лучше по смысловым границам: разделам, пунктам, строкам таблицы.
• Только векторный поиск. Эмбеддинги плохо ловят точные совпадения — артикулы, номера статей, коды ошибок. Гибрид векторного и обычного полнотекстового поиска почти всегда работает лучше любого из них по отдельности.
• Нет ответа «не знаю». Если в инструкции не разрешено отказываться, модель будет отвечать всегда — в том числе когда в найденных фрагментах ответа нет.
• Отсутствие замера. Без набора из 50–100 контрольных вопросов с эталонными ответами любое изменение системы — это вкусовщина, а не улучшение.

Связанные термины

• LLM — что за модель стоит в основе и почему она выдумывает.
• Промпт-инжиниринг — как формулируется та самая инструкция «отвечай только по материалам».