Dual-Agent LLM Architecture: два специализированных LLM вместо одного универсального

ЦИКЛ (пока Evaluation Agent не скажет "хватит"):
 
ШАГ 1: Conversational Agent → задаёт вопрос пользователю
 Использует: подсказку от Evaluation Agent (какую тему проверить)
 Стратегия: эмпатия / эмпатия+личный опыт / прямой вопрос
 
ШАГ 2: Пользователь → отвечает

ШАГ 3: Evaluation Agent → анализирует весь диалог
 Вход: полная история диалога
 Выход: (1) обновлённые оценки по всем метрикам
 (2) следующая тема для проверки ИЛИ "достаточно данных"
 
ШАГ 4: Решение
 Если Evaluation Agent вернул тему → повтор с ШАГ 1
 Если вернул "None" → стоп, финальный результат

Две модели работают в одном запросе каждая на итерацию, но выполняют разные функции. Conversational Agent видит только подсказку и историю, Evaluation Agent видит полную картину.

⚠️ Ограничения метода: Исследование про медицинскую диагностику. Для нашего примера берём НЕмедицинскую задачу, где двухагентная архитектура тоже сработает — сбор обратной связи от клиента.

Задача: Вы UX-исследователь. Провели редизайн интерфейса мобильного банка. Нужно за 5-7 вопросов понять реакцию пользователя на 10 изменений: новая навигация, упрощённые переводы, изменённые цвета, добавленные подсказки и т.д. Классический опросник скучный — люди отвечают формально. Нужен живой разговор, который систематически покроет все изменения.

Промпт для Conversational Agent (первое сообщение):

Ты UX-исследователь. Веди дружеский разговор с пользователем о новом дизайне приложения банка.

ТВОЯ ЦЕЛЬ: узнать мнение по всем изменениям естественно, без формальных опросников.

СТРАТЕГИЯ:
- Начни с общего впечатления
- Задавай открытые вопросы
- Реагируй эмпатично на ответы
- Если тема важна — углубляйся

ВАЖНО: не задавай все вопросы сразу. Один вопрос → ждёшь ответ → следующий.

ПЕРВЫЙ ВОПРОС: Спроси общее впечатление от обновлённого приложения.

Промпт для Evaluation Agent (после каждого ответа пользователя):

Ты аналитик UX-исследования. Твоя задача — отслеживать какие темы уже обсудили, а какие нет.

СПИСОК ТЕМ ДЛЯ ПРОВЕРКИ:
1. Навигация (нижнее меню)
2. Переводы (упрощённая форма)
3. История операций (новый дизайн)
4. Цветовая схема (светлые тона)
5. Подсказки (контекстные тултипы)
6. Скорость работы
7. Шрифты (читаемость)
8. Главный экран (виджеты)
9. Уведомления (новый формат)
10. Общее удобство

ИСТОРИЯ ДИАЛОГА:
{вставить диалог}

ТВОЙ OUTPUT (JSON):
{
 "covered_topics": ["список тем, которые пользователь уже затронул"],
 "uncovered_topics": ["список тем, о которых не говорили"],
 "next_topic": "тема для следующего вопроса ИЛИ null если хватит данных",
 "reason": "почему выбрал эту тему / почему решил закончить"
}

ПРАВИЛО: минимум 3 итерации, максимум 8. Заканчивай когда покрыли 7+ тем ИЛИ пользователь устал.

Результат: Conversational Agent ведёт естественный диалог — задаёт вопросы, реагирует на ответы, углубляется в интересные моменты. Evaluation Agent работает в фоне — после каждого ответа анализирует что уже выяснено, подсказывает какую тему проверить следующей, решает когда остановиться. Вы получаете структурированную обратную связь без формального опросника — пользователь не чувствует что его "допрашивают по чек-листу", но все важные темы систематически покрываются.

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

Сильная сторона LLM: Модель отлично выполняет специализированную роль с чётким фокусом. Conversational Agent фокусируется только на качестве диалога — эмпатия, естественность, установление контакта. Evaluation Agent фокусируется только на аналитике — что покрыто, что упущено, когда хватит.

Как метод использует сильную сторону: Разделение ролей снимает когнитивную нагрузку с каждой модели. Conversational Agent не думает о чек-листе — он просто хороший собеседник. Evaluation Agent не пытается быть живым — он структурированный аналитик. Вместе они дают систему, которая естественна в диалоге и систематична в покрытии тем.

Рычаги управления:

• Число итераций (min/max) → уменьши для быстрого сбора базовых данных, увеличь для глубокого исследования
• Стратегия диалога (эмпатия, личный опыт, прямые вопросы) → меняй под аудиторию и контекст
• Критерий завершения (покрыто N тем, собрано достаточно данных) → адаптируй под задачу
• Список тем для отслеживания → замени на свои метрики/вопросы/аспекты
• Роли агентов → вместо "исследователь" и "аналитик" можешь сделать "продавец" и "контроль качества лидов", "интервьюер" и "трекер компетенций"

Ты {роль_диалога}. Веди {стиль_общения} разговор с пользователем о {тема}.

ТВОЯ ЦЕЛЬ: {что_узнать}

СТРАТЕГИЯ:
{выбери_одну}
- [Эмпатия] Реагируй на ответы пользователя с пониманием, задавай открытые вопросы
- [Эмпатия + личный опыт] Делись коротким релевантным опытом, создавай доверие
- [Прямые вопросы] Задавай конкретные вопросы без лишних комментариев

ВАЖНО: 
- Один вопрос за раз
- Реагируй на ответ перед следующим вопросом
- Если пользователь затронул важное — углубись

СЛЕДУЮЩАЯ ТЕМА ДЛЯ ПРОВЕРКИ: {тема_от_evaluation_agent}

ИСТОРИЯ ДИАЛОГА:
{история}

Твой ответ пользователю:

Ты {роль_аналитика}. Отслеживай покрытие тем в диалоге.

СПИСОК ТЕМ ДЛЯ ПРОВЕРКИ:
{список_тем_с_нумерацией}

ИСТОРИЯ ДИАЛОГА:
{история}

ТВОЙ OUTPUT (строго JSON):
{
 "covered_topics": [список покрытых тем],
 "uncovered_topics": [список непокрытых тем],
 "next_topic": "тема для следующего вопроса ИЛИ null",
 "confidence_scores": {тема: 0-10 насколько хорошо покрыта},
 "reason": "почему выбрал эту тему / почему решил закончить"
}

ПРАВИЛА ЗАВЕРШЕНИЯ:
- Минимум {N} итераций
- Максимум {M} итераций 
- Закончи если: {критерий_например_покрыто_X_тем_или_пользователь_устал}

Плейсхолдеры:

• {роль_диалога} — UX-исследователь, менеджер по продажам, HR-интервьюер
• {стиль_общения} — дружеский, профессиональный, неформальный
• {тема} — новый дизайн, болевые точки клиента, технические навыки кандидата
• {что_узнать} — реакция на изменения, потребности клиента, уровень компетенций
• {список_тем_с_нумерацией} — конкретные аспекты которые нужно проверить
• {N}, {M} — минимум и максимум итераций
• {критерий} — когда остановиться (покрыто 7/10 тем, confidence > 8 по ключевым темам)

🚀 Быстрый старт — вставь в два отдельных чата:

Вот шаблоны Dual-Agent Architecture. Адаптируй под мою задачу: [твоя задача].

Задай вопросы чтобы заполнить плейсхолдеры:
- Какую роль играет Conversational Agent
- Какой стиль общения нужен
- Какие темы/аспекты отслеживать
- Критерий завершения диалога

[вставить оба шаблона выше]

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

⚠️ Два чата параллельно: Нужно работать с двумя окнами LLM одновременно — один для диалога, второй для анализа. Можно через API автоматизировать, но в обычных чатах это ручная работа.

⚠️ Латентность: Каждая итерация = 2 запроса к LLM (диалог + анализ). Для задач где важна скорость ответа (например, real-time поддержка) это может быть медленно.

⚠️ Зависимость от качества Evaluation Agent: Если аналитический агент плохо отслеживает прогресс или некорректно выбирает следующую тему, весь диалог идёт не туда. Нужен хороший промпт для Evaluation Agent.

⚠️ Контекст обоих агентов растёт: При длинном диалоге история в обоих промптах увеличивается → стоимость токенов растёт быстрее чем в одномодельном подходе.

Команда проверила три стратегии диалога на одной и той же задаче (оценка симптомов депрессии через разговор с LLM-персонами, симулирующими пациентов):

• Run 0 (эмпатия + самораскрытие): Conversational Agent не только сопереживает, но и делится коротким личным опытом. Например: "Я тоже замечал что после стресса на работе сложно заснуть. А у вас как с этим?"
• Run 1 (только эмпатия): Агент валидирует чувства пользователя без личных историй. "Понимаю, это действительно тяжело. Расскажите подробнее?"
• Run 2 (прямые вопросы): Агент сразу задаёт вопрос без эмпатичных комментариев. "Как часто у вас проблемы со сном?"

Evaluation Agent во всех трёх случаях использовал одинаковую логику — отслеживал покрытие 21 симптома депрессии по опроснику BDI-II, подсказывал Conversational Agent какой симптом проверить следующим, останавливал диалог когда собрано достаточно данных.

Результаты удивили: Run 1 (эмпатия без самораскрытия) дал лучшие метрики по всем показателям. DCHR (точность категории депрессии) = 0.66, ADODL (точность общего уровня) = 0.93 — оба показателя лучшие среди всех команд. Run 0 с личными историями оказался слабее, хотя в предыдущих исследованиях команды самораскрытие хорошо работало для установления контакта с подростками.

Почему так вышло? Исследователи предполагают что личные истории могут отвлекать в контексте медицинской диагностики — пользователь начинает реагировать на историю агента вместо того чтобы фокусироваться на своих симптомах. Чистая эмпатия ("понимаю, это тяжело") валидирует без отвлечения. Прямые вопросы (Run 2) дали худший результат — DCHR упал до 0.41, что подтверждает гипотезу что эмпатия критична для получения честных ответов.

Ещё один инсайт: команда SINAI-UJA показала самые короткие диалоги среди всех участников — в среднем 6.54 сообщения против 31 у конкурентов. При этом их сообщения были плотнее (488 символов против 414). Это значит что хорошо настроенный Evaluation Agent позволяет собрать нужную информацию быстрее — он точно знает какие темы недопокрыты и когда можно остановиться, вместо того чтобы задавать вопросы "на всякий случай".

В статье нет готового промпта — только описание архитектуры и стратегий. Полные промпты для Conversational Agent показаны в приложении A (рисунки 7, 8, 9), для Evaluation Agent — в приложении B (рисунок 10). Они на английском и заточены под медицинскую задачу (детекция депрессии через оценку 21 симптома BDI-II).

Контекст: Исследователи использовали Llama 3.1-8B-Instruct для обоих агентов. Conversational Agent получал имя персоны-симулятора и инструкции по стратегии общения (с самораскрытием / без / только вопросы). Evaluation Agent получал всю историю диалога и возвращал JSON с оценками симптомов и следующей темой для проверки. Если Evaluation Agent возвращал "next_symptom": None — диалог завершался.

💡 Адаптация для глубинных интервью в маркетинге:

Классическая задача — понять почему клиенты выбирают конкурента или что мешает покупке. Формальные опросы дают поверхностные ответы ("дорого"). Глубинное интервью раскрывает настоящие мотивы, но требует опытного интервьюера.

=== CONVERSATIONAL AGENT ===
Ты маркетинговый исследователь. Веди неформальный разговор с клиентом который недавно ушёл к конкуренту.

ЦЕЛЬ: понять настоящие причины ухода (не те что он озвучивает сходу, а глубинные)

СТРАТЕГИЯ: Эмпатия
- Валидируй его чувства
- Если затронул важное — копай глубже через "А что именно?", "Расскажи подробнее"
- Не торопи, дай высказаться

СЛЕДУЮЩАЯ ТЕМА: {от Evaluation Agent}

ИСТОРИЯ:
{история}

=== EVALUATION AGENT ===
Отслеживай ГЛУБИННЫЕ МОТИВЫ ухода клиента.

ГИПОТЕЗЫ ДЛЯ ПРОВЕРКИ:
1. Цена (но что именно — абсолютная цифра или соотношение цена/качество?)
2. Качество продукта (конкретно что не устроило)
3. Сервис (скорость, вежливость, решение проблем)
4. Доверие (были ли косяки которые подорвали репутацию)
5. Функционал (чего не хватает в сравнении с конкурентом)
6. Удобство (интерфейс, доставка, оплата)
7. Эмоциональная связь (бренд перестал резонировать)

ИСТОРИЯ:
{история}

OUTPUT (JSON):
{
 "surface_reasons": [что клиент говорит явно],
 "deep_reasons": [что стоит за поверхностными причинами],
 "uncovered_hypotheses": [какие гипотезы не проверены],
 "next_hypothesis": "какую проверить следующей ИЛИ null",
 "confidence": {гипотеза: 0-10},
 "recommendation": "закончить диалог ИЛИ копать глубже в [тема]"
}

ПРАВИЛО: Минимум 4 итерации. Закончи если нашёл 2-3 глубинные причины с confidence > 7.

Почему это сработает: Conversational Agent создаёт безопасное пространство где клиент может честно говорить (не боится что его осудят за уход). Evaluation Agent отличает поверхностные отмазки от глубинных причин — если клиент сказал "дорого", агент помечает это как поверхностную причину и подсказывает копать глубже ("а что конкретно дорого — сам продукт или в сравнении с тем что получаете?").

🔧 Техника: async двухагентный анализ для больших документов

Классическая проблема: просишь LLM "проверь юридический договор на риски" → модель пропускает детали или галлюцинирует, потому что пытается сразу читать И анализировать.

Решение: Разделяем на два агента в одном чате через мета-промпт:

Ты система из двух специализированных агентов для анализа документов.

АГЕНТ 1 (Reader): Читает документ последовательно. Ищет конкретные паттерны рисков:
- Несбалансированные обязательства (одна сторона должна больше)
- Санкции и штрафы
- Ограничения и запреты
- Размытые формулировки ("по возможности", "в разумные сроки")
- Отсутствующие защитные механизмы

После каждого раздела документа Reader выдаёт JSON:
{
 "section": "название раздела",
 "findings": ["найденные паттерны"],
 "flags": ["потенциальные риски"]
}

АГЕНТ 2 (Analyst): Получает все findings от Reader. Оценивает:
- Критичность каждого риска (1-10)
- Связи между рисками (один риск усиливает другой)
- Недостающие пункты (чего нет но должно быть)
- Итоговая рекомендация (подписывать / доработать / отклонить)

ДОКУМЕНТ:
{договор}

ИНСТРУКЦИЯ:
1. Reader: Проанализируй документ по разделам, выдай findings
2. Analyst: Получи findings, сделай итоговую оценку
3. Финальный output: краткий список критичных рисков + рекомендация

Почему это другой паттерн: В исследовании два агента работают синхронно (диалог → анализ → диалог). Здесь sequential processing — сначала один агент полностью делает свою работу (читает весь документ), потом второй получает результаты и делает свою (синтезирует выводы). Это async двухагентность в рамках одного промпта — полезно когда задача требует двух разных когнитивных режимов: детальное чтение vs высокоуровневый анализ.

SINAI at eRisk@CLEF 2025: Transformer-Based and Conversational Strategies for Depression Detection

Alba Maria Marmol-Romero, Manuel Garcia-Vega, Miguel Angel Garcia-Cumbreras, Arturo Montejo-Raez

University of Jaen, SINAI Research Group, Spain