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

• Доля проблем в данных: 70–80% всех отказов корпоративного RAG (30% старые версии, 20% дубли, 15% битый OCR)
• Реальный кейс чистки базы: сокращение с 12 000 до 3 800 документов дало кратный рост точности поиска
• Прирост от Tool-based RAG: до +70% качества ответа при переходе от слепого pre-query к function calling
• Параметры чанкинга регламентов: Parent-Child (поисковый child 200–300 токенов, контекстный parent 1500–2000)

Развивая 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](https://academy.hamidun.com) и на разборах архитектуры в [Vibe Club](https://hamidun.com/club).