Когда Клод изменился, изменилось всё: управление радиусом поражения ИИ в производственной среде.
Сарат Махавратаяджула , Виджай Сагар Гуллапалли
Наша система делала одну вещь, и делала это хорошо: она преобразовывала вопросы на естественном языке в вызовы API.
Пользователями системы были аналитики, менеджеры по работе с клиентами и руководители операционных отделов. Они знали, какие данные им нужны, но их сбор вручную означал использование четырех панелей мониторинга, двух инструментов бизнес-аналитики и конструктора отчетов Salesforce. С нашей системой они просто вводили запрос простым языком. Запрос типа «Составить отчет об объеме продаж за период с января по март 2026 года для Северо-восточного региона с разбивкой по городам» преобразовывался в вызов API, который система могла обработать:
json
{
«Описание»: «Запрошенный пользователем объем продаж за указанный диапазон дат. Вот вызов API для получения ответа.»
«api_call»: «/api/sales_volume»,
«post_body»: {
«start_date»: «2026-01-01»,
«end_date»: «2026-03-31»,
«регион»: «северо-восток»
}
}
Остальная часть процесса обработки данных представляла собой обычную инженерную задачу. Система направляла запрос в нужный бэкэнд — у нас была интеграция с внутренними порталами отчетности, Salesforce и несколькими собственными сервисами — применяла сгенерированный с помощью большой языковой модели (LLM) JSON-запрос для фильтрации и формирования ответа и доставляла его по электронной почте, в виде документа Google Drive или в виде диаграммы в браузере.
К середине 2025 года система генерировала несколько сотен отчетов в месяц. Эти отчеты использовались руководством и аналитиками, а также распространялись среди внешних заинтересованных сторон. Для большинства команд это стало основным способом получения данных по запросу.
Контракт между LLM и остальной частью системы представлял собой структурированный JSON-объект, как описано в приведенном выше примере.
json
{
«Описание»: «Запрошенный пользователем объем продаж за указанный диапазон дат. Вот вызов API для получения ответа.»
«api_call»: «/api/sales_volume»,
«post_body»: {
«start_date»: «2026-01-01»,
«end_date»: «2026-03-31»,
«регион»: «северо-восток»
}
}
Мы создали его на основе Claude Sonnet 3.5 в начале 2025 года. Мы без проблем обновились до версии 3.7 и до 4.0. К моменту выхода Sonnet 4.5 мы успокоились относительно стабильности и предсказуемости LLM в решении, как нам казалось, простой проблемы. Обновления моделей стали обычным делом, как, например, обновление до минорной версии хорошо работающей библиотеки.
Затем мы внедрили версию 4.5. Для значительного процента запросов модель начала объединять содержимое поля post_body с полем описания. Последовали два режима сбоя.
Во-первых, параметры фильтра так и не дошли до API. Наша система считала поле post_body источником достоверной информации для полезной нагрузки запроса, и это поле возвращалось пустым. Вызов API был выполнен без фильтра по диапазону дат или региону. В зависимости от конкретного вызываемого API, бэкэнд либо возвращал объем продаж за все время или по всем регионам, либо возвращал ошибку 500.
Во-вторых, модель начала задавать уточняющие вопросы в своих ответах. Это было нововведением. Более ранние версии всегда старались максимально эффективно обрабатывать неоднозначные запросы и возвращали структурированный объект. Sonnet 4.5, будучи более осторожной, иногда вместо этого отвечала вопросом. В нашей системе не было такого механизма. Она была построена на предположении, что каждый вызов модели будет приводить к вызову API. Отсутствовал компонент участия человека и состояние для хранения частично выполненного запроса. Это приводило к сбоям в работе последующих систем по нескольким направлениям.
Мы вернулись к версии 4.0. Это оказалось сложнее, чем должно было быть: между развертыванием версий 4.0 и 4.5 наша команда добавила новые интеграции API, все из которых были проверены на соответствие версии 4.5. Откат модели означал повторную проверку каждой из них на соответствие версии 4.0 в условиях ограниченного времени.
Почему традиционная инженерная дисциплина здесь терпит неудачу
Разработка программного обеспечения основывается на способности ограничить влияние изменений. При обновлении драйвера или библиотеки вы читаете примечания к выпуску, чтобы понять, следует ли ожидать критических изменений. Модульные тесты ограничивают то, что могло быть изменено. Вы можете использовать следующее свойство: изменяемая система достаточно детерминирована, чтобы ее поведение можно было предсказать или, по крайней мере, достаточно плотно исследовать, чтобы обеспечить уверенность. Радиус взрыва ограничен по своей природе.
Системы, использующие LLM, нарушают это предположение. Компонент, который формирует выходные данные, находится вне вашего контроля. Вы не можете просто сравнить версию модели с 4.0 до 4.5. Это полная замена функциональности, от которой зависит ваша система.
Вот что мы подразумеваем под бесконечным радиусом взрыва : изменение, последствия которого невозможно перечислить заранее, поскольку пространство входных данных (естественный язык) и режимы отказов (все, что модель могла бы сделать иначе) являются неограниченными.
Анатомия неудачи
Анализ ситуации показал, что наш запрос всегда был недостаточно конкретизирован. Мы указали модели возвращать JSON-объект с тремя полями. Мы описали назначение каждого поля. Мы не указали явно, что описание должно быть строкой на естественном языке и не должно содержать сериализованных представлений других полей.
Более ранние версии модели выводили это ограничение из контекста. Sonnet 4.5, очевидно, лучше справляясь с «полезностью» в выборе форматирования, решил, что запрос на уточнение или предоставление текста запроса в описании делает ответ более полезным. С точки зрения модели, это была разумная интерпретация неоднозначной инструкции. Однако это противоречило предположениям, на которых была построена наша система.
Ошибка заключалась не в модели. Ошибка была в нашем предположении, что модель продолжит заполнять пробелы в наших спецификациях, как это всегда происходило. Три успешных обновления приучили нас верить, что эти пробелы невредимы.
Структурированные режимы вывода и API для использования инструментов позволили бы выявить эту конкретную ошибку на уровне схемы. Мы не использовали их по инженерным причинам, выходящим за рамки этой статьи. Но схемы ограничивают только синтаксис, а не семантику. Схема не может указывать, что уточняющий вопрос не должен появляться в системе без возможности его уточнения, или что диапазон дат никогда не должен молчаливо устанавливаться по умолчанию на все время. Схемы решают более простую часть проблемы.
Архитектура, ориентированная на оценки.
Дисциплина, которая устраняет этот пробел, заключается в том, чтобы рассматривать набор оценочных заданий — а не подсказку — как формальную спецификацию системы. Подсказка — это реализация спецификации. Модель — это интерпретатор . Оценочные задания — это сама спецификация, и любое изменение модели или подсказки допустимо тогда и только тогда, когда оно проходит проверку.
На практике eval представляет собой тройку: входные данные, свойство, которому должны удовлетворять выходные данные, и функция оценки. Для нашей системы eval, которая выявила бы регрессию 4,5, выглядит примерно так:
питон
def test_description_contains_no_serialized_payload(response):
desc = response[«description»].lower()
forbidden = [«curl», «post_body», «{«, «http://», «https://»]
assert not any(token in desc for token in forbidden),
f»description leaked structured content: {response['description']}»
Несколько сотен таких свойств, некоторые из которых написаны вручную для известных важных инвариантов, некоторые сгенерированы в качестве регрессионных тестов на основе реального производственного трафика, а некоторые оценены экспертом с дипломом магистра права (LLM) по более расплывчатым параметрам, таким как тон, становятся своего рода «пропускным пунктом». Обновления модели и изменения в подсказках следует рассматривать как запросы на слияние (pull requests), которые должны получить одобрение всего набора тестов, прежде чем будут объединены.
Создание и поддержка систем оценки обходятся дорого. Их результаты меняются по мере развития продукта. Использование LLM в качестве судьи вносит свою собственную изменчивость в результаты. Кроме того, набор инструментов может выявлять только те виды отказов, которые вы предусмотрели — вы не сможете обеспечить безопасность от категории отказов, которые вы никогда не предполагали, с помощью оценок. Мы усвоили этот урок на собственном горьком опыте: никто в нашей команде никогда не писал утверждения типа «поле описания не должно содержать команду curl», потому что никто не думал, что модель её туда добавит.
Оценки — это не панацея. Они позволяют ограничить радиус поражения изменения единственным доступным способом, когда базовая функция представляет собой «черный ящик»: путем плотного отбора проб входного и выходного отклика, который вас действительно интересует, и отказа от развертывания, когда это поведение изменяется.
Дорожная карта
Инженерное сообщество еще не разработало свод знаний для написания эффективных отчетов об оценке. Нет общепринятых стандартов того, что означает «покрытие» в контексте ввода естественного языка. Системы CI/CD не были созданы для контроля вероятностных результатов тестирования. По мере того, как агенты берут на себя все более автономную работу — написание кода, перемещение денег, планирование изменений инфраструктуры — разрыв между «модель прошла наши дымовые тесты» и «мы знаем, что эта система будет делать в продакшене» становится центральной инженерной проблемой на ближайшие несколько лет.
Команды, которые смогут сократить этот разрыв, перестанут рассматривать оценки как второстепенный аспект обеспечения качества и начнут воспринимать их как фактическое описание того, что представляет собой их система.
Виджай Сагар Гуллапалли — инженер-основатель компании Adopt AI и изобретатель, имеющий патент USPTO.
Сарат Махавратаяджула — старший инженер-программист в Sherwin-Williams.
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевых публикаций — это площадка, где технические эксперты делятся своими знаниями и предоставляют нейтральные, непредвзятые аналитические материалы по искусственному интеллекту, инфраструктуре данных, кибербезопасности и другим передовым технологиям, формирующим будущее предприятий.
Узнайте больше о нашей программе гостевых публикаций — и ознакомьтесь с нашими рекомендациями, если вы заинтересованы в написании собственной статьи!
Подпишитесь, чтобы получать самые свежие новости!
Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.
Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.
Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.
Источник: venturebeat.com
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.