RAG в enterprise: почему 80% проблем в данных, а не в модели

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

Где ломается RAG

При масштабировании от прототипа к продакшну выясняется неприятная правда: проблемы RAG на 70-80% связаны с управлением данными, индексацией и поиском, а не с возможностями самой языковой модели. Как бы хороша ни была GPT-4 или Claude, если данные индексированы плохо, система будет выдавать неправильные ответы. Это становится видно особенно остро, когда на RAG переходят со 100 на 10 000 документов. Вот реальные причины, почему RAG падает в enterprise: * Путаница версий документов — в индексе остаются старые версии, система не знает, какой документ актуальный. Пользователь получает ответ по регламенту двухлетней давности.

• Потеря контекста — система не помнит, что обсуждалось в предыдущих сообщениях в чате, повторяет одно и то же или противоречит себе.
• Плохой чанкинг — документы нарезаны не по смыслу, а просто по размеру. Логика рассыпается между кусками, система не видит связи.
• Отсутствие переранжирования — BM25 подтягивает много шума, система не различает релевантные документы от случайного совпадения по слову.
• Низкое качество embeddings — векторы обучены на общем корпусе, но не понимают вашу специфику и терминологию.
• Отсутствие feedback-цикла — никто не отслеживает неправильные ответы, система не учится на ошибках.

Как строится правильный RAG В

AlpinaGPT мы шли от противного: сначала собрали требования к идеальной системе, потом посмотрели, какие именно проблемы их блокируют. Результат — архитектура, которая прошла боевые испытания на корпоративных клиентах. Вот ключевые компоненты: * Чанкинг по смыслу — нарезаем не по размеру, а по структуре документа, заголовкам, семантическим блокам.

Так контекст не рассыпается между кусками. * Версионирование данных — каждая версия документа индексируется отдельно с меткой даты. Система знает, какой документ актуальный.

Двухэтапный поиск — сначала быстрый BM25 (ключевые слова), потом переранжирование нейросетью (семантика). Это дешевле, чем искать всё через embeddings. Контекст между сообщениями — система помнит всю историю чата и не повторяет уже объяснённое пользователю.

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

Что это значит RAG будущего — это не просто embeddings и поиск по векторам.

Это управление версионированием документов, правильная семантическая нарезка по смыслу, многоэтапный поиск и постоянная обратная связь. Если в вашем RAG половина ответов неправильная, проблема почти наверняка не в модели GPT-4 или Claude. Проблема в том, как вы подготавливаете данные, как их нарезаете, как индексируете и как собираете обратную связь. Пересмотрите весь этот pipeline — и качество скачет. Это то, что мы выучили на примере AlpinaGPT.