Почему уверенный ответ может быть хуже, чем его отсутствие
Вы закончили создание внутреннего чат-бота. Вы скормили ему все HR-политики, технические спецификации и документы по онбордингу, которыми владеет ваша компания. Новый сотрудник спрашивает о лимите расходов на деловые ужины с клиентами. Бот отвечает мгновенно. Он звучит очень уверенно. Лимит, который он называет, составляет 75 долларов на человека.
На самом деле в политике указано 50 долларов. Бот выдумал ответ. Он даже не открывал ваши файлы. Он просто угадал, опираясь на паттерны, заложенные в его обучающих данных много лет назад. Такова суровая реальность использования «сырых» больших языковых моделей (LLM) для работы с частными документами. У них нет доступа к вашим внутренним знаниям. Когда нужные им факты находятся за пределами их обучающих весов, они начинают фабриковать ответы вместо того, чтобы признать свое незнание. В промышленной эксплуатации это перестает быть забавным и становится источником рисков.
Retrieval-Augmented Generation, или RAG, был создан именно для решения этой проблемы. Вместо того чтобы просить модель помнить всё, вы позволяете ей искать информацию.
От догадок к чтению
Представьте себе базовую LLM как блестящего коллегу с фотографической памятью, но такого, который уволился из вашей компании еще до вашего прихода. Он может писать красноречивые тексты, рассуждать в логических задачах и объяснять концепции простыми словами. Но если вы спросите его об изменениях в API за прошлый квартал, он просто выдумает что-то правдоподобное. У него нет другого выхода.
RAG дает этому коллеге доступ к картотеке. Когда пользователь задает вопрос, система не забрасывает вопрос модели вслепую. Сначала она извлекает релевантные документы, вставляет их в промпт в качестве контекста и только после этого просит модель прочитать их и ответить. Модель переключается с режима вспоминания фактов на режим осмысления фактов, которые буквально находятся перед ней.
Этот процесс четко делится на две части: предварительную работу (offline) и оперативный ответ (online).
Этап 1: Фаза подготовки (Offline)
Задолго до того, как кто-либо введет вопрос, вы должны превратить свою разрозненную коллекцию документов в базу знаний, доступную для поиска. От этой подготовительной работы зависит, будет ли ваша RAG-система процветать или тихо потерпеть неудачу.
Загрузчики документов (document loaders) — это ваша отправная точка. Эти коннекторы извлекают необработанный текст из PDF, рабочих пространств Notion, папок SharePoint, веб-страниц и внутренних вики. Здесь впервые можно столкнуться с трудностями. Загрузчик может извлечь чистый текст из документа Word, но «запинаться» на отсканированном PDF, который представляет собой просто изображение без текстового слоя. Загрузчик возвращает пустую строку, ваша база данных ничего не сохраняет, а пользователь позже получает ответ «Я не знаю» без каких-либо предупреждений. Всегда проверяйте, что именно извлекли ваши загрузчики. Проводите выборочные проверки нескольких документов из каждого источника, прежде чем доверять конвейеру.
Далее следует разделение текста (text splitting), также называемое чанкингом (chunking). Вы не можете скормить восьмидесятистраничную политику безопасности в одном промпте; вы превысите лимиты контекста и похороните полезный сигнал в шуме. Вместо этого вы разбиваете документы на фрагменты (чанки). Секрет в выборе правильного размера. Слишком маленькие фрагменты, например, отдельные предложения, часто теряют критически важный контекст. Фрагмент, гласящий: «Все запросы должны быть одобрены менеджером», может забыть упомянуть, что это правило относится только к международным поездкам. Слишком большие фрагменты, такие как целые главы, размывают эмбеддинг и путают поиск, так как охватывают сразу пятнадцать разных тем. На практике многие команды начинают с фрагментов размером от 300 до 500 токенов с перекрытием (overlap) в 50 токенов, чтобы предложения, разделенные границей, не искажались. Настраивайте этот параметр в зависимости от вашего контента. Документация API допускает более мелкие фрагменты. Юридическим контрактам часто требуются более крупные фрагменты для сохранения условной логики.
После разбиения каждый фрагмент преобразуется в эмбеддинг (embedding). Это означает пропуск текста через модель, которая выдает список чисел, вектор, представляющий семантическое значение фрагмента. Похожие идеи оказываются рядом друг с другом в этом математическом пространстве. «Политика софинансирования 401k» и «правила пенсионных отчислений» будут находиться ближе друг к другу, чем «политика софинансирования 401k» и «настройка офисного принтера». Эти векторы хранятся в векторной базе данных (vector database), такой как Pinecone, Weaviate или в open-source альтернативе вроде Chroma. Векторное хранилище — это не просто свалка данных. Это индекс, оптимизированный для поиска ближайших соседей (approximate nearest-neighbor search), что позволяет находить наиболее релевантные фрагменты за миллисекунды даже среди миллионов документов.
Этап 2: Оперативный путь (Online)
Когда пользователь наконец спрашивает: «Какова наша политика возмещения командировочных расходов на ужины с клиентами?», запускается live-пайплайн.
Этот