LLM-системы: от наивного цикла к производственной архитектуре

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

Для иллюстрации пост строит агента сравнения городов, который принимает список городов и создает отчет о населении, часовом поясе и повествовательных сводках. Задача разбивается на независимые поиски (девять вызовов инструментов для трех городов), которые могут выполняться параллельно, в то время как итоговый отчет зависит от завершения всех поисков. Инструменты имеют разные затраты: чтение словаря в памяти для населения и часового пояса, и вызовы LLM для сводок и агрегации, создавая реалистичное бюджетное давление.

Для воспроизводимости инструменты поиска используют имитированный словарь CITY_FACTS, а части на основе LLM могут работать с реальной моделью Anthropic или детерминированным имитированным провайдером. Имитированный провайдер возвращает ответы, учитывающие роль—канонический план, шаблонные сводки и вердикты на основе правил—чтобы отделить ошибки оркестрации от проблем планирования модели. Типизированные инструменты с моделями Pydantic обеспечивают проверку во время выполнения, JSON Schema для API использования инструментов, документацию для планировщика и хуки учета затрат, позволяя быструю проверку до дорогих вызовов. Пост отмечает, что набор для оценки, бенчмарки извлечения и специализированные пулы рабочих будут рассмотрены в будущем посте.