ИИ-агент сказал «сделано». Но сделал ли он на самом деле?

[warhamster]

детектирование аномальных решений

Я сначала даже повелся на статью, но вот как выглядит код детектора аномальных решений:

def score_anomaly(response: str, forbidden_patterns: list) -> EvalResult:
    """Detect anomalous patterns in agent response."""
    found = [p for p in forbidden_patterns if p.lower() in response.lower()]
    score = 1.0 if not found else 0.0
    return EvalResult(
        prompt_id="anomaly_check",
        score=score,
        passed=not found,
        reason=f"Anomalies found: {found}" if found else "No anomalies detected"
    )

[DariRinch]

Справедливо. score_anomaly — это pattern matching, не ML-детектор. Называть это «детектированием аномальных решений» — это преувеличение с моей стороны, признаю.

Почему это всё равно имеет смысл в контексте DCL: сам слой верификации не про умный детектор аномалий — он про детерминированность и воспроизводимость. Поиск подстроки запрещенных паттернов — предсказуемый, аудируемый, объяснимый механизм. Его вывод всегда один и тот же при одном и том же входе. LLM-судья дал бы другой ответ при другом seed — и это ровно та проблема, которую DCL пытается решить.

Более сложные детекторы (эмбеддинговое расстояние, поведенческий drift по Z-тесту — он в приложении есть) — отдельный слой поверх. Но базовый policy enforcement намеренно детерминирован и прост. Это выбор, а не недосмотр.

Формулировку в статье уточню — «детектирование нарушений политики» точнее отражает то, что делает этот конкретный метод.

[akod67]

Она не «выполняет» задачу — она генерирует текст, который статистически соответствует тому, как выглядит выполненная задача.

Дальше можно не читать. Современные агенсткие системы проверяют результаты выполнения сгенерированного кода.

[Ingref]

Было бы интересно посмотреть конкретные примеры использования на реальных задачах. Где агент выдал не совсем то, а система его подловила. Как вот в случае с алгоритмом Беллмана-Форда из той статьи, про которую вы упомянули.

[DariRinch]

Отличная идея! Как раз готовим статью с реальными кейсами. Один из них - финансовый агент который стабильно давал COMMIT на запросы типа 'как минимизировать налоги', но при добавлении policy finance получил NO_COMMIT с причиной: forbidden pattern 'tax evasion adjacent'. Разница между дефолтной политикой и специализированной оказалась показательной.

Второй кейс — drift detection: агент начал постепенно снижать confidence с 94% до 67% за 40 итераций, DriftMonitor поймал ESCALATION на 38-й. Без мониторинга это бы прошло незамеченным.

Статья скоро — подпишитесь чтобы не пропустить

[diffnotes-tech]

Логирование tool calls с трассами - LangSmith, LangFuse, Arize это умеют. Новое тут commitment protocol, агент фиксирует план до выполнения. Но реальные агентные пайплайны адаптивные, следующий шаг зависит от результата предыдущего. Агент обязался вызвать 3 инструмента, по ходу понял что нужен четвёртый - нарушение обязательства или нормальная работа?

[DariRinch]

Хороший вопрос. LangSmith/LangFuse/Arize — это observability, они логируют что произошло. DCL — это commitment layer, он фиксирует что должно произойти и верифицирует результат против политики. По адаптивным пайплайнам: добавление четвёртого инструмента — не нарушение, если итоговый output проходит policy verification. DCL оценивает результат, а не маршрут. Commitment — это "output будет соответствовать политике", а не "будет ровно 3 tool call". Это принципиальное отличие от трассировки: нас интересует верифицируемый результат с криптографическим доказательством, а не полная трасса выполнения. Трасса — для дебага, commitment — для compliance, соответствия требованиям