«Пять проверок на каждый абзац»: AWS показала контроль качества LLM на Amazon Bedrock

Что показала AWS

NarrateAI — внутренний ассистент AWS для руководителей: он собирает корпоративные документы в персональные нарративы и отвечает по ним на естественные вопросы, а пользуются им более 4 000 активных руководителей AWS от CEO до региональных менеджеров.

Первый пост серии описывал двухслойную архитектуру — пакетную генерацию нарративов и разговорный слой реального времени на Amazon Bedrock AgentCore, который снял необходимость строить собственную оркестрацию.

Новый разбор идёт глубже и показывает инженерную часть: как пять техник вместе дают около 99 процентов числовой точности, при том что ответы стримятся в реальном времени.

Техники такие: адаптивная оркестрация конвейера, отказоустойчивость между аккаунтами и моделями, оценка прямо в потоке, композитная оценка и проверка достоверности данных.

В продакшене недостаток этой инженерии ощущается как выдуманные метрики, троттлинг API, задержка валидации и субъективный язык — то есть именно то, что подрывает доверие к аналитическому ассистенту.

Адаптивная оркестрация: один быстрый путь и один полный

Запросы к корпоративным документам очень разной тяжести, поэтому конвейер маршрутизирует их по объёму данных: большинство проходит одним быстрым проходом, а сложные запросы получают полную параллельную обработку.

Порог θ калибруется относительно размера контекстного окна модели и подбирается так, чтобы быстрым путём уходило 70–90 процентов запросов; на практике по нему идёт около 90 процентов.

Быстрый путь — это один вызов LLM со всем контекстом и прямая потоковая выдача в конвейер оценки. Нормальный путь раскладывает секции в оптимальные батчи с учётом границ документов и разводит их по N параллельным вызовам, а третья фаза, условная консолидация, сводит N независимых анализов в один ответ и работает только на нормальном пути.

Экономия получается заметная: при типичных N = 4 батча смешанная стоимость запроса — примерно 1,4 вызова LLM, то есть на 72 процента меньше вызовов, чем при постоянной многопроходной схеме.

По задержке разрыв тоже понятный: быстрый путь укладывается в несколько секунд до первого токена и обычно меньше 25 секунд суммарно, тогда как сложные многодокументные запросы занимают 50–75 секунд.

Ёмкость вместо ожидания

Пиковые периоды, когда тысячи пользователей одновременно запускают свои разборы, опасны тем, что один троттлинг подрывает доверие к инструменту и возвращает людей к ручным таблицам.

Квоты Amazon Bedrock независимы по модели и по аккаунту, поэтому конфигурация из трёх моделей на трёх аккаунтах даёт девять независимых квотных пространств.

Вместо стандартного BedrockModel команда поставила кастомного провайдера для Strands Agents SDK — совместимую замену, которая прозрачно расширяет ёмкость, не ломая код агентов. Перед каждой попыткой отказа список ARN ролей перемешивается через random.shuffle(), а ThrottlingDetector ловит ThrottlingException, ServiceQuotaExceededException и TooManyRequestsException и немедленно переходит к следующей комбинации «аккаунт + модель».

Свежие креды через AWS Security Token Service (STS) AssumeRole стоят 100–200 мс — на фоне многосекундных задержек экспоненциального backoff с джиттером это пренебрежимо мало.

Нагрузочный тест Locust подтвердил расчёт: система выдержала запросы более ста пользователей одновременно в течение длительного периода и без единого отказавшего запроса.

Оценка без паузы

Оценщик подключён потребителем в схеме producer-consumer, где производитель отдаёт абзацы, поэтому единица работы здесь абзац, а не весь ответ.

Генерация абзаца занимает секунды, а детерминированные проверки укладываются в десятки миллисекунд, так что запаса устойчивости хватает с большим избытком и оценка в обычном случае остаётся для пользователя незаметной.

На быстром пути абзацы, которым нужны только детерминированные проверки — слова-паразиты и эмодзи, — оцениваются примерно за 79 мс медианы, то есть коэффициент загрузки ρ ≈ 0,095, далеко ниже единицы.

Накладные расходы измерили на 1 000 продакшен-запросов, что дало около 10 439 абзацев: медианное время до первого контента — 13,2 секунды против 11,8 секунды у потока вообще без проверок, то есть плюс 1,4 секунды, и против 100,2 секунды у последовательной оценки после генерации.

Иначе говоря, параллельная схема снижает задержку на 86,8 процента по сравнению с последовательной оценкой, а те самые 1,4 секунды — это разовая стоимость оценки первого абзаца, пока конвейер не вышел на установившийся режим.

Композитная оценка и двусторонняя ответственность

Монолитный валидатор закрывает только один режим отказа, поэтому по каждому абзацу параллельно идут независимые оценщики, объединённые общим интерфейсом.

Три референсных оценщика бьют по ортогональным проблемам: WeaselWordEvaluator регэкспами требует количественных формулировок вместо субъективных оценок, EmojiEvaluator вычищает Unicode-эмодзи ради формального тона, а DataAccuracyEvaluator ловит числовые галлюцинации — самый рискованный режим отказа в бизнес-аналитике.

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

Композитность здесь не формальность: почти четверть отмеченных абзацев задевала два и более оценщика сразу, а значит при единственном оценщике второй режим отказа остался бы незамеченным полностью.

Ответственность за ИИ в системе двусторонняя: Amazon Bedrock Guardrails фильтрует каждый входящий запрос до начала генерации, а композитные оценщики проверяют каждый исходящий абзац до того, как он дойдёт до пользователя.

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

Две ступени проверки чисел

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

Цена ошибки наглядно показана на примере: «$441M» вместо фактических «$414M» — расхождения достаточно, чтобы решения о распределении ресурсов стали неверными раньше, чем кто-либо заметит опечатку.

Каскад начинается с дешёвого точного сравнения на регэкспах и операциях над множествами: метрики без совпадений помечаются как UNVERIFIED, и на этом проверка фабрикации заканчивается с минимальной стоимостью.

Дальше включается SequenceMatcher: он считает схожесть ρ между контекстом ответа и контекстом источника по окнам в w = 50 символов, а для случаев с низкой схожестью поднимается ContextualDataAgent с семантической проверкой.

Экономика каскада измерена по шагам: первая ступень — около 0,3 мс, строковое сравнение — примерно 1,7 мс, семантическая проверка через LLM — около 1 758 мс за вызов; первую ступень проходит 87 процентов метрик, и только 30 процентов из них требуют дорогой проверки.

В итоге средняя стоимость метрики — примерно 812 мс, что на 54 процента ниже монолитной LLM-проверки.

Что из этого вынести

Итог шестимесячной эксплуатации: ответы начинают стримиться примерно за 13 секунд, числовая точность держится на 99,3 процента, и всё это без выделенной инфраструктуры валидации, увеличения квот и узких мест сериализации.

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

Добавлять новые оценщики можно и дальше: это корректно, пока суммарный ρ по всем оценщикам остаётся ниже единицы — именно это условие держит потоковый конвейер устойчивым.