Как управлять «заносом» 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 положил в статью в тг.