Маршрутизация подсказок по типу документа в одном AI‑потоке

Почему одна подсказка не подходит для разных документов

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

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

Первая проблема — тон. Модель может ответить на запрос клиента как технический аудит или описать пункт договора в том же неформальном стиле, что и внутренние заметки. Вторая проблема — формат. Инженерам нужны структурированные поля. Юристам — комментарии к пунктам. Поддержке — приоритет, категория и черновик ответа. Одна универсальная подсказка редко справляется со всем этим.

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

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

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

Подсказка не должна угадывать тип полученного документа. Она должна его знать.

Где федеративные системы добавляют работы по маршрутизации

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

Имя — первая проблема. Один инструмент может назвать файл «вложением к тикету», другой — «заметкой по делу», третий хранит его как просто «документ». Ни одна из этих меток не подсказывает, содержится ли в файле код, договор или запрос в поддержку.

Несоответствия проявляются быстро. Служба поддержки может экспортировать отчёт об ошибке в PDF с вставленными логами. Юридическая система может хранить черновик договора в Word под именем «final_v2_review». Синхронизация репозитория может прислать plain‑text файл без расширения, хотя внутри лежит исходный код. Почтовый шлюз может удалить имена файлов и оставить только метаданные сообщения.

Метаданные усугубляют ситуацию. Во федеративной маршрутизации вы часто получаете частичные факты вместо чистой записи. Имя файла может отсутствовать, поле автора — быть неверным, а система‑источник маркировать почти всё как "text/plain".

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

Локальные правила тоже могут конфликтовать. Юристы могут считать бланк заказа договором. Поддержка — тот же файл как запись клиента. Инженеры сосредоточатся на примере API на второй странице и проигнорируют остальное. Эта путаница создаётся не моделью, а вашими системами.

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

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

Выбирайте типы документов прежде, чем писать обёртки

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

Начните с небольшого набора типов документов, которые встречаются чаще всего. Три‑четыре типа достаточно для первого прохода. Это упрощает логику маршрутизатора и заставляет вас отделить общие задачи от крайних случаев.

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

Простой стартовый набор может выглядеть так:

• Код и технические артефакты
• Договоры и нормативные документы
• Тикеты поддержки и сообщения клиентов
• Смешанное или неизвестное содержимое

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

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

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

Что должна содержать каждая обёртка

Маршрутизация работает лучше, когда каждая обёртка короткая и строгая. Обёртка должна сказать модели, что она читает, что нужно сделать и в каком виде должен быть ответ.

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

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

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

Правила должны быть прямыми. Скажите модели, что скрывать, в каком тоне говорить и где остановиться. Для редактирования укажите, какие данные маскировать: номера счетов, приватные контакты и т.д. Для тона укажите, нейтральный он, формальный или дружелюбный. Для границ чётко укажите, что модель может отмечать юридические риски, но не должна выдавать себя за юриста.

Держите контекст узким

Передавайте только тот контекст, который нужен обёртке. Обёртке для ревью кода нужны изменения в файлах, логи и стек‑трэйсы. Ей не нужен жалобный текст клиента из того же дела. Тикету поддержки может потребоваться история заказов и политика возврата, но не весь исходный код.

Узкий контекст сокращает шум и снижает шанс, что один тип документа «протечёт» в другой и заставит модель решать не ту задачу.

Стройте поток маршрутизации шаг за шагом

Хороший маршрутизатор принимает одно решение до того, как начнёт читать слишком много. Сначала проверьте метаданные. Имя файла, приложение‑источник, папка, отправитель и MIME‑тип часто говорят больше, чем первый абзац. .py из GitLab и PDF под именем msa_v4 не должны идти в одну и ту же обёртку.

Затем прочитайте небольшой фрагмент тела и ищите явные подсказки. Блоки кода, строки import, стек‑трэйсы, номера пунктов, блоки подписи, ID тикета, приветствия и фразы о возврате — всё это указывает в разные стороны. На этом этапе не нужна глубокая семантика, нужны быстрые шаблонные проверки, которые отделяют явные случаи от грязных.

Чистый поток маршрутизации обычно имеет пять шагов:

1. Собрать метаданные до парсинга тела.
2. Просканировать первый кусок на маркеры документа.
3. Оценить каждый тип простыми правилами.
4. Отправить документ через одну обёртку только.
5. Логировать маршрут, оценку уверенности и версию обёртки.

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

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

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

Простой пример с кодом, договорами и тикетами

Небольшая команда может использовать одну общую модель для всего, что приходит в центральную очередь. В понедельник утром приходят три файла: diff пулл‑реквеста, подписанный PDF и отчёт об ошибке из поддержки. Если отправить всё через одну универсальную подсказку, ответы начнут сливаться. Модель может объяснять код юридическим языком или трактовать тикет поддержки как задачу по отладке.

Решение — маршрутизировать по типу документа до того, как модель прочитает содержание. Diff пулл‑реквеста идёт в обёртку кода. Эта обёртка просит модель просмотреть изменённые файлы, искать рискованную логику, указывать отсутствующие тесты и держать комментарии короткими, чтобы их можно было вставить в ветку ревью. Ответ должен звучать как ревьюер, а не как агент поддержки.

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

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

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

Обработка смешанных файлов и случаев низкой уверенности

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

Разбивайте сообщение на части до маршрутизации. Обрабатывайте тело, каждое вложение и извлечённый текст из изображений как отдельные элементы. Затем классифицируйте каждый элемент по‑отдельности. Тикет идёт в обёртку поддержки, а прикреплённое соглашение — в обёртку договора.

Простое правило помогает: маршрутизируйте по тому, что вы можете прочитать, а не по имени файла. «final_v2.pdf» ничего не говорит. Страница, полная пунктов о ответственности, говорит многое.

Когда уверенность падает, не догадывайтесь. Задайте один короткий вопрос и дождитесь ответа. Сделайте его узким, чтобы пользователь мог ответить парой слов, например: «Обработать это как ревью кода, проверку договора или триаж поддержки?» Один такой вопрос исправляет больше ошибок, чем ещё один слой логики подсказки.

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

Безопасная запасная ветка должна проверять четыре вещи: содержит ли элемент юридические, безопасность‑ориентированные или персональные данные; какой открытый текст можно извлечь с уверенностью; какой наиболее вероятный тип документа; и стоит ли ждать человеческой проверки. Некоторые вещи не должны зависеть от слабой догадки. Договоры, регулятивные документы, сообщения о нарушениях, креденшалы и всё, что похоже на регулируемый контент, требуют более строгой обработки.

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

Ошибки, которые вызывают неправильную маршрутизацию

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

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

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

Команды также создают проблемы, когда дают полям непоследовательные имена. Одна система присылает "doc_type", другая — "content_kind", третья — "task". Они могут означать одно и то же, но маршрутизатору всё равно нужно их нормализовать. Если никто это не делает, неправильная маршрутизация становится рутиной.

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

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

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

Быстрые проверки перед развёртыванием

Большинство проблем проявляется, когда вы перестаёте тестировать аккуратные примеры и начинаете работать с реальными файлами, которые люди присылают каждый день. Чистый фрагмент кода, отшлифованный договор и короткий тикет редко создают проблемы. Отсканированные PDF, вставленные цепочки писем, смешанные заметки и недоделанные черновики — вот где всё ломается.

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

Используйте настоящие файлы из недавней работы, а не игрушечные примеры. Включите странные случаи: договор с техническими заметками внутри или тикет с прикреплённым стек‑трэйсом. Оценивайте маршрутизацию и формат вывода как два отдельных критерия. Сначала спросите: выбрана ли правильная обёртка? Затем — следует ли результат нужному формату и тону.

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

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

Следующие шаги для небольшого первого запуска

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

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

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

Не добавляйте новую обёртку из‑за одного странного файла, который запутал систему во вторник. Добавляйте её, когда вы постоянно видите одно и то же несоответствие: например, PDF‑счета, которые идут через обёртку поддержки, или вставки кода, которые попадают в общий текстовый поток.

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

Небольшой пример демонстрирует мысль. Если 70% входящих файлов — тикеты поддержки и образцы кода, запустите с этими двумя. Через две недели проверьте, где люди всё ещё вмешиваются. Если обзоров договоров достаточно, чтобы оправдать отдельные правила и формат вывода, добавьте такую обёртку.

Некоторые команды могут настроить это самостоятельно. Если рабочий процесс затрагивает продукт, инженерию, инфраструктуру и операции одновременно, внешняя экспертиза может сэкономить раунд переделок. Oleg at oleg.is работает со стартапами и малыми командами над практическими AI‑первичными рабочими процессами, включая маршрутизацию, автоматизацию и техническую доставку, так что опытный Fractional CTO может помочь сохранить первую версию простой и пригодной.