Чанкинг и эмбеддинги для RAG: меньше галлюцинаций в регламентах

Откуда берутся «галлюцинации» в ответах по регламентам

Регламенты и инструкции устроены так, что один пропущенный нюанс меняет смысл целого пункта. А модель старается отвечать связно и часто заполняет пробелы привычными формулировками. Поэтому текст звучит уверенно даже тогда, когда фактически неверен.

Контекст чаще всего теряется там, где логика документа важнее близости предложений: в определениях, исключениях («кроме случаев…»), примечаниях, сносках и отсылках на другие пункты. Отдельная проблема - нумерация и вложенные подпункты. Если вытащить только середину, ответ будет правильным по тону, но неправильным по условиям.

Полезно различать два типа ошибок:

• Ошибка поиска: система не нашла нужный фрагмент или нашла похожий, но про другое.
• Ошибка генерации: нужный фрагмент был, но модель пересказала его с изменением смысла или добавила лишнее.

Для внутренней документации «точность» - это не красота формулировки, а проверяемость. Хороший ответ можно быстро сопоставить с конкретным пунктом: он либо цитируем (видно опору на точные фразы), либо явно привязан к номеру раздела и условиям (кто, когда, при каких исключениях). Если такой опоры нет, риск «галлюцинации» растет, даже если текст выглядит убедительно.

Чанкинг простыми словами: почему от него зависит качество ответов

Чанкинг - это нарезка документа на куски (чанки), которые потом участвуют в поиске по эмбеддингам. Модель не читает регламент целиком каждый раз. Сначала система находит несколько подходящих чанков, и уже из них собирает ответ.

Если чанки слишком мелкие, в них не хватает контекста. Например, найдется фраза «согласовать с руководителем», но без условий: для каких случаев, в какие сроки, какие исключения. Ответ получается уверенным, но неполным или неверно обобщенным.

Если чанки слишком крупные, поиск приносит «простыню», где нужный пункт тонет среди похожих формулировок. Модель может пересказать близкий абзац, перепутать номер шага или взять общий раздел вместо точного требования.

Перекрытие (overlap) помогает, когда важная мысль попала на границу двух кусков: конец одного абзаца и начало следующего. Но перекрытие не исправляет плохую структуру. Оно полезно точечно: в инструкциях с короткими шагами, частыми отсылками «см. ниже» и формулировками, которые продолжаются в следующем пункте.

Хороший чанкинг напрямую влияет на цитирование: проще подтянуть ровно тот пункт, где написано требование, и повторить формулировку без «додумываний». Практическая цель простая: найденный чанк должен содержать достаточно контекста, чтобы ответить точно и показать, где это написано.

Стратегии нарезки: что выбирать для инструкций и политик

Для регламентов обычно лучше всего начинать с нарезки по заголовкам и подпунктам. Так сохраняются смысловые границы: пункт 3.2.1 остается целым, а не размазывается по соседним фрагментам. Это особенно важно, если вы делаете Чанкинг и эмбеддинги для RAG и хотите, чтобы поиск попадал в конкретный пункт, а не в общий раздел.

Нарезка фиксированной длины (по символам или токенам) полезна, когда структура документа «сломана»: сканированный текст, плохая разметка, много пустых заголовков. Она дает предсказуемый размер, но чаще теряет контекст: рядом оказываются разные темы, а один смысловой блок может разрезаться посередине.

Нарезка по абзацам звучит логично, но в инструкциях часто ломается на списках шагов. «Шаг 1» и «Шаг 2» по отдельности быстро теряют смысл. Обычно лучше склеивать последовательность шагов в один чанк, пока не сменится подзаголовок или процедура.

Сложные блоки часто выгоднее обрабатывать отдельно. Таблицы стоит превращать в текст так, чтобы значения не жили без заголовков колонок. В формах держите рядом поле и правило заполнения. Приложения лучше индексировать как отдельные секции с явной пометкой вроде «Приложение A».

Отдельного внимания заслуживают «Определения», «Исключения», «Ответственные». Их удобно выделять в самостоятельные чанки и помечать тип секции. Тогда запрос «кто утверждает» не утонет в описании процесса.

Пример: в политике доступа раздел «Исключения» часто ссылается на роли и сроки из основного текста. Если режете по заголовкам, держите ссылочный абзац вместе с ближайшим подпунктом, на который он опирается. Так меньше шансов, что модель «додумает» правило вместо цитаты.

Размер чанка и overlap: как подобрать без угадываний

Размер чанка и overlap определяют, что именно окажется в контексте. Слишком крупно - поиск по эмбеддингам приносит «похожий текст», но не нужный пункт. Слишком мелко - пропадают условия, исключения и отсылки на соседние подпункты. В «Чанкинг и эмбеддинги для RAG» это обычно первая настройка, которая дает заметный прирост точности.

Рабочее правило: начните с нарезки по смысловым границам (заголовки, нумерованные пункты, подпункты), а размер подберите под стиль документа. Для инструкций с короткими пунктами часто хватает 1-2 пункта в чанке (примерно 120-220 слов). Для регламентов с длинными описаниями - 250-450 слов, чтобы внутри были и правило, и уточнение.

Overlap нужен, когда ответ должен опираться на два соседних пункта (например, «кто согласует» в одном подпункте, а «сроки» в следующем). В таких случаях разумно начинать с 10-20%: этого обычно хватает, чтобы «перехватить» границу, не превращая все чанки в почти одинаковые.

Пара простых сигналов, что параметры не подходят:

• Чанк слишком большой: в выдаче много общего текста, а ответы путают условия и исключения.
• Чанк слишком маленький: ответы звучат уверенно, но часто неполные и без оговорок.
• Overlap слишком маленький: пропускаются важные фразы на стыке пунктов.
• Overlap слишком большой: поиск возвращает дубликаты, а разнообразия источников в контексте меньше.

Мини-тест: возьмите 10 типовых вопросов по регламенту и посмотрите, попадает ли нужный пункт в top-3 выдачи. Если часто «рядом, но не то» - уменьшайте чанк. Если «то, но без условий» - увеличивайте чанк или добавляйте overlap.

Параметры эмбеддингов: что влияет на попадание в нужный пункт

Эмбеддинги нужны, чтобы сравнивать смысл запроса и фрагмента текста, а не только совпадение слов. Если модель плохо работает с вашим языком или стилем документов, поиск начинает тянуть похожие по форме куски и пропускать нужный пункт. В RAG это быстро превращается в «галлюцинации»: ответ уверенный, но опирается не на тот абзац.

Первое, что проверяют на регламентах и инструкциях, - язык и домен. Универсальная модель может неплохо работать на новостях, но промахиваться в тексте с нумерацией, сокращениями, терминами и канцеляритом. Типичный симптом: запрос про конкретную обязанность постоянно вытаскивает общий раздел «Термины и определения».

Есть и технические вещи, которые легко «сломать» незаметно. Например, вы поменяли модель или размерность, а индекс остался старым - и качество резко падает.

Что стоит проверить в настройках эмбеддингов

Проверьте базовый набор:

• Для документов и запросов используется одна и та же модель (или корректная парная схема, если encoders разные для query и doc).
• Нормализация векторов включена и одинакова везде (часто ожидается cosine similarity с L2-нормализацией).
• Размерность совпадает с тем, что хранит индекс (после смены модели индекс нужно перестроить).
• Модель действительно хорошо работает на русском и на ваших формулировках.
• Длина входа: важные хвосты предложений не обрезаются лимитом токенов.

Отдельная ловушка - разная предобработка текста. Если при индексации вы чистите точки, номера пунктов и «лишние» пробелы, а запрос оставляете как есть, эмбеддинги становятся менее сопоставимыми. Держите одинаковые правила: одинаковая раскладка, одинаковая очистка, одинаковое приведение к единому виду.

Если вы настраиваете Чанкинг и эмбеддинги для RAG, начните с простого: возьмите 20 реальных вопросов, для каждого посмотрите топ-5 найденных фрагментов и отметьте, есть ли среди них точный пункт регламента. Это быстро показывает, проблема в эмбеддингах или уже в нарезке и поиске.

Настройки поиска: top-k, пороги и метаданные

Даже при хорошей нарезке качество RAG часто ломается на этапе retrieval: в контекст попадают не те фрагменты или их слишком много, и модель начинает «склеивать» ответ. Поэтому настройки поиска стоит проверять так же внимательно, как чанкинг и эмбеддинги для RAG.

Top-k - это сколько фрагментов вы кладете в контекст. Больше не всегда лучше. Если регламент длинный и пункты похожи (например, «срок согласования» в разных процедурах), лишние фрагменты создают шум, и модель выбирает «самый убедительный», а не правильный. Обычно удобно начинать с 3-5 и увеличивать только если вопрос регулярно требует нескольких пунктов сразу.

Порог по похожести (similarity threshold) помогает не угадывать. Если лучший найденный фрагмент ниже порога, лучше честно отказать в ответе или запросить уточнение (версия документа, подразделение), чем выдавать красивую, но неверную формулировку. Для регламентов это критично: одна цифра или условие меняют смысл.

Реранкинг - это «второй судья». Сначала быстрый поиск по эмбеддингам находит кандидатов, затем реранкер перечитывает их и переставляет ближе к вопросу. Он особенно полезен, когда пункты похожи по словам, но отличаются условиями.

Метаданные снижают количество ошибок сильнее, чем кажется. Часто помогают фильтры по:

• версии документа и дате действия
• подразделению или филиалу
• типу процедуры (закупка, отпуск, ИБ)
• языку документа
• статусу (черновик/утвержден)

Наконец, смешанный поиск (ключевые слова + эмбеддинги) хорошо работает на терминах, кодах и номерах пунктов: «ISO 9001», «п. 4.2.1», «S200», внутренние коды форм. Эмбеддинги ловят смысл, а ключевые слова вытаскивают точные совпадения там, где смысловой поиск часто промахивается.

Как проверять качество: простые тесты вместо ощущения «стало лучше»

Когда вы меняете нарезку или модель эмбеддингов, ощущение «стало точнее» легко обманывает. Нужны короткие, повторяемые проверки, которые показывают: система действительно находит правильный пункт регламента еще до того, как начинается генерация.

Соберите небольшой набор вопросов из реальной жизни: обращения в поддержку, спорные ситуации, частые «а что если». Для каждого вопроса заранее отметьте, какие именно пункты регламента считаются правильной опорой (1-3 фрагмента). Это будет эталон.

Дальше гоняйте один и тот же набор на разных вариантах (другая длина чанка, другой overlap, другая модель). Результаты лучше фиксировать в таблице, а не «на глаз».

Retrieval полезно оценивать отдельно от генерации:

• попал ли правильный пункт в top-k выдачи
• на какой позиции он оказался
• сколько в выдаче «похожих, но не тех» фрагментов
• бывают ли случаи, когда нужный пункт вообще не найден

Отдельно оцените качество уже сгенерированного ответа, но простыми метриками: точность (не противоречит регламенту), полнота (учтены важные условия) и «лишняя уверенность» (категоричный тон при слабой опоре).

Пример: вопрос про возврат и исключения. Если система стабильно находит общий раздел «Возврат» вместо подпункта «Исключения для вскрытой упаковки», проблема чаще в чанкинге и контексте, а не в «умности» модели. Такие кейсы лучше всего показывают, улучшают ли Чанкинг и эмбеддинги для RAG реальную точность.

Пошагово: как настроить чанкинг и эмбеддинги для RAG

Надежная настройка начинается не с выбора «самой сильной модели», а с понятного конвейера: одинаковые правила подготовки текста, стабильные чанки, проверяемый поиск и короткий цикл улучшений. Если делать это по шагам, «галлюцинаций» становится меньше, потому что ассистент чаще видит нужный пункт целиком.

1. Подготовьте текст так, чтобы структура не потерялась. Сохраните заголовки, нумерацию, подпункты, названия разделов, версии и даты. Если в документе есть отсылки вроде «см. пункт 3.2», оставьте их как текст, иначе связи пропадут.

2. Выберите стратегию нарезки и метаданные. Для регламентов обычно лучше резать по смысловым блокам: раздел - подпункт - абзац. В метаданные добавьте документ, раздел, номер пункта, версию, дату, владельца.

3. Посчитайте эмбеддинги и соберите индекс. Проверьте, что одинаковые фразы из разных документов не «слипаются» из-за одинаковых заголовков.

4. Настройте выдачу контекста: сколько чанков брать и когда «не отвечать». Начните с небольшого top-k, добавьте порог похожести. Реранкинг имеет смысл подключать, если часто путаются близкие пункты.

5. Прогоните тесты и повторите цикл. Возьмите 20-30 типовых вопросов (например, «кто согласует отпуск» или «срок ответа на обращение»), и проверьте: найден ли правильный пункт, не потеряна ли оговорка, нет ли смешивания версий.

Если после правок выросла точность retrieval, ответы почти всегда улучшаются и без смены модели.

Сложные места: PDF, таблицы, нумерация и версии документов

Много ошибок в RAG появляется не из-за модели, а из-за того, как регламент превратили в текст. Особенно это заметно на PDF, таблицах и документах с жесткой нумерацией.

Сканированные PDF после OCR часто теряют структуру: склеиваются слова, пропадают переносы, путаются колонки. В результате эмбеддинг «видит» кашу и хуже попадает в нужный пункт. Минимум, который стоит сделать: прогнать OCR с сохранением абзацев и проверить вручную несколько страниц, где есть таблицы и списки.

Нумерация и подпункты (например, 2.3.1) важны не меньше текста. Если при нарезке вы удаляете номера или не «приклеиваете» заголовок раздела, смысл теряется. Хорошая практика - хранить номер пункта и заголовки как часть текста чанка, а не только в метаданных.

С таблицами проблема в том, что запрос обычно содержит заголовок колонки, а ответ лежит в ячейке. Если заголовки не попали в тот же фрагмент, retrieval не найдет строку.

Таблицы: как подготовить, чтобы находилось

Чаще всего помогает один из вариантов:

• превращать каждую строку в короткий «паспорт»: заголовки + значения + контекст раздела
• дублировать заголовки колонок в каждой строке (текста станет больше, но попадание улучшается)
• выносить ключевые поля отдельными фразами, если ячейки очень короткие

Версионность критична для регламентов: ответы по устаревшей редакции выглядят как «галлюцинации». Держите в метаданных дату, номер версии, статус (действует/архив), и по умолчанию фильтруйте поиск по «действует».

Короткие команды в инструкциях («Нажмите», «Откройте», «Проверьте») легко смешать, если чанк захватывает шаги из разных процедур. Нарезайте по границам процедур и добавляйте в каждый шаг название процедуры и условия применения (для кого, в какой системе), чтобы шаг не жил отдельно от контекста.

Частые ошибки и ловушки, которые ухудшают точность

Самая частая причина промахов в RAG - не «плохая модель», а то, как вы подали ей текст. Когда регламенты нарезаны неудачно, поиск по эмбеддингам приносит близкий по словам фрагмент, но не тот пункт, на который должен опираться ответ.

Типовые ловушки:

• Нарезали «по 1000 символов» и разрезали смысл: заголовок остался в одном чанке, подпункты в другом.
• Сделали overlap слишком большим: система получает почти одинаковые куски, и модель смешивает соседние формулировки.
• Слепили разные документы в один чанк или не сохранили метаданные (название, версия, раздел): ответ может оказаться из другой политики.
• Не настроили отказ: когда ничего подходящего не найдено, система все равно «придумывает» ответ уверенным тоном.
• Проверяли на «красивых» вопросах: пользователи пишут иначе, с сокращениями и бытовыми словами, и retrieval промахивается.

Простой пример: в инструкции есть раздел «Командировки» и подпункт «Суточные». Если заголовок отрезали, чанк с цифрами суточных выглядит как случайная таблица, и поиск вытаскивает похожие числа из «Представительских расходов».

Быстрые меры обычно те же: режьте по структуре (заголовок плюс подпункты), держите overlap умеренным, храните метаданные как фильтры, добавьте правило «нет источника - нет ответа», и тестируйте на реальных формулировках из чатов и тикетов.

Быстрый чек-лист перед пилотом

Перед пилотом важно не просто «подкрутить параметры», а договориться о правилах, по которым система находит нужный пункт и честно говорит, когда опоры в тексте нет. Для инструкций и регламентов ответ без привязки к конкретному пункту почти всегда превращается в догадку.

Проверьте базовые вещи один раз, а дальше меняйте настройки только через тесты:

• Нарезка повторяет структуру документа: разделы, пункты, подпункты.
• В каждом чанке есть минимум для проверки: номер пункта, заголовок и короткий контекст.
• Текст очищается одинаково при индексации и при обработке запросов.
• Поиск настроен на аккуратность: выбран top-k, есть порог схожести и понятный режим «основания не найдено».
• Есть тестовый набор вопросов (15-30), который вы запускаете после каждого изменения.

Практический прием: возьмите 5 типовых вопросов от пользователей и проверьте, попадает ли в top-3 тот самый пункт регламента, который вы бы процитировали вручную. Если нет, пилот лучше отложить, пока не исправите нарезку или пороги.

Пример из практики: один регламент, два подхода к нарезке

Ситуация простая: сотрудник пишет в чат-бот, как согласовать закупку на определенную сумму и есть ли исключения (например, срочная поломка или закупка у единственного поставщика). Регламент один, но в нем есть общее правило в начале и отдельный подпункт с исключениями дальше.

До настройки система часто отвечала «по умолчанию»: брала общий абзац про лимиты и согласование и подавала его как единственно верный. Исключение из другого места документа не попадало в подборку, и модель начинала «додумывать» детали: кто согласует, какие сроки, какие документы приложить.

Что изменили в нарезке:

• разрезали документ по подпунктам, сохранив нумерацию (например, 3.2.1, 3.2.2)
• вынесли определения и исключения в отдельные чанки, даже если они короткие
• добавили в чанк короткую «шапку» с названием раздела, чтобы не терялся контекст

Проверка была приземленной: до генерации смотрели, попал ли нужный подпункт (про исключения) в top-3 результатов поиска по эмбеддингам на запросы вроде «закупка выше лимита, но срочно».

Результат глазами пользователя: ответы стали чаще опираться на конкретные пункты и формулировки, а не на пересказ «примерно как помнится». И если исключение не находилось, это было видно сразу на этапе retrieval, а не после уверенного, но ошибочного текста.

Следующие шаги: как превратить настройки в рабочий процесс

Чтобы чанкинг и эмбеддинги не оставались «настройками в ноутбуке», начните с узкого, но реального кейса. Возьмите 1-2 приоритетных документа и один сценарий вопросов, который задают чаще всего: «что делать при инциденте», «кто согласует», «какие сроки».

Соберите небольшой пилот и заранее договоритесь, что считается успехом. Важно отдельно определить недопустимые ошибки (например, перепутанные сроки или требования безопасности) и то, как вы будете ловить их до запуска.

План на 2-3 недели можно держать простым:

• Выберите один регламент и один тип вопросов (FAQ от сотрудников или ответы для службы поддержки).
• Соберите тестовый набор из 30-50 вопросов с эталонными пунктами.
• Зафиксируйте метрики: попадание в нужный пункт в top-k, долю ответов «не знаю», количество ложных ссылок на пункты.
• Назначьте владельца качества: кто принимает изменения в нарезке, эмбеддингах и поиске.

Затем продумайте «жизнь после пилота»: где будет жить индекс, как обновлять версии документов, что делать при изменении регламента. Хорошее правило - обновление документа должно автоматически запускать переиндексацию и короткую регрессионную проверку на тестовом наборе.

Если нужен проект «под ключ», часто проще подключать системного интегратора, который умеет работать с корпоративными требованиями: доступы, аудит, хранение данных, эксплуатация.

Для on-prem сценариев можно опереться на инфраструктуру и поддержку GSE.kz (gse.kz): серверы и рабочие станции для развертывания RAG, услуги системной интеграции и 24/7 сервис, чтобы пилот не зависел от одного инженера и не ломался при обновлениях.