Как управлять «заносом» LLM в разработке
Одна из ошибок в AI-разработке — пытаться сделать модель детерминированной огромным промптом.
Не получится.
LLM по своей природе вероятностная. Но это не значит, что вся система вокруг неё должна быть такой же.
Хорошая аналогия — автомобиль на скользкой дороге. Ты не убираешь саму возможность заноса. Ты делаешь так, чтобы машина оставалась в управляемом коридоре.
С LLM примерно так же.
Вместо: «Проанализируй инцидент и найди root cause»
мы даём агенту конкретные инструменты: get_logs() get_metrics() get_trace() get_deployments() get_dependency_health()
И добавляем правила: нельзя объявлять root cause без фактов; нужно минимум два независимых подтверждения; если данных недостаточно — вернуть insufficient evidence; production менять нельзя; результат должен соответствовать фиксированной схеме.
Например, агент может сам решить, куда пойти сначала: в логи, трейсы или метрики.
Но ответ обязан выглядеть примерно так: Impact → Period → Affected component → Evidence → Root cause → Confidence
Вот это и есть детерминированный контур вокруг недетерминированной модели.
И здесь важный момент: не нужно писать отдельный tool под каждую бизнес-задачу.
Гораздо полезнее сделать набор универсальных примитивов: search_logs() query_metrics() get_trace() get_api_spec() run_test() get_deployment() create_ticket()
А уже модель комбинирует их в зависимости от задачи.
По сути, мы всё меньше программируем последовательность действий и всё больше программируем: что модель видит; что ей разрешено делать; что запрещено; какой у неё бюджет; и как проверяется результат.
Это хорошо ложится на идею из HarnessOpt-Bench: качество агента определяется не только самой моделью, но и harness вокруг неё — prompts, tools, control flow, context, memory и orchestration.
Материал HarnessOpt-Bench положил в статью в тг.