Что не искать в RAG: какие источники портят ответы

Где RAG сбивается

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

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

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

Временные файлы вредят еще тише. Кусок текста из файла вроде faq_new_final2 может попасть в индекс без заголовка, даты и автора. Поиск находит удачный фрагмент, но не понимает, что это обрывок без начала и конца. Модель достраивает недостающее сама. Так появляется уверенный ответ, который опирается на мусор.

Обычно RAG ошибается в четырех случаях:

• берет незавершенную версию вместо рабочей
• считает чат равным регламенту
• вытаскивает обрывок из временного файла
• не видит статус документа и срок его действия

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

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

Какие источники убрать из поиска

Хуже всего RAG портят не откровенно неверные документы, а почти правильные. Система находит знакомые слова, видит похожий контекст и вытаскивает текст, который уже устарел, был промежуточной версией или вообще не предназначался для базы знаний. Из-за этого ответ звучит убедительно, но ведет человека не туда.

Первое, что стоит убрать, - все, что не прошло финальное согласование. Черновики с именами вроде draft, v2 или final-final часто содержат старые формулировки, спорные правки и временные решения. Для человека это заметно. Для поиска это обычный документ, который легко попадет в выдачу.

Рабочие чаты и выгрузки из мессенджеров тоже редко подходят для индекса. В них много коротких реплик без контекста: "да, оставляем так", "это уже неактуально", "смотри выше". RAG не видит всей истории обсуждения так, как ее видит участник переписки. Он берет один фрагмент и превращает его в основу ответа.

То же касается временных файлов. Автосохранения, кэш редакторов, копии с пометками tmp, backup или recovery появляются в хранилищах тихо, а вредят сильно. В них легко найти обрывки текста, старые таблицы и случайные куски, которые никто не проверял.

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

Отдельная проблема - дубли. Один и тот же текст часто хранится в PDF, DOCX и HTML, иногда еще и в письме или на wiki-странице. Когда индекс получает пять копий одного документа, он начинает переоценивать этот материал. В ответе модель может повторять один и тот же тезис, а более свежий документ проиграет по частоте совпадений.

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

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

Почему шум побеждает полезные документы

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

Из-за этого сухой утвержденный регламент легко проигрывает живому чату. Чат ближе к реальному вопросу: в нем те же формулировки, те же ошибки пользователя, те же названия кнопок и полей. Регламент пишет юрист или методолог, а сотрудник в переписке пишет так, как спрашивают люди. Для ретривера такой кусок выглядит точнее, даже если это спор без финального решения.

Проблему усиливает чанкинг. Когда система режет документы на абзацы или короткие блоки, она часто отрывает полезный текст от пометки "не использовать", "устарело" или "заменено новой версией". В индекс попадает чистый абзац с хорошими совпадениями слов, а предупреждение остается в другом чанке и уже не участвует в поиске. Модель видит убедительный фрагмент и не понимает, что рядом был запрет.

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

У модели нет встроенного чувства иерархии документов. Она не знает, кто утвердил файл, когда его обновили и почему один источник важнее другого. Если вы не передали метаданные в поиск и не настроили фильтры, для нее заметка из личной папки и официальный документ почти равны.

Хуже всего то, что шум часто выглядит правдоподобно. Черновик может содержать более конкретный ответ, чем официальный текст. Временный файл может включать точные названия полей API. Старый чат поддержки может почти слово в слово повторять вопрос пользователя. Ретривер любит такую близость. Бизнесу же нужен не самый похожий текст, а тот, которому можно верить.

Если база знаний не различает утвержденные документы, обсуждения и рабочий мусор, качество ответов падает даже при хорошей модели. Ошибка начинается не в генерации, а раньше - в тот момент, когда поиск поднял не тот контекст.

Как собрать список "не искать"

Список "не искать" собирают не по ощущению, а по карте источников. Сначала выпишите все места, откуда индексатор вообще может забирать данные: папки в файловом хранилище, экспорт из Confluence, тикеты, чаты, вложения из почты, старые архивы, временные выгрузки. У многих команд уже на этом шаге всплывает главная проблема: в индекс попадает все подряд, хотя утвержденные документы лежат только в двух-трех местах.

Потом отделите финальные версии от рабочего шума. Если инструкция лежит в папке approved, а рядом есть draft, tmp, old или copy, индексатор должен видеть только первую. То же касается чатов, заметок после созвона, промежуточных таблиц и файлов вроде faq_new_final_7. Люди понимают, что это черновик. Поиск часто не понимает.

Какие правила обычно работают

Хороший список исключений редко бывает длинным. Обычно хватает нескольких простых правил:

• исключать пути и папки, где лежат черновики, архивы и временные файлы
• не брать документы без статуса approved или другого признака утверждения
• убирать типы файлов с шумом: личные заметки, экспорт чатов, автосохранения, старые CSV-выгрузки
• ограничивать документы по дате, если старые версии только путают поиск
• исключать записи с тегами internal, raw, discussion, если они не нужны для ответов

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

Проверяйте на реальных вопросах

Дальше нужен короткий тест. Возьмите 20-30 частых вопросов, которые люди реально задают: про возврат, тариф, лимиты, условия интеграции, сроки ответа поддержки. Прогоните их до фильтрации и после нее. Смотрите не только на точность ответа, но и на то, какие документы поиск поднял в контекст.

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

Чтобы команда не спорила вслепую, сохраните причины исключения в простой таблице: источник, правило, почему убрали, кто согласовал, когда пересмотреть. Например: /support/drafts/ - исключили, потому что там лежат незакрытые правки; chat_export_june - исключили, потому что сотрудники спорили о версии политики. Через месяц такая таблица экономит часы и помогает спокойно пересматривать правила.

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

Пример на базе поддержки

В службе поддержки одна и та же тема часто живет сразу в нескольких местах. Есть утвержденная статья в базе знаний. Есть чат смены, где операторы пишут догадки и быстрые советы. И есть папка temp, куда кто-то когда-то сложил выгрузку по платежам для разовой проверки.

Теперь представим обычный вопрос пользователя: как вернуть ошибочный платеж. Формулировка короткая, слова знакомые, и RAG ищет по совпадениям. Проблема в том, что совпадения не равны надежности.

Что произошло без фильтра

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

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

Модель читает найденный фрагмент и строит ответ вокруг догадки оператора. Она советует сразу оформить ручной возврат, не проверив статус транзакции и причину сбоя. Пользователь получает уверенный, но неверный ответ. Если агент поддержки повторит его в работе, компания рискует сделать лишний возврат или сломать учет.

Что изменилось после фильтра

Команда добавляет простой список неиндексируемых источников. Из поиска убирают чат смены целиком, потому что там нет утвержденных правил. Папку temp тоже исключают: это рабочий мусор, а не база знаний. В индексе остается статья, которую владелец процесса проверил и обновил.

После этого тот же вопрос дает другой набор фрагментов. RAG берет утвержденную инструкцию, а не случайную реплику. Ответ становится спокойнее и точнее: сначала проверить статус платежа, потом выбрать нужный сценарий возврата, а если статус спорный - передать случай на ручную проверку.

Этот пример хорошо показывает простую вещь: список того, что не искать, не менее важен, чем список того, что искать. Один чат с похожими словами может испортить ответ сильнее, чем десять полезных документов помогут. Если источник не создан для правил и не прошел проверку, ему не место в индексе.

Где команды ошибаются

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

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

Вторая ошибка проще и опаснее: смотреть только на расширение файла. Команда исключает .tmp и .bak, но спокойно индексирует экспорт из чата в .html, .txt или .md. Внутри такого файла может лежать спор, черновой ответ, обрывки фраз и реплики без контекста. Формально это обычный текстовый файл, по смыслу - шум.

Третья проблема - автосохранения рядом с рабочим документом. Один сотрудник правит регламент, редактор создает копии каждые несколько минут, а индексатор забирает все подряд. В базе появляются версии, которые отличаются одной строкой, одной датой или одной незакрытой правкой. Поиск видит много почти одинаковых документов и начинает путаться.

Отдельно команды часто не разводят статусы. "Утверждено" и "в работе" лежат в одном индексе без меток, даты и владельца. Для человека разница заметна по названию папки. Для ретривера - не всегда. В результате ответ может опереться на черновик, даже если рядом есть финальная версия.

Еще один частый промах - дубликаты в нескольких форматах. Один и тот же текст хранится как DOCX, PDF, HTML и кусок в wiki. Если не убрать повторы, поиск получает ложный сигнал: будто этот текст важнее других, раз он встречается четыре раза.

Обычно это бьет по ответам так:

• модель цитирует черновую формулировку вместо действующей
• в ответ попадает реплика из чата без решения
• ретривер поднимает три копии одного текста и пропускает полезный документ
• система путает старый шаблон с текущим правилом

В поддержке это видно быстро. Например, команда индексирует базу ответов, внутренние чаты и папку с автосохранениями. Клиент спрашивает про возврат, а RAG собирает ответ из старого макроса, обсуждения в чате и незавершенного обновления регламента. Текст выглядит уверенно, но в одном абзаце срок старый, в другом - уже новый.

Для компаний с требованиями по 152-ФЗ и аудитом цена такой ошибки выше. Вопрос не только в качестве ответа, но и в том, какой документ система подняла и почему. Если убрать эти классы шума заранее, фильтрация базы знаний начнет работать заметно лучше, а ответы станут ровнее уже без сложной перенастройки модели.

Быстрые проверки перед индексацией

Хороший индекс редко получается с первого раза. Обычно его портят не сложные ошибки, а обычный беспорядок: файл без владельца, старый черновик рядом с финальной версией, экспорт чата в той же папке, что и утвержденная инструкция. Если команда заранее проверяет такие вещи, качество ответов заметно растет.

У каждого документа должны быть две простые метки: кто за него отвечает и в каком он статусе. Без владельца файл быстро превращается в ничейный артефакт, который годами живет в базе знаний. Без статуса система не понимает, это действующая инструкция, архив, черновик или временная заметка.

Самое рабочее правило для списка "не искать" звучит скучно, но почти всегда помогает: не индексировать то, что люди сами не открыли бы как официальный источник. Папки tmp, drafts и chat-export лучше исключать по умолчанию. В них много текста, но мало фактов, на которые можно опираться в ответе.

Перед загрузкой в индекс хватит короткого чек-листа:

• у каждого файла есть владелец и статус
• поиск не берет папки tmp, drafts и chat-export
• в индексе нет дублей одной инструкции в разных форматах
• тестовые вопросы два дня подряд вытягивают один и тот же основной источник
• команда видит причину, по которой система исключила файл

Пункт с дублями часто недооценивают. Одна и та же инструкция в PDF, DOCX и копии из wiki выглядит безобидно, но retrieval начинает путаться. В итоге модель получает три почти одинаковых фрагмента с мелкими расхождениями и отвечает хуже, чем при одном чистом источнике.

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

Отдельно стоит показывать команде причину исключения файла. Простая пометка вроде "черновик", "нет владельца" или "дубликат" снимает споры быстрее любой презентации. Люди перестают гадать, почему документ пропал из поиска, и начинают исправлять сам источник.

Для команд, которые строят RAG в российском контуре, такая прозрачность особенно полезна. Если система фиксирует, что именно вошло в индекс, а что нет, проще пройти внутреннюю проверку и не тащить в поиск лишние чаты, временные выгрузки и файлы с персональными данными. Так и выглядит нормальная фильтрация базы знаний: меньше мусора на входе, меньше случайных ответов на выходе.

Что делать дальше

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

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

План на ближайший цикл

• найдите 3 источника, где чаще всего встречаются устаревшие версии, обрывки мыслей и служебные заметки
• проставьте им отдельные метки: draft, chat, temp или свои названия, которые команда поймет без пояснений
• соберите короткий набор вопросов из реальной работы поддержки, продаж или внутренней базы
• сравните две версии пайплайна: с этими источниками и без них

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

Отдельные метки для черновиков, чатов и временных файлов полезнее, чем один общий флаг "не индексировать". Так команда видит, какой тип шума бьет по качеству сильнее. Бывает, что черновики почти не мешают, а вот чаты ломают ответы регулярно, потому что в них много догадок, сокращений и фраз без контекста.

Если команда тестирует RAG в РФ, удобно гонять один и тот же набор вопросов через разные модели через единый API и держать логи в российском контуре. Для такого сценария RU LLM подходит как OpenAI-совместимый шлюз: можно менять base_url на api.rullm.com, прогонять одинаковые запросы через разные модели и сравнивать ответы без переделки SDK, кода и промптов.

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

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