Приручаем недетерминизм агентных систем

[DrMayDay]

Как отлаживать то, что не воспроизводится? Как перезапустить упавший пайплайн не с нуля? Как вообще понять поведение системы, если каждый запуск чуть-чуть другой?

Seed модели задайте руками, и будет вам полный детерминизм, одно и то же каждый запуск на одни те же данные. Не благодарите.

[ArtTrek]

К сожалению seed не дает полного детерминизма - OpenAI пишет «mostly deterministic».

Есть на эту тему исследование от Thinking Machine.

Ну и сама нулевая температура, есть кейсы где она актуальна (классификация, json собирать), но что если нужен живой диалог? Написание кода? Исследование?

Ну и в целом, ESA не про это - он не про воспроизводимость именно конкретного ответа, он про воспроизводимость всей системы.

[DrMayDay]

С LLM'ками нельзя всё сваливать в кучу. Если у вашего(я так понимаю самописного) агента начинаются проблемы типа "петель" на вызове инструментов, то тут уже не место "диалогам" - проблему нужно логировать и жёстко разгребать на конкретном seed'е. В той чудной статье 2023го года объясняют, что "mostly deterministic" имеется ввиду, что нельзя в своих государственно-сертифицированных криптоприложениях рассчитывать на идентичность, радиация там, распределённость вычислений, ненадёжность float, всё такое... Для целей отладки агентов детерминизм там полный(при условии одинаковых seed/temp/top_p/...).

И вообще агентов надо на локальных моделях типа GPT-OSS 20B тестировать(если openai-compatible) именно из-за их "несильной умности", так как они не будут пытаться сами баги вашего агента как-то сглаживать, а сразу начнут косячить и глючить, что хорошо в случае отладки. Если вы сможете сделать агента у которого Gemma4 26B заработает без "петель", в этого агента потом можете что угодно засовывать(с таким форматом потока) - он точно отработает)

[ArtTrek]

Вот тут соглашусь, отладка на локальных моделях отличный подход.

Но главное с чем соглашусь - "проблему нужно логировать и жёстко разгребать". ESA как раз и создана для этого - всё, что происходит в системе уже в логе. Нужен перезапуск с другими параметрами? Да сколько влезет, причём нет нужды прогонять заново вообще все шаги, их можно спокойно переиспользовать.

[Ariless]

Самое ценное в такой архитектуре с точки зрения тестируемости это связка causation_id + immutable log.

У меня в RAG-пайплайне был кейс, где тест падал с 422 (неправильная специализация). Проблема была не в модели, а в том что retrieval layer формировал некорректный контекст.

Ключевой вопрос в отладке был не "ошибся ли LLM", а "какие именно данные попали в контекст на этом шаге". Без иммутабельного лога это требовало ручной реконструкции: проверка retrieval scores через node -e, отдельный режим AI_MOCK_RESPONSE=true для исключения LLM и изоляции retrieval-слоя. В результате выяснилось, что релевантный контекст не попадал в prompt на этапе сборки.

При наличии event log с причинной связностью контекст становится воспроизводимой проекцией состояния системы. Это переводит отладку из восстановления фактов в навигацию по correlation_id. Практический эффект - тест начинает проверять не только выход системы, но и входное состояние, в котором этот выход был сгенерирован.

[ArtTrek]

Прямо в точку. Про проверку входного состояния - идеальная формулировка, лучше моей.