§9.06 Распределённый поиск и посредник модели
Время: 45 мин чтение + 30 мин
В одном предложении: Пилот думает, что лучшая модель решает все задачи, а на самом деле в агентной экосистеме маршрутизация запросов к оптимальным ресурсам через Fan-out и LLM Proxy даёт качество выше сильнейшей модели в одиночку при меньших затратах, потому что разные задачи требуют разных когнитивных профилей, и одна модель — это как один инструмент для всех работ.
Мем, который снимается. «У меня подписка на самую мощную модель — зачем мне что-то ещё? Она и код напишет, и стихи сочинит, и проанализирует данные.» На самом деле мощность — это не универсальность. Самая сильная модель в мире не обязательно лучший выбор для каждой задачи. Некоторые задачи требуют скорости, а не глубины. Некоторые — доменной экспертизы, которой нет у общих моделей. Некоторые — творческого риска, который сильные модели склонны сглаживать в погоне за «безопасным» ответом. Использовать одну модель для всего — это как ездить на гоночном болиде за хлебом: technically possible, но расточительно и неудобно.
Понятия. Fan-out (веерный поиск) — распределение запроса к нескольким агентам или источникам знаний одновременно с последующей агрегацией результатов. LLM Proxy (посредник модели) — посредник, маршрутизирующий запросы к оптимальной языковой модели на основе типа задачи, требований к качеству, latency и стоимости. Маршрутизация — процесс выбора наилучшего пути исполнения запроса в распределённой экосистеме. Fan-out + LLM Proxy = эффективное использование ресурсов: не все задачи требуют сильнейшей модели, не все запросы решаются одним агентом.
Объяснение. Fan-out и Proxy решают две разные, но связанные проблемы. Fan-out решает проблему покрытия: один агент или модель видит мир под одним углом. Три агента с разной специализацией, запущенные параллельно, покрывают больше пространства решений. Агрегация результатов — это не просто «голосование», а конструктивное слияние: один агент нашёл факт, второй — связь, третий — ограничение. Сложенное вместе, это даёт решение, которое ни один агент не смог бы построить самостоятельно.
LLM Proxy решает проблему эффективности. Запросы различаются по глубине рассуждения, требуемой точности, допустимой задержке и чувствительности к стоимости. Proxy классифицирует запрос и направляет его: простые lookups — к быстрым моделям, архитектурные решения — к сильным моделям с длинным контекстом, креативные задачи — к моделям с нужным профилем, чувствительные данные — к локальным моделям. Пилот определяет правила маршрутизации; Машина исполняет их.
Вместе Fan-out и Proxy создают эмерджентное качество, которое называется «экосистемный интеллект». Отдельная модель — это отдельный мозг. Экосистема с Fan-out и Proxy — это коллективный разум, где каждый участник делает то, что у него лучше получается, а посредник обеспечивает координацию. Это не замена пилота, а усиление: пилот задаёт стратегию маршрутизации, агенты выполняют тактику.
На практике. Практика «Проектирование Fan-out + Proxy» (30 мин):
- Выберите один тип запросов в вашей IWE, который вы сейчас отправляете одному агенту или модели. (3 мин)
- Определите 2–3 агента или источника, которые могут ответить на этот запрос по-разному (разные специализации, разные модели, разные базы знаний). (7 мин)
- Спроектируйте правило Fan-out: как запрос распределяется, как результаты агрегируются (консенсус, лучший выбор, слияние). (10 мин)
- Спроектируйте правило Proxy: по каким признакам запрос маршрутизируется к разным исполнителям. (7 мин)
- Зафиксируйте схему в Pack: диаграмму, правила, примеры запросов. (3 мин)
Типичный кейс. Команда аналитиков использовала одну сильную модель для всех запросов: от быстрых справок до глубоких исследований. Счет за API был высоким, а качество — неравномерным: простые вопросы получали слишком развёрнутые ответы, а сложные — упрощённые из-за ограничений контекста. После внедрения Proxy простые запросы шли к быстрой модели (стоимость в 10 раз меньше, скорость в 3 раза выше). Сложные исследования шли к сильной модели с длинным контекстом. Fan-out применялся для проверки фактов: три агента искали независимо, результаты сравнивались. Результат: стоимость снизилась на 60%, качество фактчекинга выросло, а пилот перестал думать о том, «какую модель выбрать» — Proxy делал это автоматически.
Типичная ошибка. «Несколько агентов создают хаос — они дают разные ответы, и непонятно, кому верить.» Хаос приходит не от множественности источников, а от плохой агрегации. Если у вас есть правило «при расхождении более 30% — эскалация пилоту», разные ответы становятся сигналом, а не проблемой. Другая ошибка: «Proxy добавляет сложность и задержку.» Хороший Proxy добавляет миллисекунды на маршрутизацию, чтобы сэкономить секунды или минуты на ненужно сложном вычислении. Задержка от выбора неправильной модели всегда выше, чем задержка от её правильного выбора.
Степени мастерства:
| Степень | Что происходит | Критерий перехода |
|---|---|---|
| 1. Объясняю | Могу объяснить разницу между Fan-out и Proxy и привести пример задачи для каждого | Один раз спроектировал схему Fan-out или Proxy для реального процесса |
| 2. Умею | Для регулярных типов задач использую маршрутизацию: разные модели или агенты для разных запросов | Три типа запросов в моей IWE имеют явные правила маршрутизации |
| 3. Навык | Системно оптимизирую экосистему: анализирую, какие запросы идут куда, и корректирую правила Proxy по данным | Стоимость или latency моей агентной экосистемы снизились вдвое без потери качества |
| 4. Мастерство | Проектирую экосистемную маршрутизацию для сообщества: общие правила, пулы агентов, алгоритмы агрегации | Другая команда внедрила мою схему маршрутизации и получила измеримый прирост эффективности |
Проверка себя.
- Могу назвать три типа задач в своей IWE и объяснить, почему каждая идёт к конкретной модели или агенту
- У меня есть хотя бы один процесс, где запрос распределяется между несколькими источниками с агрегацией
- Я анализирую соотношение стоимость/качество/latency для своих запросов и корректирую маршрутизацию
- Могу показать одну задачу, которую я перенаправил с сильной модели на более лёгкую без потери качества
- Мои агенты не дублируют работу друг друга — у каждого есть чёткая специализация
На практике. Следующий раз, когда вы зададите вопрос агенту, остановитесь и спросите: «Этот вопрос требует глубокого рассуждения или быстрой справки? Может ли другой агент ответить лучше? Стоит ли запустить несколько агентов параллельно?» Запишите свой выбор и результат. Это и есть проектирование маршрутизации.
См. также: Экономика вклада — PD.GUIDE.3.S9.SS5, Статус достоверности утверждения — PD.GUIDE.3.S9.SS7.
Что дальше. Следующий подраздел — о статусе достоверности утверждения: как маркировать уровень уверенности в знаниях Pack и защищаться от ложной уверенности в мире, где агенты генерируют утверждения со скоростью машины.