Ассистент, а не агент: как спроектировать предсказуемую LLM-систему

Владимир Суворов, senior data scientist и core-разработчик open-source AutoML-фреймворка OutBoxML, рассказывает о проектировании LLM-системы на примере ассистента, который сверяет входящий документ технического задания со сводом документации и ставит комментарии о наличии запрашиваемых пунктов. Он проводит чёткое различие между ИИ-агентом (аутсорс) и ИИ-ассистентом (штатный сотрудник): агент автономен и неконтролируем, ассистент строго регламентирован, что даёт предсказуемость и надёжность. Для регулярных процессов, таких как сверка документов, Суворов рекомендует строить ассистента, который всегда обращается к актуальным правилам и не полагается на память. Архитектура ассистента основана на оркестраторе, который управляет четырьмя подсистемами: DocumentPreprocessor (подготовка данных), AIModel (общение с LLM), PostProcessor (разбор ответа) и ReportExport (вывод результата). Пайплайн обработки включает чанкинг документа, RAG для извлечения релевантных разделов нормативной базы (через NormativeIndex и ContextBuilder), и многоуровневый матчинг при сборке отчёта. Заменяемые интерфейсы позволяют легко переключаться между моделями: для разработки используются локальные модели через Ollama, для тестирования — Gemini, для продакшена — Qwen 3 на внутреннем контуре. Для Qwen 3 отключают reasoning-режим. Основная сложность продакшена — работа с лимитами и отказами: на внешнем API (Gemini) применяют превентивные таймауты, на своём контуре (Qwen) — retry с паузой и пропуск проблемного чанка после N неудачных попыток, чтобы не потерять весь документ.