Разбиение по задачам для AI-ассистентов, которые отвечают чисто

Почему чанки на всю страницу дают смешанные ответы

Длинная страница часто решает сразу несколько задач. Сначала там идёт текущее правило, потом добавляется фон, затем показываются примеры, а внизу остаётся старое исключение, потому что его никто не хотел удалять. Когда ассистент получает весь этот блок, он не видит чистое правило. Он получает кучу всего сразу.

Эта куча и приводит к смешанным ответам. Задайте простой вопрос вроде «Может ли клиент получить возврат после 30 дней?» — и ассистент может смешать текущую политику с прошлым исключением, особым корпоративным случаем и примером ответа службы поддержки. Ответ звучит уверенно, но при этом всё равно может быть неверным.

Обычно структура страницы отражает то, как команда публикует документы, а не то, как люди задают вопросы. Авторы группируют контент по отделу, владельцу страницы или структуре меню. Пользователи делают иначе. Они задают узкие вопросы по задаче: «Что мне отправить?» «Кто это утверждает?» «Распространяется ли это на подрядчиков?» Одна длинная страница редко хорошо подходит под такие запросы.

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

Типичная страница выглядит так: в первом разделе сказано, что счета требуют одобрения менеджера, в более позднем абзаце написано, что во время пилота в прошлом году finance принимала прямую отправку, а внизу есть пример обращения в поддержку, где для одного крупного клиента одобрение не нужно.

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

Вот почему чанки на всю страницу создают грязный retrieval. Они склеивают правила, примеры, просроченные заметки и особые случаи, которые должны жить отдельно. Потом ассистент пытается свести всё это в один ответ. Смешанные ответы обычно начинаются именно так.

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

Что пользователи реально спрашивают

Люди не думают названиями страниц. Они пишут проблему обычным языком, обычно одним коротким предложением. Если ваша база знаний организована вокруг названий вроде «Employee handbook» или «Billing policy», ассистенту приходится копать в большом количестве текста, который не совпадает с вопросом.

Реальные логи чата обычно звучат так: «Могу ли я изменить счёт после оплаты?» «Что будет, если я пропущу дату продления?» «Получают ли подрядчики тот же доступ к безопасности, что и сотрудники?» «Можно ли использовать пример клиента в кейсе?» «Кто утверждает возврат свыше $500?»

Эти вопросы уже подсказывают, как делить контент. Каждый из них указывает на задачу: изменить счёт, обработать позднее продление, назначить доступ, использовать историю клиента, утвердить возврат. Это лучший формат, чем целая страница, потому что ассистент может взять ровно то правило, которое нужно, а не тащить за собой фон, старые заметки и боковые случаи.

Именно здесь task-based чанки обычно выигрывают у page-based чанков. Пользователю, который спрашивает про одобрение возврата, не нужен весь финансовый регламент. Ему нужно одно правило, возможно один порог и, может быть, одно исключение. Если дать модели все 2000 слов по этой теме, она может смешать правило по возврату с командировочными, условиями оплаты или устаревшим примером с той же страницы.

Названия документов всё ещё важны, но они должны оставаться на заднем плане. На переднем плане должна быть структура, которая совпадает с тем, что люди пытаются сделать. «Запросить возврат», «сбросить доступ» и «обновить условия контракта» понятнее, чем «Finance policy v3» или «Operations guide».

Помогает простой тест. Прочитайте первое предложение вопроса пользователя и спросите: «Что этот человек пытается сделать прямо сейчас?» Используйте этот ответ как основу для чанка.

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

Как делить контент по задачам

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

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

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

Старайтесь держать полный рабочий ответ вместе. Это значит, что прямой ответ, область действия правила и следующий шаг должны жить в одном чанке. Если правило находится в одном месте, а действие — в другом, ассистент часто выдаёт наполовину правильный ответ. Пользователь получает политику, но не получает шаг, или получает шаг без ограничения.

Крайние случаи должны жить в отдельных чанках. Не прячьте старые исключения, временные обходные решения или региональные правила под основным ответом. Выносите их в отдельные чанки и указывайте, когда они применяются. Так базовый ответ остаётся чистым, а retrieval с большей вероятностью подтянет исключение только тогда, когда вопрос действительно того требует.

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

Держите политику, примеры и исключения отдельно

Когда в одном чанке лежат правило, три примера и два старых крайних случая, ассистент обычно смешивает их в один ответ. Именно так понятная политика превращается в запутанный ответ. Модель видит всё рядом как одинаково важное, даже если одна строка — это настоящее правило, а остальное — просто контекст.

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

Отдельный чанк с примером должен показывать один обычный случай. Выбирайте тот случай, который соответствует тому, о чём спрашивает большинство пользователей. Если ваше правило возврата говорит, что возврат возможен в течение 30 дней при наличии чека, пример должен показывать стандартный возврат, а не праздничное исключение и не повреждённый товар.

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

Практичное разделение выглядит так:

• Политика: только текущее правило
• Пример: один повседневный случай
• Исключение: один редкий случай на чанк
• Даты: когда правило началось, изменилось или закончилось

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

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

Представьте политику компенсации командировок. Текущее правило может разрешать только эконом-класс. Один пример может показать обычную поездку внутри страны. Отдельный чанк с исключением может покрывать согласованные медицинские нужды или срочные поездки к клиенту. Когда эти случаи живут отдельно, ассистент перестаёт смешивать особые согласования с обычными ответами.

Простой формат чанка

Большинство плохих ответов начинается с плохих чанков. Чанк должен отвечать на один реальный вопрос, а не служить складом для всего, что скопировали со страницы.

Используйте вопрос пользователя как заголовок. Пишите его так, как спросил бы человек. «Как сбросить пароль клиента?» лучше, чем «Политика восстановления доступа». Ассистент быстрее сопоставляет вопрос, а ответ обычно остаётся по теме.

Затем сначала дайте короткий ответ. Двух или трёх предложений часто достаточно. Если пользователю нужен только факт, на этом можно остановиться. Если пользователю нужно что-то сделать, добавьте после ответа короткий список шагов.

Question: How do I reset a customer's password?
Answer: Support staff can reset a password after they verify the user's email and last sign-in date.

Steps:
1. Open the admin panel.
2. Check the user's identity.
3. Send the reset link.
4. Log the action.

Limits:
- Do not reset accounts for suspended users.
- Escalate VIP accounts to a manager.
- Rule updated on 2025-02-01.

Tags: audience=support, product=admin panel, process=account recovery

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

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

Это ещё и тот тип структуры, с которым Oleg Sotnikov работает на oleg.is, помогая командам строить AI-workflow и внутренние настройки ассистентов. Чистые чанки не делают модель умнее. Они просто помогают быстрее находить правильный ответ.

Реалистичный пример

Возьмём страницу с расходами на поездки, которая росла годами. Сначала это была обычная политика, потом кто-то добавил примеры заявок, а затем finance вставила разовое исключение из прошлогоднего выездного мероприятия отдела продаж. Теперь это один длинный документ, и ассистент вытаскивает всё сразу.

На странице сказано, что сотрудники могут списывать авиабилеты, отели, поезда и местный транспорт для утверждённых рабочих поездок. Ниже есть две примерные заявки с вымышленными суммами. А ближе к концу написано, что во время прошлогоднего выезда компания компенсировала доступ в spa до $50, потому что это было включено в счёт отеля.

Пользователь спрашивает: «Могу ли я списать такси из аэропорта до отеля?»

Если retrieval берёт большой чанк с этой страницы, ассистент может ответить так:

«Да, расходы на поездки обычно компенсируются. Приложите чек к отчёту. В некоторых случаях также одобряли пакеты услуг отеля, например доступ в spa во время выезда. Ниже смотрите формат примерной заявки.»

Ответ не совсем неверный, но он грязный. Пользователь спрашивал про такси. Ассистент смешал правило, примечание о процессе, старое исключение и пример, который не помогает.

Task-based чанки быстро исправляют это. Вместо того чтобы хранить всю страницу в одном или двух больших блоках, разделите её на маленькие единицы, которые соответствуют типам вопросов, которые задают люди: право на компенсацию наземного транспорта, шаги подачи расхода, особые случаи и разовые исключения, а также примеры заявок только для формата.

Теперь тот же вопрос подтягивает только чанк с правом на компенсацию. Ассистент может ответить:

«Да. Вы можете списать такси из аэропорта до отеля, если поездка была утверждена как рабочая. Сохраните чек и укажите дату, маршрут и цель в отчёте о расходах.»

Этот ответ чище, потому что в чанке есть только то правило, которое соответствует вопросу.

Если пользователь спрашивает: «Как мне это подать?» — ассистент подтягивает чанк со шагами, а не чанк с правом на компенсацию. Если пользователь спрашивает: «Засчитывается ли charge за spa на выезде?» — можно подтянуть чанк с особым случаем и сказать, что это относилось только к тому мероприятию.

Именно поэтому хорошая стратегия chunking для RAG должна следовать за задачами пользователей, а не за длиной страницы. Когда правила, примеры и старые исключения живут в отдельных чанках, ассистент перестаёт смешивать их в один ответ. Пользователи получают прямой ответ, а поддержка тратит меньше времени на исправление крайних случаев, которых вообще не должно было быть в ответе.

Ошибки, из-за которых ответы остаются грязными

Большинство плохих ответов начинается в исходных материалах, а не в промпте. Если ассистент продолжает смешивать правила, примеры и крайние случаи, обычно в контенте просто нет чёткой границы, на которую можно опереться.

Первая частая ошибка — резать контент только по количеству символов. Это кажется аккуратным, но ломает мысли посередине. Один чанк заканчивается на половине правила, а следующий начинается с примера или исключения. Когда retrieval подтягивает оба, ассистент воспринимает их как одну мысль.

Похожую проблему создаёт упаковка многих FAQ в один чанк. Пользователь задаёт один узкий вопрос, но модель одновременно видит соседние ответы про другие случаи. Тогда она заимствует формулировку не из того FAQ и выдаёт смешанный ответ.

Дублирующиеся правила — ещё один тихий источник плохих ответов. Команды часто копируют одну и ту же политику в onboarding-документы, статьи помощи, внутренние заметки и старые файлы проекта. Если одна версия говорит: «Возврат занимает 5 дней», а другая — «Возврат занимает 7 дней», у ассистента нет явного победителя, если только вы не пометите один источник как активное правило.

Скриншоты тоже часто подводят команды. Люди сохраняют шаги процесса в виде изображений, вставленных слайдов или PDF с большим количеством скриншотов, а потом удивляются, почему ассистент пропускает детали. Для надёжного retrieval модели нужен обычный текст. Текст внутри изображений часто распознаётся плохо, особенно если на скриншоте есть таблицы, подписи или мелкие заметки.

Старые политики рядом с активными создают самый неприятный вид путаницы, потому что ответ звучит правдоподобно. Отменённое исключение прошлого года может выглядеть актуальным, если оно лежит в той же папке и написано похожими словами. Отделяйте архивные материалы от действующих инструкций и исключайте их из retrieval, если вопрос не относится к истории.

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

Чистые чанки почти всегда лучше умных промптов.

Быстрая проверка перед публикацией

Чанк может выглядеть аккуратно в документе и всё равно проваливаться в retrieval. Обычно проблема проста: он пытается ответить сразу на два или три разных вопроса. Тогда ассистент вытаскивает лишние детали и даёт смешанный ответ.

Быстрая проверка ловит большую часть таких случаев до того, как контент увидят пользователи. У каждого чанка должна быть одна задача.

1. Убедитесь, что каждый чанк отвечает на один вопрос. Если чанк объясняет сроки возврата, держите закрытие аккаунта, редкие исключения и истории из поддержки в другом месте.
2. Поставьте прямой ответ в первые строки. Многие системы сильно учитывают начало чанка, да и пользователи тоже.
3. Держите чанки с политикой чистыми. Перенесите примеры, образцы ответов и рабочие сценарии в отдельные чанки, чтобы модель не повторяла пример как правило.
4. Уберите старые правила из активного набора или пометьте их понятными датами и статусом. Отменённое исключение прошлого года всё ещё может просочиться в ответы, если оно лежит рядом с текущей политикой.
5. Протестируйте с пятью реальными вопросами пользователей до публикации. Используйте обычные формулировки, а не внутренние названия, и посмотрите, к какому чанку ассистент обращается первым.

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

Небольшой тест быстро показывает слабые чанки. Спросите что-то вроде: «Могу ли я получить возврат после 30 дней?» и «А что если support уже одобрила это по email?» Если ассистент смешивает базовое правило со старым единичным случаем, структуру всё ещё нужно дорабатывать.

Один практичный принцип очень помогает: если вы не можете указать на один-единственный чанк, который должен ответить на вопрос, значит и ассистент, скорее всего, не сможет. Разбейте ещё раз.

Команды часто не хотят архивировать старый контент, потому что хотят сохранить историю. Сохранять историю можно, но не надо держать её в том же пути retrieval, что и актуальные инструкции. Храните её отдельно, помечайте датами и делайте текущее правило заметно проще в поиске, чем старое.

Чистая база знаний может казаться автору немного повторяющейся. Это нормально. Повторение дешевле путаницы.

Что делать дальше

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

Возьмите эту область и перестройте её вокруг задач, с которыми пользователи приходят к ассистенту. Если люди спрашивают: «Могу ли я получить возврат после 30 дней?» — сделайте чанк именно для этой задачи. Держите правило в одном месте, примеры — в другом, а старые крайние случаи уберите из основного пути ответа.

Простой первый проход обычно работает хорошо:

• Выберите одну область политики с частыми вопросами.
• Разбейте её на 5–10 реальных вопросов пользователей.
• Создайте отдельные чанки для правил, примеров и исключений.
• Уберите старые заметки, которые больше не меняют ответ.

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

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

Если вашей команде нужен внешний взгляд, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями над AI-first workflow, дизайном внутренних ассистентов и структурой контента. Такой ревью особенно помогает, когда retrieval в целом уже неплохой, но ответы всё ещё приходят запутанными.

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