Недавно на Хабре вышла статья про создание RAG-системы для строительных ГОСТов. Команда Цифрового стандарта проделала титаническую работу (полгода вручную разбивали документы на смысловые чанки). Респект за настойчивость и результат.

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

Всем привет! Меня зовут Дима, я делаю ИИ-функции в Gramax. Эта статья для тех, кто сейчас воюет с чанками вручную или пытается найти оптимальный подход. Делюсь нашим путем от быстрого прототипа до продакшен-решения с метриками 95%+.

Шаг 1. Первый запуск: быстро, но криво

Решили сделать умный поиск по документации за счет AI. Загуглили RAG, взяли LangChain, разбили автоматическим делителем на чанки по 150 токенов, закинули в Qdrant, настроили поиск. Стало работать лучше, но не идеально.

Начали изучать проблему. Первое, что бросилось в глаза — чанки:

  • Все были разные (до 150 токенов) и слишком маленькие.

  • Первые 10 чанков частично включали какую-то информацию, но не давали полной картины.

  • Часть чанков была настолько мелкая, что теряла контекст.

Поняли, что так дело не пойдёт.

Шаг 2. Кастомное чанкование: умные правила

Приняли решение увеличить размер чанков до 500 токенов. Чанки стали более полноценными, делились по якорям (заголовкам). Но частенько встречались маленькие чанки до 100 токенов — описание начала файла или короткие секции.

Написали кастомный алгоритм со следующей логикой:

  • Размер чанка — 500 токенов.

  • Если чанк меньше 100 токенов — добавляем токены со следующего якоря до 500.

  • Перекрытие чанков — 15% (конец первого и начало второго содержат общие токены).

Разделение идет по якорям — заголовкам разного уровня (h1, h2, h3). Все автоматически, на основе структуры Markdown. Запустили поиск — стало работать ещё лучше.

Но как понимали, что лучше? Глазками... Это трудозатратно, и все моменты не уследишь. Решили, что нужно продумать объективное тестирование.

Шаг 3. Бенчмарк и метрики: прекратили мерить "глазками"

Как понять, что чанк релевантен заданному вопросу? Нужно придумать вопрос и найти текст, который хотим увидеть в ответе. Пример бенчмарка:

  • Вопрос: "Какая погода в Москве 5-ого февраля?"

  • Ожидаемый текст в ответе:

5 февраля 2026 года в Москве ожидается облачная с прояснениями погода, преимущественно без осадков.
Прогноз температуры воздуха:
11:00 — -14 °C, облачно с прояснениями, влажность 78%, давление 756 мм
15:00 — -12 °C, пасмурно, влажность 74%, давление 756 мм

Создали систему объективной оценки по 3 параметрам.

Триграммы

Разбиваем текст на массивы из трёх подряд идущих слов:

["5", "февраля", "2026"],
["февраля", "2026", "года"],
["2026", "года", "в"]...

Сравниваем пересечение с эталонным ответом. Делаем поправку на перекрытия чанков и неполную идентичность — ставим порог 80%. Если пересечение триграмм > 80% — чанк релевантен.

Recall (полнота)

Проверяем покрытие триграммами найденных чанков текста из бенчмарка. Если метрика > 95% — значит все нужные чанки, которые хотим видеть в ответе, присутствуют в первых 10.

Но есть нюанс. Может быть такое, что нужные чанки окажутся на 7, 8, 9, 10 местах. Это нас не устраивает. Если захотим ускорить работу, придётся уменьшить контекст и брать меньше чанков — тогда нужная информация может не попасть в LLM.

DCG (Discounted Cumulative Gain)

Оцениваем ранжирование. Для каждого набора найденных чанков строим последовательность: 0 — нерелевантный чанк, 1 — релевантный.

Примеры:

  • 1110000000 — DCG = 100% (все релевантные чанки в начале)

  • 0011010100 — хуже, нужные чанки вперемешку с мусором

  • Чем раньше стоят единицы, тем выше DCG

Шаг 4. Метаданные: хлебные крошки для контекста

В Gramax статьи располагаются по иерархии: каталог → раздел → подраздел → статья. Эту иерархию желательно учитывать в поиске, чтобы отслеживать зависимость (древо) информации, а не вырывать из контекста. Пример иерархии:

Москва / Погода / 2026 / Февраль > 5 февраля

5 февраля 2026 года в Москве ожидается облачная с...

Здесь:

  • Москва, Погода, 2026 — разделы и подразделы (папки).

  • Февраль — статья (Markdown-файл).

  • 5 февраля — заголовок внутри документа (h1, h2 или h3).

Поиск должен отследить, что в запросе "Февраль 2026" и вытащить чанк именно оттуда. А не из "Февраль 2025".

Но тут главное не переусердствовать. Важно вынести именно смысловую вложенность информации в заголовок каждого чанка. Это помогло векторному поиску находить семантически близкие чанки. При векторизации и семантическом поиске нужные чанки оказываются ближе друг к другу и выводятся первыми в релевантных результатах.

Также применили взвешенный RRF (Reciprocal Rank Fusion), снизив вес лексического поиска относительно семантического в соотношении 1:2. На этом этапе метрики перевалили за 70%, но это ещё не 90%.

Шаг 5. Реранкер: финальный штрих

Подключили модель jina для реранкинга — на вход подается вопрос и 10 чанков, возвращается переупорядоченный список по релевантности.

Критично: запускать на GPU. Изначально на CPU работало медленно — 16 секунд. С батчингом и оптимизацией удалось снизить до 4-5 секунд, но это всё равно много. На GPU (RTX) — меньше 0.02 сек.

В результате релевантность подскочила до 95%+. Более того — просматривая результаты, мы поняли, что иногда поиск находит чанки, которые действительно более релевантны запросу, чем текст из нашего бенчмарка. То есть система работает даже лучше наших ожиданий.

Итоговая архитектура

Мы прошли классический путь:

  1. Сначала быстрый прототип на авто-делителе (работает, но криво).

  2. Привели чанки в человеческий вид (размер, склейка мелких, overlap).

  3. Перестали мерить "глазками" и ввели бенчмарк с понятными метриками (триграммы, Recall, DCG).

  4. Начали реально повышать качество — метаданные (хлебные крошки, иерархия), гибридный поиск (взвешенный RRF).

  5. Финальный штрих — реранкер.

Полный пайплайн выглядит так:

  1. Автоматическое чанкование по 500 токенов с умными правилами.

  2. Добавление метаданных (breadcrumbs).

  3. Векторизация и загрузка в Qdrant.

  4. Гибридный поиск (семантический + лексический через RRF 1:2).

  5. Реранкинг топ-10 результатов.

  6. Подача в LLM только релевантного контекста.

Никакого ручного деления на чанки. Метрики выше 95%. LLM всегда видит релевантный контекст.

Почему это важно для продукта

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

Когда мы начали внедрять RAG, быстро поняли: качество поиска зависит не только от качества контента, но и от качества чанкования. Плохие чанки → нерелевантные результаты → пользователи не находят нужную информацию.

При этом у нас специфика: пользователи работают в визуальном редакторе с Markdown-файлами, которые имеют четкую структуру — заголовки разных уровней (h1, h2, h3), списки, таблицы. Это открывает возможности для автоматизации.

Как это работает в продакшене

Сейчас в Gramax чанкование работает автоматически:

  1. Пользователь создаёт документацию в простом интерфейсе визуального редактора и публикует. Фоном создается Markdown-файл и коммитится в Git-хранилище.

  2. Система автоматически парсит структуру — находит все заголовки, определяет иерархию.

  3. Применяются правила чанкования — 500 токенов, склейка маленьких, 15% overlap.

  4. Добавляются хлебные крошки — полный путь по иерархии документов.

  5. Происходит векторизация и индексация в Qdrant.

  6. При поиске — гибридный поиск + реранкинг → топ-10 релевантных чанков

Пользователь просто пишет документацию, поиск работает сам.

Ключевые выводы

Если вы сейчас думаете о внедрении RAG для своей документации:

  1. Автоматизация чанкования реальна — при правильном подходе дает 95%+ точности.

  2. Метрики критически важны — триграммы, Recall, DCG избавят от "оценки глазками".

  3. Реранкер решает — последний шаг, который поднимает точность с 70% до 95%+.

В Gramax весь этот путь уже пройден. Мы потратили месяцы на эксперименты, метрики, оптимизацию. Чтобы вам не пришлось.

Открыто, бесплатно, и с сообществом

P.S. Если вас заинтересовали технические детали — какие конкретно библиотеки использовали, как настроили Qdrant, как работает реранкер на GPU — пишите в комментариях. Можем сделать подробный технический разбор.

P.P.S. Команде Цифрового стандарта — удачи с проектом! Ваша настойчивость достойна уважения.