Снижение затрат и предотвращение галлюцинаций мультиагентных систем на примере uReview от Uber
Как отсеивать ненужные фрагменты кода до вызова LLM с помощью AST-парсинга
Передача сырых git-диффов и всего исходного кода в устаревший монолит приводит к огромным расчетам за токены. Представленная Uber в 2025 году платформа uReview автоматически анализировала 90 процентов из 65 000 изменений, поступающих каждую неделю из шести монорепозиториев. Однако если подавать модели код с нечеткими границами модулей без предварительной очистки, затраты на токены возрастают в 6 раз. Модель, не понимающая глобальные классы фабрик, начинает требовать несуществующие проверки на null и галлюцинирует. В тот момент, когда у разработчиков накапливаются бесполезные комментарии, они отключают уведомления и у них развивается «баннерофобия».
Необходимо написать препроцессор на базе стандартного модуля ast в Python, который выделяет только измененные сигнатуры функций и затронутые локальные переменные. После очистки статических метаданных модификации, не связанные с функциональностью, удаляются с помощью сравнения хэшей. Затем для создания легкой JSON-полезной нагрузки выполняются обратный парсинг сигнатуры нижнего узла функции, содержащего измененные строки, и самих измененных инструкций.
Бенчмарк на 100 устаревших модулях наглядно показывает разницу. Передача сырых файлов расходует 42 000 токенов и 0,273 доллара на один PR. С другой стороны, использование AST-препроцессора и сжатия в JSON снижает показатели до 6 100 токенов и 0,068 доллара на PR. Стоимость API уменьшается на 47,3 процента, а доля галлюцинаторных ложноположительных срабатываний падает до 9,4 процента.
Как разорвать бесконечные циклы между агентами с помощью схемы конечных автоматов
Если объединить агент безопасности и агент бизнес-логики в интерактивный групповой чат, они начинают бесконечно перебрасываться результатами вывода, попадая в цикл пинг-понга. Анализ одного PR занимает десятки минут, а затраты на API взлетают. Нельзя позволять агентам общаться напрямую. Необходимо создать фреймворк конечного автомата, используя схемы Pydantic и LangGraph.
Каждый специализированный агент получает только состояние центрального конвейера и возвращает результаты оценки в строго определенном моделью формате в соответствии со своими доменными правилами. С помощью Pydantic определяется класс данных, который принудительно задает идентификатор, путь к файлу, степень серьезности и показатель уверенности для вывода агента. Устанавливается условное ребро, которое принудительно прерывает конечный автомат, если количество итераций достигает двух или если уверенность во всех комментариях сходится к значению 0.85 и выше.
В соответствии со стандартом семантических соглашений OpenTelemetry GenAI выполнение каждого агента нужно обернуть в уникальный диапазон (span), а данные об использовании токенов отправить в бэкенд распределенной трассировки. Применение этой структуры сокращает время отладки техлидов, которое раньше уходило на устранение сбоев агентов, более чем на 6 часов в неделю.
Как достичь 70-процентного уровня принятия разработчиками с помощью скрипта проверки белых списков
Согласно данным по эксплуатации внутреннего инструмента статичного анализа Tricoder в Google, каким бы точным ни было замечание инструмента, если разработчик чувствует, что его не стоит исправлять, растет лишь враждебность. Анализаторы с уровнем ложноположительных срабатываний выше 5 процентов немедленно выводятся из эксплуатации. Чтобы добиться принятия более чем 67 процентов автоматических комментариев к ревью, необходим поэтапный запуск, начиная с наименее рискованных модулей.
В течение трех недель запускается теневой режим, скрывающий комментарии в выбранных слоях (например, в слое валидации DTO и чистых функциях без побочных эффектов). После подтверждения точности на уровне 85 процентов инлайн-комментарии открываются для бэкенд-кода трех доменных команд, и отслеживается уровень их принятия. Еженедельно собираются журналы отзывов, и запускается скрипт обратной связи, который автоматически удаляет из белого списка и отправляет в список изоляции правила с высоким уровнем ложных срабатываний, чей показатель принятия упал ниже 67 процентов. Интеграция этого скрипта проверки белого списка в конвейер позволяет быстро отсеивать раздражающие разработчиков бесполезные правила и достичь 70-процентного уровня принятия системы код-ревью в команде.