RSS VentureBeat
Подписаться
Когда Клод изменился, изменилось всё: управление радиусом поражения ИИ в производстве
Эта система эффективно переводила запросы на естественном языке в API-вызовы, обслуживая аналитиков и менеджеров аккаунтов, оптимизируя сборку данных из различных источников. Это достигалось путём отправки API-вызовов на интегрированные серверы, применения JSON-запроса, генерируемого LLM, для формирования ответов и доставки результатов через электронную почту, документы Drive или диаграммы браузера. К середине 2025 года он стал стандартным методом спонтанного поиска данных, генерируя несколько сотен отчетов ежемесячно для внутренних и внешних заинтересованных сторон.
Основное взаимодействие основывалось на структурированном JSON-объектном контракте между LLM и системой. Первоначальные обновления модели с Claude Sonnet 3.5 до 4.0 прошли безупречно, что способствовало самодовольству в отношении стабильности LLM. Однако обновление Sonnet 4.5 вызвало две серьёзные проблемы. Во-первых, модель начала встраивать post_body содержимое в поле описания, что приводило к пустым параметрам фильтра для вызовов API, что приводило к широкому поиску данных или 500 ошибкам. Во-вторых, Sonnet 4.5 начал задавать уточняющие вопросы — функцию, для которой система, предназначенная для прямых вызовов API без человеческого взаимодействия или управления состоянием, не имела установленного пути.
Эти сбои потребовали отката до Sonnet 4.0, что осложнялось новыми интеграциями API, квалифицированными для версии 4.5. Этот инцидент показывает, как системы, поддерживаемые LLM, противоречат традиционной инженерной дисциплине, поскольку внутренние компоненты не находятся под контролем разработчиков, что приводит к непредсказуемым «бесконечным радиусам взрыва» для изменений. Вскрытие выявило недостаточно определённую подсказку; предыдущие версии моделей подразумевали ограничения, которые Сонет 4.5, будучи более «полезным», нарушал.
Авторы предлагают архитектуру «evaluat-first», где формальной спецификацией системы выступает набор оценок, а не подсказка. Оценки состоят из входных данных, необходимых выходных свойств и функции оценки для проверки изменений моделей или подсказок. Пример оценки проверял, содержит ли поле описания сериализованное содержимое полезной нагрузки. Хотя это дорого в производстве и обслуживании, оценки действуют как «ворота», ограничивая радиус взрыва за счёт плотного отбора входно-выходного поведения.
Несмотря на свою полезность, оценки не являются панацеей; они могут фиксировать только определённые режимы отказа и вводить собственную дисперсию с помощью LLM-as-judge. Инженерное сообщество по-прежнему не имеет стандартов для покрытия оценки в естественном языке и систем CI/CD для вероятностных тестов. Сокращение разрыва между прохождением дымовых тестов и предсказанием поведения производства, особенно по мере того, как агенты становятся более автономными, — это критически важная инженерная задача. Команды, которые отдают приоритет оценкам как истинной спецификации системы, будут лучше всего подготовлены к решению этой задачи.
