«Девять стадий вместо одного промпта»: Orca Security снизила цену запроса на 90%, переведя языковой поиск по облаку в Amazon Bedrock

В чём была проблема

Аналитикам по безопасности нужны быстрые ответы о своей облачной инфраструктуре без глубокого знания предметного языка запросов. Инструмент Orca Security охватывает более 900 облачных моделей — типов ресурсов, которые отслеживает Sonar, вроде инстанса Amazon Elastic Compute Cloud (Amazon EC2) или бакета Amazon Simple Storage Service (Amazon S3). Чтобы задать вопрос напрямую, требовалось точно знать имена моделей, навигировать по вложенным связям и выбирать из 18 операторов — функций сравнения, таких как «равно» или «содержит».

Идея была простой: сделать естественно-языковой интерфейс, который порождает корректные запросы к Sonar из обычного текста. Первый прототип команда собрала по принципу «загрузить всё»: полная схема Sonar в одном промпте на самой большой доступной модели — более 900 определений моделей, все типы связей и щедрый набор примеров запросов. Качество вышло сильным, но на производственном масштабе проявились три издержки.

Первая — расход токенов: примерно 2 млн входных токенов на рабочую нагрузку, что тянуло вверх стоимость. Вторая — задержка: около 60 секунд на ответ. Третья — ограниченная точность на сложных запросах с несколькими моделями, потому что вложенные связи и условия часто требовали дополнительной доводки. Концепция работала, но её нужно было сделать дешёвой, быстрой и достаточно точной для прода — так появилась архитектура, которая обслуживает тысячи запросов в день при 15-секундном отклике.

Девять стадий, у каждой — своя модель

Discovery AI собран как гибрид на Amazon Bedrock: генерация с дополнением через поиск (RAG) плюс конструирование запроса с учётом схемы, а каждый этап многоступенчатого конвейера отдан наиболее подходящей модели. Конвейер проходит девять шагов.

На входе — приём запроса и подготовка контекста: к вопросу пользователя добавляют организацию, подключённых облачных провайдеров и метаданные запроса, чтобы интерпретация точно соответствовала среде клиента. Затем быстрый детерминированный сопоставитель ловит структурные входы — IP-адреса, идентификаторы CVE, ARN, хеши файлов, идентификаторы Amazon Machine Image, идентификаторы Oracle Cloud и EC2, URL и идентификаторы алертов — регулярными выражениями и правилами, и при совпадении отдаёт готовый фильтр по быстрому пути вообще без инференса языковой модели.

Дальше включается защитный экран LLM Guardrail, который проверяет, что запрос безопасен, релевантен, техничен и поддерживается, и блокирует попытки внедрения промпта, офтоп-запросы и неподдерживаемые входы до того, как они дойдут до остального конвейера. После этого идёт семантический отбор кандидатов по эмбеддингам: поиск похожих ранее подтверждённых примеров через Amazon Titan Text Embeddings возвращает 20 ближайших соседей из векторного хранилища.

Затем нейросетевой реранкинг: кандидатов пересортировывает Cohere Rerank 3.5 на Amazon Bedrock и оставляет пять наиболее сигнальных примеров, а при точном или высокоуверенном совпадении конвейер может вообще переиспользовать уже проверенный фильтр. Следующий шаг — отбор релевантных моделей: он сужает более 900 моделей Sonar до небольшого набора, нужного под конкретный запрос, и передаёт генератору только схемы выбранных моделей — от компактных micro-схем до более подробных mini-схем, что убирает лишний контекст.

Генерацию ведёт агент с инструментами: он рассуждает над схемами выбранных моделей, найденными примерами, контекстом пользователя и доступными инструментами и итеративно доводит фильтр до корректного представления запроса. Затем — статическая проверка и проверка через API: фильтр проверяют на синтаксическую и семантическую корректность, а затем сверяют с Sonar API, и при ошибке она возвращается генератору, чтобы агент исправился и попробовал снова. Если число попыток исчерпано, конвейер возвращает ответ о невалидном фильтре; статическая проверка разворачивает каждую модель, поле и оператор обратно к определениям схемы, поэтому повторные попытки «перезаземляются», а не угадывают заново.

Распределение моделей по стадиям выглядит так: Anthropic Claude Haiku 4.5 работает на отборе моделей и в генераторе, где нужна сильная способность рассуждать; Amazon Nova 2 Lite отвечает за защитный экран и валидатор, где важнее быстрый инференс при меньшей стоимости; Amazon Titan даёт эмбеддинги для семантического поиска; Cohere Rerank 3.5 пересортировывает найденных кандидатов. Выбор пал на Amazon Bedrock ещё и потому, что он даёт доступ к нескольким моделям через единый API — команда назначает разные модели на разные стадии, не собирая отдельные интеграции, а архитектура, не привязанная к конкретной модели, позволяет подменять версии без перестройки конвейера.

Что дали замеры

Результаты в записи названы по трём осям — стоимость, задержка и точность. Использование входных токенов упало на 93%: примерно с 2 млн до 140 тыс. токенов на сопоставимую рабочую нагрузку. Общая стоимость снизилась на 90%, и это следствие не только меньшего числа токенов, но и распределения моделей по стадиям. Задержка полного ответа сократилась на 75% — примерно с 60 до 15 секунд. Точность на сложных запросах с несколькими моделями тоже выросла, и измерялась она непрерывно через собственный оценочный харнесс команды.

Отдельно авторы разбирают, что оказалось главным рычагом точности — поиск примеров. Чистый top-K семантический поиск на эмбеддингах Amazon Titan работал быстро, но тянул почти дублирующиеся примеры и лишал генератор разнообразия; метод максимальной маргинальной релевантности (MMR) добавлял разнообразие, но терял релевантность, когда верхний кандидат и был правильным ответом. Победила связка: выборка 20 ближайших соседей по эмбеддингам Titan, а затем реранкинг Cohere Rerank 3.5 до пяти примеров — небольшой, разнообразный и высокорелевантный набор без компромисса между покрытием и точностью на этапе поиска.

Как удерживают качество после запуска

Команда Orca построила оценочный харнесс в начале проекта, а не после: он соединяет подготовленный набор данных, автоматический слой оценки и измерение по срезам, чтобы каждому изменению можно было доверять до выката. Набор покрывает типы вопросов, семейства моделей и уровни сложности из реальной эксплуатации; слой оценки «LLM как судья» ставит сгенерированным запросам баллы по корректности, полноте и семантической эквивалентности эталонному запросу, а разбор по срезам показывает, где именно возникла регрессия и что исправлять. Любое изменение промпта, модели, параметра поиска или примера проходит через харнесс до прода.

Второй контур — разметка с участием экспертов: Orca сделала внутренний инструмент, которым менеджеры продукта, инженеры поддержки и исследователи безопасности помечают запросы, правят выводы и одним действием отправляют исправление в банк примеров. Система сама собирает производственные запросы с примерами низкой уверенности и направляет их профильному эксперту на ежедневную разметку, а следующий прогон подхватывает новый пример через Cohere Rerank 3.5 — и точность на этом классе вопросов улучшается тем же моментом, без деплоя.

«Интерфейс разметки — самая важная инвестиция, которую мы сделали ради долгосрочного качества. Он превращает Discovery AI из статичной выкатки в живую систему, которую наши эксперты непрерывно улучшают внутри своего обычного рабочего процесса», — приводит запись слова Ор Габая (Or Gabay), директора по ИИ в Orca Security. В продакшене Discovery AI работает с марта 2026 года и обслуживает тысячи запросов в день, а качество подтверждают внутренние эксперты и обратная связь от клиентов.

Что это значит — и чего публикация не доказывает

Это пост AWS и Orca Security о собственной системе, и цифры — заявления его авторов, а не результат независимого измерения: сторонней проверки по тексту нет. Как именно менялась точность, сказано только общо — «измерялась непрерывно через оценочный харнесс», без разбивки по типам вопросов и без абсолютных значений качества. Замеры стоимости и задержки привязаны к «сопоставимой рабочей нагрузке» и к первоначальной базовой линии, а не к универсальному эталону.

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