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

Эта статья родилась из работы над AlpinaGPT. Мы недавно зарелизили в нём по-настоящему крутых AI-ассистентов и AI-проекты: с подключаемыми базами знаний, общим контекстом чатов и нормальной памятью между сессиями. Я начал смотреть, как RAG сделан у других — и оказалось, что во многих продуктах на рынке всё гораздо проще и грубее, чем нам кажется. 

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

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

Спектр RAG-архитектур: от простого к сложному

RAG — не одна конкретная архитектура, а спектр подходов разной степени сложности.

Naive RAG — запрос, поиск, ответ. Работает для однородных текстов с простыми вопросами. Ломается, как только данные становятся разнородными или от ответа зависит что-то важное.

Advanced RAG — добавляется переранжирование, гибридный поиск (вектор + BM25), декомпозиция запроса. Качество растёт, сложность тоже.

GraphRAG — документы связываются в граф. Хорош для данных со сложными связями: оргструктуры, юридические документы с перекрёстными ссылками.

Agentic RAG — LLM сама решает, нужно ли обращаться к базе знаний и какой запрос сформировать. Не слепой pre-query, а осознанный вызов через function calling.

Из практики: 80% корпоративных задач закрывается ассистентом с хорошим RAG — без единого агента. GraphRAG и Agentic RAG почти никогда не оправдывают свою сложность на старте. Я видел десятки проектов, где команда начинала с GraphRAG, потому что «данные связаны», и через полгода откатывалась к Advanced RAG с метаданными — работало не хуже, а поддерживалось в три раза дешевле. Принцип: начинай с простого, усложняй только при измеримой проблеме.

Четыре причины, по которым RAG ломается в enterprise

В презентациях RAG выглядит просто: документы → эмбеддинги → вектор → поиск → ответ. В реальности между каждой стрелочкой — источник отказов. Четыре категории проблем, которые возникают регулярно при корпоративных внедрениях:

1. Data Engineering: бардак на входе — бардак на выходе

Самая частая и самая недооценённая проблема. Компания приходит с запросом: «Сделайте нам базу знаний» и передаёт 10 000 документов. Из них:

• 30% — устаревшие версии (но никто не знает, какие).

• 20% — дубликаты с минимальными отличиями.

• 15% — PDF-сканы с артефактами OCR.

• у большинства нет метаданных: ни даты обновления, ни автора, ни отдела.

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

На одном из проектов нам передали базу из 12 000 документов с пометкой «актуальное». После аудита осталось около 3 800. Больше двух третей оказались непригодны: дубликаты с косметическими правками, устаревшие версии без маркировки, презентации в PDF, которые никто не открывал с 2020 года, черновики, которые случайно попали в «утверждённую» папку. Первое, что мы сделали — выбросили три четверти базы. Качество retrieval выросло кратно без единой строчки нового кода.

Чтобы масштаб был понятен: в AlpinaGPT сегодня 8000+ пользователей и 40+ корпоративных клиентов. У каждого крупного клиента — своя база знаний, свои регламенты, свои дубликаты с косметическими правками. И на каждом новом внедрении первый месяц — это не про модель, это про аудит и чистку данных. Закономерность ни разу не нарушилась.

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

Решение начинается не с кода, а с аудита данных. Версионирование, дедупликация, обогащение метаданными — неблагодарная работа, которую хочется пропустить. Но без неё всё остальное бессмысленно.

2. Retrieval Quality: не то нашли

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

Эмбеддинг-модели для русского — отдельная боль. OpenAI text-embedding-3-large работает, но заметно хуже, чем на английском, особенно на узкоспециальной лексике. На русских доменах у нас стабильно лучше работают multilingual-e5-large и jina-embeddings-v3 — это по нашим замерам конца 2025 года, рынок меняется быстро. Если домен узкий (юридический, медицинский, корпоративные регламенты), имеет смысл дообучать эмбеддер на своих данных.

И всегда пробуйте гибрид вектор + BM25. Чисто векторный поиск проседает на запросах типа «найди пункт 4.2.1 регламента №47» — семантически такой запрос может оказаться дальше от нужного документа, чем десяток нерелевантных. BM25 находит его мгновенно по буквальному совпадению. Хорошо настроенный гибрид закрывает оба сценария.

3. Eval & Monitoring: тихая деградация

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

Без системы оценки качества RAG деградирует незаметно. Нет алертов — нет проблемы. Пока кто-нибудь не обнаружит, что система три недели выдаёт неправильные ответы на вопросы о новой политике отпусков.

Минимальный набор метрик (из фреймворка RAGAS и аналогов):

Faithfulness — ответ соответствует найденным фрагментам? Не додумала ли модель лишнего?

Answer Relevancy — ответ релевантен заданному вопросу?

Context Recall — все ли значимые фрагменты, нужные для ответа, нашлись в выдаче?

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

Отдельно стоит упомянуть новую метрику в RAGAS — Noise Sensitivity (появилась в v0.2). Она измеряет, как качество ответа падает при добавлении нерелевантных документов в контекст. На enterprise-данных эта метрика полезнее стандартных: она реально показывает, насколько система устойчива к «шуму» в базе, а в корпоративной базе шума всегда больше, чем хочется признавать.

4. Structural Limits: RAG — это не CRUD

RAG по своей природе — read-only система, работающая со снепшотами данных. Это важное ограничение, которое часто игнорируют.

RAG не умеет:

• отслеживать изменения в реальном времени.

• обновлять данные (только переиндексация).

• гарантировать актуальность ответа.

Для базы знаний с документацией, которая обновляется раз в квартал — не проблема. Для системы, работающей с часто меняющимися данными (тикеты, статусы, цены) — фундаментальное ограничение, которое нужно учитывать на этапе проектирования.

Качество RAG начинается с чанкинга

Это ядро всей проблемы и одновременно — область, где больше всего мифов и антипаттернов. Чанкинг — нарезка документов на фрагменты для индексации — определяет, что попадёт в контекст LLM и, следовательно, что окажется в ответе.

Стратегии чанкинга

Fixed-size + overlap — нарезка по N токенов с перекрытием. Просто, предсказуемо, работает для однородного текста. Перекрытие (overlap) нужно, чтобы не «разрезать» мысль на границе чанков. Типичные параметры: 500–1000 токенов, overlap 10–20%.

Semantic chunking — разбивка по смысловым границам: абзацам, разделам, логическим блокам. Точнее, чем fixed-size, но сложнее в реализации. Требует понимания структуры документа.

Parent-Child — рекомендованная стратегия для большинства случаев. Маленький чанк используется для поиска (высокая точность), но в контекст LLM отправляется широкий родительский фрагмент (полнота). Точность поиска + полнота контекста = лучший результат.

Sentence window — ищем по предложению, но передаём в LLM окно из ±N предложений вокруг найденного. Хорош для FAQ-систем и баз знаний с короткими атомарными ответами.

Антипаттерны: как не надо

PDF на 80 страниц = один чанк. 

Встречается чаще, чем хотелось бы. Весь документ — один вектор. Не влезет в контекст, смысл потеряется, релевантность поиска — на уровне случайности.

Чанки без метаданных. 

Фрагмент текста попадает в базу без информации о том, откуда он взят: нет названия документа, нет раздела, нет даты. Модель находит фрагмент, но не может оценить его актуальность и контекст. «Процедура возврата: в течение 14 дней» — из какого документа? Какого года? Для какого продукта?

Нет overlap — смысл разрезается. 

Определение термина оказалось в одном чанке, а пример его использования — в следующем. Модель находит определение, но не понимает контекст. Перекрытие решает проблему, но добавляет объём базы.

Грязные данные в индексе. 

Колонтитулы, нумерация страниц, артефакты OCR-распознавания, скрытые символы из Word-документов — всё это попадает в чанки и загрязняет поиск. Мусор на входе — мусор на выходе. Парсинг и очистка данных ДО индексации — обязательный этап, который пропускают в 80% проектов.

Главное правило

Что работает для PDF — не подойдёт для таблиц. Что работает для регламентов — не подойдёт для кода. Мелкие чанки — не универсальный ответ. Стратегия чанкинга подбирается под конкретный тип данных и конкретные паттерны запросов.

Чтобы не быть голословным — вот что работает у нас на практике. На регламентах и юридической документации лучше всего ложится Parent-Child: child chunk 200–300 токенов для точного поиска, parent 1500–2000 токенов идёт в контекст LLM. На технической документации (API-доки, SDK, инженерные инструкции) — fixed-size 500 токенов с overlap 100. На кодовых базах — semantic по функциям и классам, fixed-size не использую совсем, он разрезает логические единицы. На FAQ и базах коротких ответов — sentence window. Универсальной конфигурации не существует, это каждый раз эксперимент на 2–3 итерации, но стартовать с этих значений быстрее, чем с дефолтов из туториалов.

Нативный RAG vs Tool-based RAG: два подхода к поиску

Различие принципиальное, и выбор между ними определяет качество системы больше, чем выбор модели.

Нативный RAG работает просто: при каждом запросе система автоматически ищет в базе и подставляет найденные фрагменты в промпт до вызова LLM. Предсказуемо, но слепо — на: «Привет, как дела?» RAG послушно лезет в базу, тратит токены и засоряет контекст мусором.

Tool-based RAG устроен иначе: LLM сама решает, нужно ли обращаться к базе, формулирует поисковый запрос и вызывает RAG через function calling. Может сделать несколько вызовов с разными запросами по одной задаче.

Переход с нативного на tool-based даёт кратный прирост качества — в наших проектах разница доходит до 70%.

Отдельно про парсинг: PDF, DOCX, XLSX, HTML, Markdown — каждый формат требует своего подхода. Хороший парсер конвертирует файлы в чистый markdown/JSON, удаляет мусор, сохраняет структуру, обогащает метаданными. Два дня на нормальный парсер экономят месяцы борьбы с артефактами в поиске.

Практический чеклист: как внедрять RAG правильно

• До разработки: аудит данных (что есть, в каком формате, насколько актуально), анализ запросов, метрики качества определены заранее.

• Данные: очистка от дубликатов и устаревших версий, обогащение метаданными (источник, дата, раздел, автор), парсер с сохранением структуры.

• Архитектура: стартуем с naive или tool-based RAG, чанкинг под тип данных, гибридный поиск вектор + BM25, реранкинг.

• Мониторинг: метрики с первого дня, алерты на деградацию, регулярная переиндексация.

RAG — это задача data engineering в AI-обёртке. Если у вас бардак в данных, никакая модель, даже самая дорогая, вас не спасёт. Задача, которую вы решаете — это задача данных, а не задача модели. Тот, кто понимает это с первого дня, сэкономит месяцы работы и бюджет.

Если у вас в компании сейчас стоит задача внедрения RAG — мы готовы помочь её разобрать. В AlpinaGPT RAG реализован через ИИ-ассистентов с подключаемыми базами знаний компании: загружаете регламенты, документацию, внутренние материалы — ассистент работает с ними, в одном корпоративном контуре, без VPN и по 152-ФЗ. Если хочется посмотреть демо на ваших документах или обсудить on-premise-внедрение под закрытый контур — напишите, разберём конкретно вашу задачу: какой объём данных, какая стратегия чанкинга подходит под ваш тип документов, где у вас сейчас узкое место.

Больше кейсов по корпоративному внедрению ИИ — в Телеграм-канал «Дело в промпте». Там разбираем конкретные тренды, промпты и анти-паттерны внедрения ИИ в бизнес-процессы.