|
Professor Seleznov
|
Жемал Хамидун, 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-обёртке. Если у вас бардак в данных, никакая модель, даже самая дорогая, вас не спасёт. Задача, которую вы решаете — это задача данных, а не задача модели. Тот, кто понимает это с первого дня, сэкономит месяцы работы и бюджет.
Если у вас в компании сейчас стоит задача внедрения RAG — мы готовы помочь её разобрать. В AlpinaGPT RAG реализован через ИИ-ассистентов с подключаемыми базами знаний компании: загружаете регламенты, документацию, внутренние материалы — ассистент работает с ними, в одном корпоративном контуре, без VPN и по 152-ФЗ. Если хочется посмотреть демо на ваших документах или обсудить on-premise-внедрение под закрытый контур — напишите, разберём конкретно вашу задачу: какой объём данных, какая стратегия чанкинга подходит под ваш тип документов, где у вас сейчас узкое место.
Больше кейсов по корпоративному внедрению ИИ — в Телеграм-канал «Дело в промпте». Там разбираем конкретные тренды, промпты и анти-паттерны внедрения ИИ в бизнес-процессы.-Источник
|
