Почему стратегии чанкинга решают качество ответов
Границы фрагментов при нарезке часто задаёт не смысл, а счётчик символов — предложение обрывается на середине, условие из первого абзаца уезжает в один фрагмент, вывод — в другой. Модель получает половину мысли и достраивает остальное сама: ответ звучит уверенно, но расходится с документом. Поиск при этом отчитывается, что нужная страница найдена.
Разнородная вёрстка документов усугубляет: заголовок раздела попадает в один фрагмент, его таблица — в следующий, подпись к схеме отрывается от схемы. Это и есть потеря контекста на стыке блоков — непонятно, к какой строке относится цифра и о каком периоде идёт речь. В регламентах и договорах, где смысл держится на связке «пункт — подпункт — примечание», такой разрыв стоит дороже всего.
Перекрытие соседних окон решает одну проблему и создаёт другую — дубли фрагментов в выдаче. Один абзац попадает сразу в несколько кусков, они занимают место в контексте, а факты из других разделов до модели не доходят. Ответ либо повторяет одно и то же, либо опирается на единственный источник.
И отдельно — ответ без подтверждения источником: если фрагмент не хранит привязку к документу, разделу и странице, проверить утверждение нельзя, и в работе такой ответ бесполезен. Поэтому стратегию нарезки подбирают под структуру документов, а не берут по умолчанию: разбираем, как это закрывается.
Эффект от управляемой нарезки: что меняется
Управляемая нарезка проявляется не в отчёте о внедрении, а в ежедневной работе с базой знаний. Ниже — контрольные точки, по которым мы сверяем результат до и после: каждую измеряем на вашем корпусе документов, а не оцениваем на глаз.
- Доля ответов с корректным источником. Разрез посреди пункта регламента или таблицы даёт ответ по обрывку — сослаться на конкретный раздел невозможно. Границы по смысловым блокам возвращают точную ссылку, и разбор обращения занимает минуты.
- Устранённый класс отказов «не хватило контекста». Если вопрос требует двух соседних абзацев, а в индекс попал один, система молчит или додумывает. Перекрытие фрагментов и склейка по структуре убирают этот класс целиком.
- Время сборки базы знаний. Нарезка известными блоками вместо полного пересчёта векторных представлений сокращает первичную сборку с часов до десятков минут и делает её предсказуемой при росте корпуса.
- Обновление документа без полной пересборки. Правка одного приказа пересчитывает только его фрагменты, остальной индекс не трогаем. Новая редакция попадает в ответы в тот же день.
- Качество поиска по регламентам. Метрика — доля запросов, где нужный пункт оказался в начале выдачи. На размеченных регламентах она растёт заметно, потому что фрагмент содержит и условие, и следствие нормы.
Стратегию под каждый тип документа проверяем на разметке: рекурсивный сплиттер из LangChain держит иерархию разделителей, а смысловые границы подключаются там, где структура не размечена.
Стратегии чанкинга: сравнение подходов
Стратегия чанкинга определяет, что именно попадает в контекст модели при поиске. Ошибка здесь не видна в метриках поиска: нужный документ найден, но фрагмент начинается с середины таблицы или теряет заголовок раздела — и модель отвечает уверенно, но неверно. Поэтому стратегию подбирают под структуру корпуса, а не берут «по умолчанию».
Ниже — четыре рабочих варианта и их реальные ограничения. На практике чаще всего рекурсивная нарезка идёт базой, а смысловая проверка границ включается там, где разметка документа не помогает.
| Стратегия | Когда подходит | Ограничения |
|---|---|---|
| Рекурсивная нарезка по структуре | Регламенты, инструкции, договоры с явными заголовками, списками и разделами | На «плоском» тексте без разметки вырождается в фиксированное окно |
| Семантическая нарезка | Аналитика и длинные тексты, где смысловая граница не совпадает с абзацем | Дороже по вычислениям, размер фрагмента нестабилен, нужен порог похожести |
| Нарезка по предложениям | Базы фактов и вопросно-ответные справочники | Мелкие фрагменты теряют контекст, растёт число обращений к хранилищу |
| Фиксированное окно с перекрытием | Однородный текст без разметки: логи, расшифровки, выгрузки | Рвёт смысл на границе, перекрытие раздувает индекс |
Размер фрагмента и перекрытие подбираем по замеру, а не на глаз: собираем набор вопросов с известными правильными фрагментами и смотрим долю попаданий и полноту ответа. Ориентир — фрагмент, который целиком закрывает один вопрос; перекрытие в 10–20% убирает разрывы на границах. Слишком мелкие фрагменты дают точный поиск и обрывочный ответ, слишком крупные — шум в контексте и лишние расходы на обработку.
Этапы работ: от аудита документов до передачи
Работы идут в фиксированном порядке: качество выдачи определяется не моделью, а тем, как нарезан корпус. Каждый этап заканчивается артефактом, который проверяем на контрольной выборке, — поэтому результат не зависит от впечатлений от демонстрации.
- Аудит корпуса документов. Собираем всё, что должно находиться поиском: регламенты, инструкции, договоры, переписку поддержки. Отмечаем форматы, дубли, устаревшие редакции и владельца каждого источника.
- Схема нарезки. Решаем, что считать смысловой единицей — пункт регламента, раздел инструкции или абзац, — и выбираем стратегию чанкинга: рекурсивную по заголовкам, семантическую по смене темы или по предложениям. Перекрытие задаём так, чтобы ответ не рвался на границе фрагментов.
- Контрольная выборка запросов. Берём несколько десятков реальных вопросов с известными правильными ответами и ссылкой на источник. Это эталон для сравнения вариантов нарезки.
- Настройка и прогон. Индексируем корпус и считаем измеримое: доля вопросов, где нужный фрагмент попал в верхушку выдачи, полнота ответа, доля отказов «не знаю».
- Проверка качества выдачи. Разбираем ошибки: разорванные таблицы, потерянный контекст, склейка редакций документа, ответ из устаревшей версии. Правки в схеме — переиндексация и повторный прогон.
- Передача и обучение поддержки. Отдаём документацию по схеме нарезки и регламент обновления: как добавлять документы и когда переиндексировать. Обучаем команду, которая отвечает пользователям.
Артефакты: конфигурация нарезки, схемы и регламенты
После запуска у заказчика остаётся не «сервис под ключом», а комплект, по которому нарезку можно менять своими силами. Ниже — то, что мы передаём вместе с решением и что позволяет не звать подрядчика на каждый новый формат документа.
- Конфигурация нарезки — алгоритм для каждого класса документов: рекурсивное деление по разделителям, семантическое по смене темы или нарезка по границам предложений.
- Правила перекрытия фрагментов — сколько контекста переносится в соседний фрагмент, чтобы ответ не обрывался на стыке разделов, и чем это правило отличается для таблиц и регламентов.
- Схемы обработки документов — маршрут от загрузки файла до записи в индекс Qdrant: парсинг, очистка, разметка метаданными, ветвление по типам источников.
- Правила доступа к документам — какие разделы попадают в общий индекс, какие в закрытые коллекции, как права наследуются из исходной системы.
- Регламент обновления базы — что и когда переиндексируется при правке документа, кто запускает прогон и по каким признакам принимает результат.
- Инструкция для поддержки — типовые отказы: битый парсинг, пустые фрагменты, дубли; что проверяется на каждом шаге и как восстановиться.
- Чек-листы повторного прогона — сверка числа фрагментов до и после, контрольные вопросы к поиску, условие отката на предыдущую версию нарезки.
Артефакты версионируются вместе с кодом и проходят ревью, а не живут в переписке. Повторный прогон на тех же документах собирает тот же индекс — расхождение видно на сверке сразу, а не в ответах ассистента через месяц.
Кейс: нарезка базы знаний с таблицами и вложениями
Задачу принесла служба поддержки: ассистент по внутренней базе отвечал бегло, но ссылался не на тот документ.
Что было в исходной базе
База собиралась годами в Confluence: регламенты, инструкции и коммерческие предложения — текст с таблицами параметров и вложенными списками на несколько уровней. Разбиение шло по фиксированному числу символов, и таблицы регулярно рассыпались между соседними фрагментами. Ассистент возвращал строку «Итого» без шапки или пункт третьего уровня без родительского заголовка: формально похоже, по смыслу мимо. На контрольном наборе из 400 вопросов точность попадания в источник держалась около 64%.
Что изменили и что получилось
Основой стала рекурсивная нарезка: сначала по структурным заголовкам, затем по абзацам и лишь в крайнем случае по предложениям. Таблицы вынесли в отдельные фрагменты с продублированной шапкой, а вложенные списки склеивали с родительским пунктом, чтобы сохранить иерархию. Для плотных текстов без заголовков добавили смысловое разделение по смене темы — соседние абзацы про разные предметы больше не попадают в один блок.
Точность попадания в источник выросла с 64% до 93% на том же наборе вопросов. Доля ответов, где модель ссылалась на нужный документ, но не на ту таблицу, упала в разы, а случаев «фрагмент обрезан на середине строки» не осталось. Вложения, которые раньше выпадали из индекса, теперь обрабатываются с указанием источника. Полная переиндексация корпуса занимает около 40 минут, поэтому обновления уходят в тот же рабочий день.
Что делать, если база уже нарезана старым способом?
Пересборка существующей базы нужна реже, чем кажется. Часть корпуса можно оставить как есть — там старая нарезка не мешает: документы короткие, структура плоская, ответы приходят целиком. Пересобирать стоит те группы, где разрез рвёт смысл: таблицы, регламенты с вложенными пунктами, приложения со списками. Развилку удобно держать в виде трёх решений с разной ценой входа.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полная пересборка | Разметка битая у большинства разделов, структура документов поменялась | Нужен повторный прогон модели по всему корпусу; результат появляется не сразу |
| Частичная замена нарезки | Проблемы сосредоточены в отдельных группах — регламенты, таблицы, приложения | Требуется решить, какие документы переводить, и заново собрать их фрагменты |
| Гибридный режим обработки | Корпус большой, критичные документы уже отвечают корректно | Две схемы живут параллельно, растёт сложность оценки качества ответов |
| Пересборка при плановом обновлении | Документы регулярно переиздаются | Старые ошибки живут до ближайшего обновления |
Миграция без простоя устроена так: новый индекс собирается рядом со старым, на время сборки документы попадают в оба потока, а переключение делается одним переключателем. Пока новый набор не подтвердил качество на контрольных вопросах, сохранение текущего индекса остаётся основным режимом — откат занимает минуты и не требует повторной загрузки файлов.
Гибридный режим обработки — компромисс для больших корпусов: критичные группы идут по новой логике, остальное обслуживает старый индекс. Сложность здесь не в нарезке, а в согласованности двух схем и в понимании, какой ответ пришёл из какой ветки. Начинаем с выборки запросов, где ответы собирались из разорванных фрагментов, — она показывает, какие группы документов переводить первыми.
Частые технические сомнения по нарезке документов
Нарезка редко отказывает на старте — она отказывает на выдаче: ответ собирается из обрывков, таблица приходит без шапки, а ссылка на источник ведёт в середину абзаца. Параметры стратегии чанкинга лежат в конфигурации рядом с обработчиком документов, поэтому на приёмке мы проверяем не «красиво ли нарезано», а поведение поиска на вашем корпусе. Ниже — вопросы, которые инженеры задают чаще всего.
Нужен ли единый размер фрагмента, если документы разной длины?
Единое число — плохой компромисс: короткие регламенты теряют контекст, длинные инструкции рвутся посреди шага. Размер задаём диапазоном и набором правил по типу документа, а смысловые блоки — пункт, шаг, раздел — остаются границей нарезки. Схема при этом одна на корпус, меняются только пороги.
Что происходит с таблицами?
Таблица идёт отдельным типом фрагмента: шапка дублируется в каждый кусок, строки не разрезаются по границе окна, рядом сохраняется заголовок раздела и подпись таблицы. Без этого поиск находит строку, но не понимает, к какому столбцу относится значение.
Как проверить качество нарезки?
Берём контрольный набор вопросов с эталонными источниками и считаем долю попаданий в нужный фрагмент и долю блоков, разорванных по живому. Отдельно смотрим распределение длин: всплеск на границах показывает, что правило режет не по смыслу.
Придётся ли пересобирать базу при смене схемы?
Только для затронутых типов документов — версия схемы хранится рядом с индексом, остальное не трогаем. Нарезка воспроизводима: ту же схему переносим на новый тип документа, меняя лишь правила разбиения.
Обсудим задачу и вернёмся с планом работ
К разговору полезно подготовить корпус документов, по которому будет идти поиск: регламенты, договоры, техническую документацию, базу знаний поддержки — в том виде, в каком они живут сейчас. Важны не только тексты, но и то, как к ним привязаны метаданные: разделы, версии, права доступа. Если есть типовые вопросы пользователей и примеры удачных ответов, они сразу задают планку качества и помогают выбрать стратегии чанкинга под ваш контент.
Дальше работа идёт по шагам, и на каждом мы возвращаемся с промежуточным результатом, а не с отчётом ради отчёта:
- обсуждаем задачу: какие решения должны приниматься по документам и что считается неверным ответом;
- собираем исходные данные: форматы, объёмы, языки, доля сканов и таблиц в корпусе;
- согласуем доступы к документам — тестовый контур или выгрузка обезличенного набора;
- размечаем эталонные вопросы и ответы, чтобы качество поиска измерялось, а не обсуждалось на вкус;
- оцениваем объём работ по каждому блоку: подготовка данных, разбиение на фрагменты, индексация, проверка;
- присылаем оценку и план работ с этапами, сроками и точками приёмки;
- фиксируем, что остаётся у вас после запуска — конфигурации, инструкции, порядок обновления базы знаний.
Если часть данных пока недоступна, начинаем с того, что есть: первый замер по небольшой выборке покажет, где узкие места и сколько времени займёт подготовка остального. Опишите задачу в свободной форме — вернёмся с оценкой объёма и планом работ, где видно, за что отвечает каждая сторона.
