Меня зовут Жемал Хамидун, я Head of AI в Alpina Digital и CPO AlpinaGPT, веду тг-канал «Готовим ИИшницу». Эта статья выросла из работы над 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-обёртке. Если в данных бардак, никакая модель, даже самая дорогая, вас не спасёт. Вы решаете задачу данных, а не задачу модели. Кто понимает это с первого дня, экономит месяцы работы и бюджет.
Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →