Первый этап RAG начинается не с генерации ответа, а с подготовки документов к поиску. Система принимает исходные материалы: PDF, DOCX, HTML-страницы, базы знаний, инструкции, переписки, регламенты. Затем из них извлекается текст, удаляются служебные элементы, повторяющиеся колонтитулы, мусорные символы и фрагменты без смысловой нагрузки.
После очистки документ делится на небольшие смысловые блоки — чанки. Обычно это фрагменты по 300–1000 токенов, чтобы в одном блоке сохранялась законченная мысль: определение, правило, этап процесса, ответ на типовой вопрос. Слишком крупные фрагменты мешают точному поиску, слишком мелкие теряют контекст.
- заголовки и подзаголовки сохраняются как метаданные;
- таблицы преобразуются в текст с понятной структурой;
- для каждого фрагмента фиксируются источник, дата, раздел, автор или версия документа;
- дубли удаляются, чтобы модель не получала противоречивые копии одного ответа.
Далее каждый чанк превращается в embedding — числовой вектор, который отражает смысл текста. Например, фразы «как оформить возврат» и «процедура возврата товара» будут близки в векторном пространстве, даже если в них разные слова. Эти векторы загружаются в векторную базу: FAISS, Milvus, Weaviate, Qdrant, Pinecone или другой индекс.
Когда пользователь задает вопрос, он тоже преобразуется в вектор. Поисковый механизм сравнивает его с векторами документов и выбирает фрагменты с наибольшей смысловой близостью. Часто к этому добавляют фильтры по метаданным: искать только в актуальных инструкциях, только по конкретному продукту или только в документах за определенный период.
Так документы становятся не набором файлов, а поисковой базой, где каждый фрагмент можно быстро найти по смыслу. Именно поэтому работа с нейросетями в RAG меньше зависит от угадывания модели и больше опирается на проверенные источники.
Бесплатный экспресс аудит
Проведём SEO аудит без оплаты. Акция действует до конца августа.
Заказать аудит
Поиск релевантных фрагментов: что происходит перед генерацией ответа
Перед тем как модель начнет формировать ответ, RAG отбирает из базы знаний фрагменты, которые действительно связаны с запросом пользователя. На этом этапе система не «читает» все документы целиком: она работает с заранее подготовленным индексом, где каждый фрагмент представлен в виде вектора — числового отпечатка смысла.
Запрос пользователя проходит ту же обработку: текст очищается, преобразуется в embedding и сравнивается с векторами фрагментов. Чем ближе векторы друг к другу, тем выше вероятность, что найденный отрывок содержит нужные факты. Такой подход позволяет искать не только точные совпадения слов, но и близкие по смыслу формулировки. Например, запрос «условия возврата товара» может найти фрагмент, где написано «покупатель вправе оформить возврат в течение 14 дней».
Обычно поиск включает несколько операций:
- преобразование пользовательского вопроса в вектор;
- поиск ближайших фрагментов в векторной базе;
- отсечение результатов с низкой релевантностью;
- переранжирование найденных фрагментов по смысловой близости и контексту;
- передача лучших отрывков в промпт для генерации ответа.
Качество результата зависит от того, как были нарезаны документы. Слишком крупные фрагменты добавляют лишний шум, а слишком мелкие могут потерять важные связи между абзацами. На практике часто используют блоки по 300–800 токенов с небольшим перекрытием, чтобы сохранить контекст на границах частей.
Дополнительно применяются фильтры по метаданным: дате документа, разделу базы знаний, языку, типу файла, уровню доступа. Это особенно важно, если работа с нейросетями связана с корпоративными данными: модель должна получать только актуальные и разрешенные источники.
После отбора RAG передает модели не весь архив, а компактный набор проверенных фрагментов. Именно они становятся основой будущего ответа и снижают риск выдуманных фактов.
Как модель формирует точный ответ и снижает риск выдуманных фактов
После поиска RAG передает языковой модели не весь архив, а ограниченный набор фрагментов, которые прошли отбор по смысловой близости, фильтрам и метаданным. На этом этапе ответ строится не «из памяти» модели, а на основе найденного контекста: абзацев, таблиц, инструкций, договоров, карточек товаров или внутренних регламентов.
Обычно в запрос к модели добавляют три элемента:
- исходный вопрос пользователя с сохранением формулировки;
- релевантные фрагменты документов с идентификаторами, датами, названиями файлов или ссылками;
- инструкцию: отвечать только по переданному контексту, не подменять отсутствующие данные предположениями.
Чтобы снизить риск выдуманных фактов, система заранее ограничивает модель правилами. Если в найденных материалах нет нужного значения, даты, суммы или условия, корректный ответ должен содержать отказ от утверждения: например, «в предоставленных документах это не указано». Такой сценарий важнее красивой догадки, потому что пользователь получает проверяемый результат, а не правдоподобную ошибку.
Дополнительно применяются технические проверки. Фрагменты ранжируются повторно, дубли удаляются, противоречивые источники помечаются, а слишком слабые совпадения не передаются в генерацию. Если документ устарел, метаданные помогают выбрать более свежую версию. Если вопрос относится к конкретному разделу, фильтр не дает модели смешивать данные из разных продуктов, филиалов или периодов.
Финальный ответ собирается кратко и структурно: модель извлекает нужные факты, связывает их в логичное объяснение и, при необходимости, указывает источник. В результате работа с нейросетями становится более контролируемой: снижается доля галлюцинаций, проще проверять выводы, а ответы можно привязать к конкретным документам, а не к неопределенным знаниям модели.
