Качество, надёжность и галлюцинации

AI code review и отклонение кода от спеки

Вопросы участников:

AI code review.
Всегда нужно перепроверять, часто бывают ошибки или решение, которое не подходит под текущую спеку (требования)
периодически он творит полную дичь, несмотря на прописанную спецификацию

Начнём с трезвой картины. Свежий бенчмарк AI-ревью SWE-PRBench (350 pull request с разметкой людьми) показывает: восемь передовых моделей находят лишь 15–31% проблем, которые пометил человек-ревьюер. То есть AI-ревью пока сильно ниже уровня эксперта, даже когда модель хорошо решает задачи на генерацию кода. Контринтуитивный вывод того же исследования: чем больше контекста скармливаешь, тем хуже — качество монотонно падает при переходе от голого diff к полному контексту из-за размывания внимания на длинном окне.

Вторая половина проблемы — не пропуск ошибок, а обратное: модель бракует корректный код. Работа Are LLMs Reliable Code Reviewers? описывает систематическую overcorrection: LLM часто объявляет правильную реализацию несоответствующей требованиям, причём более детальный промпт (с требованием объяснений и правок) увеличивает долю ложных отклонений. Модель придумывает несуществующие ограничения, раздувает edge-кейсы и утверждает расплывчатые логические ошибки без доказательств. Это прямо объясняет ощущение творит дичь несмотря на спецификацию: чем строже вы формулируете, тем сильнее модель уходит в перестраховку и находит проблемы там, где их нет.

Что делать на практике:

Заземляйте вердикт на исполнении, а не на тексте. Ключевая идея из обеих работ — доверять не рассуждению модели, а прогону. В статье про overcorrection предлагают Fix-guided Verification Filter: раз модель говорит нет и предлагает патч, то пара (исходный код, патч) — это готовый контрпример, который надо прогнать через тесты. Переносится в ваш пайплайн так: любой вердикт AI-ревью подтверждается тестами и линтером, а не принимается на веру.
Держите diff маленьким. Исследование Bigger Isn't Always Better показало, что размер diff — главный предиктор качества ревью: F1 падает с 0.657 на диффах меньше 10 строк до 0.043 на диффах больше 150 строк. Дробите изменения, ревьюйте по одному логическому куску.
Не рассчитывайте на AI там, где он слеп. В том же исследовании у всех моделей почти нулевая полнота на багах производительности и на архитектурных проблемах. AI-ревью — это дешёвый первый проход по стилю и явным дефектам, а не замена человеку на важных решениях.
Не раздувайте промпт ревью. Раз детальные инструкции с требованием правок усиливают перестраховку — просите короткий вердикт плюс обязательный прогон, а не развёрнутое эссе с выдуманными замечаниями.

Что пойдёт не так: если принимать вердикты AI-ревью без прогона, вы получите худшее из двух миров — пропущенные реальные баги и поток ложных придирок к корректному коду. Лечится это только привязкой к исполняемым проверкам.

Ссылки

Какие AI компоненты лучше подходят для guardrails?

Главная развилка: guardrails — это не один инструмент, а три разных класса, которые часто путают и выбирают по числу звёзд на GitHub. Позиционная работа Building Guardrails for Large Language Models и практика 2025–2026 разводят их так:

Классификатор контента. Отдельная модель, которая берёт вход или выход основной модели и возвращает вердикт безопасно или небезопасно с кодом категории. Пример — Llama Guard от Meta (последнее поколение мультимодальное, размечает по таксономии MLCommons). Это одна инференс-проверка, а не фреймворк с правилами. Хорош, когда нужен быстрый само-хостируемый вердикт по контенту.
Оркестратор диалога. Программируемые рельсы поверх всего взаимодействия. Пример — NeMo Guardrails от NVIDIA с языком Colang и пятью типами рельсов: вход, диалог, retrieval, исполнение (tool calls), выход. Это единственный из трёх, кто умеет гейтить вызовы инструментов, поэтому он уместен для агентов. Плата — сложность конфигурации: неверный порядок рельсов может тихо пропустить небезопасное.
Валидатор выхода. Библиотека, которая проверяет ответ на соответствие схеме и политике и переспрашивает модель при провале. Пример — Guardrails AI с хабом из десятков готовых валидаторов (структура JSON, PII, токсичность, упоминания конкурентов). Берут, когда выход обязан быть типизированным и валидным.

Практический вывод: в зрелых системах эти слои комбинируют, а не выбирают один. Типовой продакшн-стек — дешёвый широкий сканер на входе (LLM Guard) → NeMo для контроля диалога и вызовов инструментов → классификатор (Llama Guard) внутри рельса → валидатор выхода. Выбирайте по тому, что вы охраняете: поток разговора, формат ответа или содержание.

Что пойдёт не так: любой одиночный детектор деградирует под адверсариальным давлением (jailbreak, инъекции промпта). Ни один инструмент в одиночку не закрывает инъекции, поэтому связка плюс регулярный red-team надёжнее одной модели-стража. Второй риск — латентность: каждая проверка добавляет десятки–сотни миллисекунд, и слои складываются, так что тяжёлый классификатор ставят на выборку запросов, а не на каждый.

Ссылки

Галлюцинации в коде и хранение большого числа промптов

Вопросы участников:

проблема в том что галлюцинируют и как удобнее хранить большое количество промптов.

Про галлюцинации именно в коде полезно понимать механику. Работа CodeHalu вводит рабочую классификацию через исполнение: галлюцинации бывают mapping, naming, resource и logic — то есть код синтаксически верен и правдоподобен, но не исполняется как надо или не выполняет требования. Отсюда единственный устойчивый детектор — прогон, а не чтение глазами. Масштаб проблемы виден в большом полевом исследовании Debt Behind the AI Boom (302.6 тыс. AI-коммитов из 6299 репозиториев): более 15% коммитов каждого ассистента вносят хотя бы одну проблему, а 22.7% внесённых дефектов доживают до последней версии репозитория, превращаясь в технический долг. Вывод: галлюцинации не столько предотвращаются на входе, сколько ловятся тестами, статическим анализом и guardrails из предыдущего блока.

Про хранение большого числа промптов. Кустарное решение — строки прямо в коде — плохо масштабируется: каждое изменение промпта завязано на деплой кода, нельзя роутить версии по окружениям, нет истории и отката. Индустрия сходится на модели промпт как версионируемый артефакт (по сути тот же подход, что к API):

Реестр промптов вместо строк в коде. LangSmith Prompt Hub, Anthropic Prompt Library, Portkey. Промпт хранится как неизменяемая версия, а окружения (dev/staging/prod) — это теги, которые двигаются между версиями.
Semver для промптов. major — ломающее изменение схемы вывода или контракта инструментов, minor — добавление гайдлайна или переменной, patch — правка формулировки. Так потребители понимают, на что реагировать.
Гейт на eval при каждом продвижении. Версия уезжает в prod только если не роняет регрессионный набор (точность вызова инструментов, валидность схемы, поведение отказа). Даже правка опечатки прогоняется через eval, потому что сдвиг токенов может изменить поведение.
Промоушен как перемещение тега, а не редеплой. Откат — это возврат тега на прошлую версию. Источник правды удобно держать в git (YAML в репозитории) и синхронизировать в реестр через CI, получая и код-ревью, и UI реестра.

Что пойдёт не так: если мутировать уже помеченную версию или пропускать eval на patch-правках, вы теряете аудит и ломаете откат — деградация приходит в прод незаметно.

Ссылки

Круги самосозданных проблем на длинных шагах

Вопросы участников:

на длинных шагах агенты начинают решать проблемы которые сами же себе и создают - возникают круги эффективного решения проблем, и очень жалко токенов.

Это не ваша частная беда, а хорошо описанный режим отказа. Разбор The Long-Horizon Task Mirage называет его history error accumulation: агент совершает раннюю ошибку, считает шаг успешным, продолжает зависимые действия — и мелкий сбой раскатывается в цепочку бессмысленных действий. Деградация на длинном горизонте не аддитивна: даже маленькая пошаговая ошибка компаундится по зависимым шагам и утаскивает агента от надёжной короткой работы к почти системному провалу.

Причина глубже, чем слабая модель. Работа Why Reasoning Fails to Plan показывает: пошаговое рассуждение — это, по сути, жадная политика, которая близоруко фиксирует локально удачный выбор, а на длинном горизонте ранние решения должны учитывать отложенные последствия. Отсюда ранние myopic-коммиты, которые потом дорого откатывать. А исследование надёжности Beyond pass@1 добавляет два неприятных факта: у передовых моделей самая высокая частота срывов (meltdown) — до 19%, потому что они берутся за амбициозные многошаговые стратегии, которые иногда сваливаются в спираль; и наивные memory-скаффолды ухудшают результат на длинном горизонте у всех десяти моделей.

Как гасить круги на практике:

Режьте горизонт на дискретные сегменты с проверкой. Теоретическая работа про стабильность авторегрессии показывает, что устойчивое длинное рассуждение требует сегментации и графоподобной структуры (DAG) вместо одной длинной цепочки. Практически — план из явных подзадач с верификацией на каждом стыке.
Верифицируйте состояние, а не доверяйте истории. Основной источник кругов — агент считает провалившийся шаг успешным. Заставляйте его перечитывать реальное состояние (тесты, вывод команды, состояние файлов) перед следующим шагом.
Ставьте жёсткие лимиты и точки отката. Бюджет на попытки и на токены плюс контрольные точки, чтобы откатиться к последнему хорошему состоянию, а не жечь токены в петле. Ровно за экономию токенов это и отвечает.
Не усложняйте память бездумно. Раз скаффолды памяти могут вредить — добавляйте память под конкретную проблему (потеря ограничения, забывание цели), а не как общий слой.

Что пойдёт не так: если оставить агента крутиться на длинной траектории без ре-валидации состояния и лимитов, ранняя ошибка почти гарантированно раскатается в петлю, и самая способная модель здесь опаснее — она дольше и увереннее идёт по неверному пути.