Почему мы выкинули 70% корпоративной базы без единой строчки кода: инженерная анатомия enterprise-RAG

Развивая AI-ассистентов и проектные базы знаний в AlpinaGPT (сегодня на платформе более 8 000 активных пользователей и 40+ корпоративных заказчиков), я изучил десятки сторонних реализаций RAG. Почти везде повторяется один сценарий: инженеры за неделю собирают красивый прототип, защищают бюджет, а через месяц после выката в прод система начинает уверенно цитировать отменённые приказы трёхлетней давности и выдумывать несуществующие пункты договоров.

Заказчики пытаются лечить это сменой LLM или модным графовым поиском. Но моя практика показывает жёсткую пропорцию: 80% корпоративных задач отлично закрываются классическим продвинутым RAG с метаданными без переусложнённого GraphRAG, а 70–80% всех сбоев лежат в инженерии данных, а не в весах нейросети.

Почему корпоративный RAG выдаёт галлюцинации и находит устаревшие регламенты?

Между папкой с корпоративными документами и правильным ответом модели лежат четыре системных узких места:

1. Замусоренный входной корпус (Data Engineering): когда клиент выгружает нам 10 000 корпоративных файлов, 30% из них оказываются устаревшими редакциями без дат, 20% — почти полными дубликатами, а 15% — кривыми PDF-сканами с мусором после OCR и колонтитулами. На одном внедрении из 12 000 переданных документов с пометкой «актуальное» после аудита осталось ровно 3 800. Мы просто удалили три четверти файлового кладбища (презентации 2020 года и черновики), и качество выдачи выросло в разы без единого коммита в код. Главное проверочное правило первой недели: посмотреть долю файлов со временем изменения старше одного года.
2. Провалы векторного поиска на русском языке: штатный text-embedding-3-large от OpenAI часто плавает на российской отраслевой терминологии. По нашим замерам, на кириллических регламентах заметно точнее отрабатывают multilingual-e5-large и jina-embeddings-v3. Кроме того, голый векторный поиск теряется на запросах вида «пункт 4.2.1 приказа №47» — здесь обязателен гибридный контур вектор + лексический поиск BM25 с последующим реранкингом.
3. Тихая деградация без мониторинга: база обновляется, и через два месяца точность падает. Помимо базовой тройки метрик RAGAS (Faithfulness, Answer Relevancy, Context Recall), в версии v0.2 появилась критически важная для корпораций метрика Noise Sensitivity — устойчивость ответа к замусоренному контексту. А самый дешёвый ранний индикатор поломки RAG в бою — еженедельный график средней длины ответа в токенах: как только модель перестаёт находить точный факт, она начинает «лить воду» и раздувать абзацы за 2–3 недели до первых жалоб пользователей.
4. Структурный предел: RAG работает со статичными слепками и не заменяет транзакционную базу (CRUD) для остатков на складе или живых цен.

Как устроена правильная нарезка чанков под регламенты, код и FAQ?

Запихнуть 80-страничный PDF в один вектор или нарезать документы без сохранения метаданных (источник, дата, раздел, автор) — гарантированный способ убить поиск. Единого размера чанка не существует, мы подбираем стратегию под физику документа:

• Юридические договоры и внутренние регламенты: стратегия Parent-Child. Поиск идёт по узкому дочернему фрагменту в 200–300 токенов (максимальная кучность попадания), а в промпт модели подставляется широкий родительский блок на 1500–2000 токенов, чтобы не потерять условия и оговорки.
• Инженерная документация и описания API: фиксированное окно Fixed-size по 500 токенов с перекрытием (overlap) в 100 токенов, чтобы не разрезать мысль пополам.
• Исходный код репозиториев: строго семантическая нарезка по границам функций и классов.
• Короткие справочники и базы FAQ: метод Sentence window — ищем по одному предложению, отдаём в модель окно из ±N соседних фраз.

Что делать на практике: почему Tool-based RAG обыгрывает нативный поиск на 70%?

В примитивных реализациях поиск прибит гвоздями перед каждым вызовом модели (Native RAG): пользователь пишет в чат «Привет, как дела?», а система послушно тащит из векторной базы пять случайных кусков устава компании, сжигая токены и сбивая модель с толку.

Мы перевели архитектуру на Tool-based RAG: поисковый движок подключён к модели как внешний инструмент через function calling. Агент сам решает, нужен ли ему поход в базу знаний, сам переформулирует вопрос пользователя в точный поисковый запрос и при необходимости делает 2–3 прицельных вызова к разным коллекциям. В наших проектах один этот переход даёт до 70% прироста качества ответов, а два дня, потраченные на написание чистого парсера DOCX/PDF в структурный Markdown, экономят месяцы борьбы с галлюцинациями. Подробно всю кухню проектирования RAG на pgvector и агентных инструментов мы разбираем на инженерных потоках в Hamidun Academy и на разборах архитектуры в Vibe Club.