Что такое NarrateAI и почему контроль качества LLM - это инженерная задача
NarrateAI - ассистент для бизнес-аналитики на Amazon Bedrock, который обслуживает более 4000 руководителей AWS и отвечает на вопросы о метриках в реальном времени, удерживая числовую точность около 99%. Публикация AWS о его архитектуре разбирает пять техник, которые дают такой результат: адаптивную оркестрацию пайплайна, мультимодельный фейловер между аккаунтами, потоковую оценку в реальном времени, композитную систему оценщиков и двухэтапную верификацию числовых данных.
Разрыв между возможностями LLM и требованиями продакшна виден на конкретных сбоях: галлюцинированные метрики, троттлинг API, задержка валидации и субъективный язык в ответах. Руководитель, который спрашивает, какие регионы не выполняют план и почему, получает цифры, на которые опирается в решениях о бюджетах. Ошибка в числе здесь дороже, чем неидеальная формулировка.
Пять техник NarrateAI образуют многоуровневую цепочку зависимостей: каждый слой питает следующий, чтобы из сырого запроса получить валидированный ответ в реальном времени. Каждая техника закрывает отдельный режим отказа и работает в связке с остальными.
Двухслойная архитектура: пакетная генерация и диалоговый интерфейс
Система построена на Amazon Bedrock AgentCore и делится на два слоя с разными требованиями к задержке.
| Слой | Режим работы | Акцент контроля качества |
|---|---|---|
| Automated Narrative Generation Layer | Пакетная обработка | Более тяжёлая валидация: задержка не критична, можно проверять глубже |
| Conversational AI Interface Layer | Реальное время | Проверки должны укладываться в бюджет задержки, поэтому встроены прямо в поток |
Разделение важно по одной причине. В пакетной генерации контроль качества можно отложить и прогнать сколько нужно проверок. В диалоге пользователь ждёт ответ, и любая синхронная проверка на выходе превращается в паузу. Пять техник работают в обоих слоях, но в реальном времени акцент смещается на те, что совмещают проверку с генерацией.
Пять режимов отказа, которые закрывают техники
У каждой техники есть конкретная проблема, ради которой она появилась.
| Режим отказа | Техника |
|---|---|
| Галлюцинированные метрики | Data Accuracy Verification |
| Троттлинг API | Cross-Account Multi-Model Failover |
| Задержка валидации | Real-Time Streaming Evaluation |
| Субъективный язык | Composite Evaluation Framework |
| Неоптимальная маршрутизация | Adaptive Pipeline Orchestration |
Такой разбор полезен тем, что показывает логику проектирования: сначала перечисляют способы, которыми LLM ломает продакшн, потом под каждый строят отдельный механизм. Дальше - устройство каждой техники и её ограничения.
Адаптивная оркестрация пайплайна: маршрутизация запросов по объёму данных
Adaptive Pipeline Orchestration маршрутизирует запросы по объёму данных: большинство выполняются за один быстрый проход, а сложные получают полную параллельную обработку. Смысл простой. Не нужно гонять дорогую многоступенчатую проверку там, где хватит одного прохода, и не стоит экономить там, где данные требуют полной обработки.
Пороговая маршрутизация: как определить сложность запроса
Конкретные пороги и метрики AWS в этом материале не публикует, поэтому дальше - общий каркас, который переносится на свой пайплайн. Порог обычно считают по нескольким признакам: объём выборки (число строк или записей), количество сущностей в запросе, число требуемых агрегаций и соединений, наличие прогноза или сравнения периодов.
Пример. Запрос «покажи выручку за квартал» - это один агрегат по одной таблице, ему хватает быстрого прохода. Запрос «сравни динамику по 20 регионам с прогнозом» тянет за собой десятки агрегаций и внешнюю модель, поэтому получает полную параллельную обработку.
Порог - настраиваемый параметр. Он задаёт баланс между скоростью и точностью: сдвинешь в одну сторону, получишь быстрые, но иногда поверхностные ответы; сдвинешь в другую - точные, но с большей задержкой и стоимостью. Меньше сложных запросов уходит на дорогие оценщики, значит, снижается и нагрузка, и время ответа.
Ограничения подхода: когда адаптивность не спасает
Если порог выставлен неверно, сложный запрос может уйти в быстрый проход и дать неточность. Ошибка тут проявляется не как сбой, а как правдоподобный, но неполный ответ, что хуже всего. Адаптивная маршрутизация не решает проблему троттлинга - для этого есть отдельная техника, мультимодельный фейловер. Пороги требуют мониторинга и калибровки: распределение запросов меняется, и то, что работало на старте, со временем устаревает.
Мультимодельный фейловер между аккаунтами: обход квот Amazon Bedrock
Cross-Account Multi-Model Failover расширяет доступную ёмкость вывода за счёт независимых пространств квот модель-аккаунт. Это прямо снижает троттлинг, который видит пользователь.
Пространства модель-аккаунт: как устроены квоты Bedrock
Квоты Amazon Bedrock привязаны к паре (модель, аккаунт). Один и тот же запрос к той же модели из разных аккаунтов расходует разные лимиты. Несколько аккаунтов и несколько моделей дают несколько независимых пулов ёмкости, и нагрузку можно распределять между ними горизонтально. Точных значений квот AWS в этом материале не приводит, но принцип независимости лимитов и лежит в основе техники.
Стратегия фейловера: приоритеты, задержки, стоимость
Логика каскада простая: primary, затем secondary, затем tertiary. Когда основная модель в аккаунте A упирается в лимит и Bedrock возвращает ThrottlingException, запрос уходит в аккаунт B или на другую модель. Схема «одна модель на один аккаунт» быстро становится бутылочным горлышком, а каскад держит ответ доступным.
Компромиссы здесь реальны. Модели различаются по задержке, стоимости и качеству ответа, а само переключение добавляет свою задержку. Фейловер не должен ухудшать точность, поэтому его результат проходит через оценщики и верификацию чисел: если резервная модель даёт другой текст, качество всё равно проверяется по общим правилам. Управлять несколькими аккаунтами и следить за их квотами сложнее, чем одним, но для нагрузки уровня 4000 руководителей это оправданная плата за доступность.
Потоковая оценка в реальном времени: валидация каждого абзаца на лету
Real-Time Streaming Evaluation проверяет каждый абзац в момент его создания, совмещая контроль качества с генерацией. Вместо того чтобы сначала сгенерировать весь ответ и потом запустить проверки, система валидирует текст по мере поступления.
Паттерн producer-consumer для потоковой валидации
Детали реализации AWS в этом материале не раскрывает, поэтому опишу типовой каркас. Producer - генератор текста, он выдаёт абзацы по мере готовности. Consumer - пул оценщиков, которые берут абзацы из очереди и проверяют их асинхронно. Пока модель пишет второй абзац, первый уже проверен: либо одобрен, либо отправлен на доработку.
Если абзац не проходит проверку, можно перегенерировать только его, не останавливая весь поток. Это ключевое отличие от последовательной схемы, где сбой в середине заставляет переделывать всё. Такой каркас требует асинхронной архитектуры, очереди и буферизации: нужно хранить незавершённые абзацы, синхронизировать вердикты оценщиков и не терять порядок фрагментов в финальном ответе.
Снижение задержки на 86,8%: откуда берётся цифра
По данным AWS, потоковая оценка сокращает задержку оценки на 86,8% по сравнению с последовательной постобработкой. В посте приведены и сама цифра, и контекст сравнения. Важное уточнение: это сокращение времени именно оценки, а не всего времени ответа. При последовательном подходе проверка стартует после последнего токена, и генерация с валидацией складываются. При потоковой они идут параллельно, и время проверки почти прячется за временем генерации.
Выигрыш такого размера объясняется тем, что оценка перестаёт быть отдельным этапом в критическом пути. Чем длиннее ответ, тем заметнее эффект: пока текст пишется, проверки уже отрабатывают. Для диалогового интерфейса, где пользователь ждёт ответ, эта разница ощутима напрямую.
Композитная система оценщиков: несколько независимых проверок на каждый абзац
Composite Evaluation Framework запускает несколько независимых оценщиков параллельно для каждого абзаца. Один оценщик редко ловит все проблемы, поэтому проверки разделяют по задачам.
Типы оценщиков и их вклад в точность
Набор обычно включает проверку числовой точности, которая пересекается с верификацией данных; стилистическую нейтральность, убирающую субъективные формулировки; проверку на галлюцинации; соответствие политикам и формату. Каждый оценщик может быть как rule-based (регулярные выражения, словари, сравнение с данными), так и LLM-based (судья, который оценивает смысл). Rule-based дешевле и предсказуемее, LLM-based гибче, но дороже и сам может ошибаться. Оценщик-судья ставит скор по заданной метрике, и его поведение нужно контролировать так же, как и основную модель. Как это делают в похожих задачах, разобрано в материале про оценку длинных отчётов с LLM-as-judge и в разборе двухуровневого мониторинга агентов с AgentCore Evaluations.
Агрегация результатов: как принять решение по абзацу
Варианты агрегации: порог по каждому оценщику, взвешенная сумма или правило консенсуса. Выбор зависит от критичности проверки. Для числовых данных пороги жёсткие: несовпадение числа с источником блокирует абзац. Для стиля пороги мягкие: неудачная формулировка не повод перегенерировать весь фрагмент. Агрегация сама должна быть быстрой, иначе выигрыш по задержке от потоковой оценки растворится в ожидании вердикта. Практичный приём - считать самые важные проверки первыми и отсекать абзац, как только провален критичный критерий, не дожидаясь остальных.
Двухэтапная верификация числовых данных: от точного сопоставления до семантической проверки
Data Accuracy Verification ловит числовые галлюцинации через двухэтапный каскад. Логика каскада строится на экономии: дешёвая проверка отсеивает большинство чисел, дорогая достаётся только спорным случаям.
Точное сопоставление: самый дешёвый и быстрый фильтр
Первый этап - точное сопоставление. Числа из ответа сверяются с исходными данными: базой, извлечёнными таблицами, результатами агрегаций. Если число найдено, оно помечается как валидное. Работает это через хеш-таблицы или поиск по индексу и стоит доли миллисекунды.
Техническая тонкость - нормализация форматов. «12%», «12,0 %», «0.12» и «двенадцать процентов» означают одно и то же, и перед сравнением их нужно привести к единому виду: убрать разделители разрядов, унифицировать валюты, проценты и единицы. Без нормализации точный матчинг даёт ложные промахи, и лишние числа уходят на дорогой второй этап. В материале AWS первый этап описан как дешёвое точное сопоставление, именно с него начинается каскад.
Семантическая проверка через LLM: когда точное сопоставление не сработало
Второй этап включается, когда числа в исходных данных нет. Полное описание этого этапа в доступном фрагменте поста AWS обрывается, поэтому дальше - общий принцип, который применяют для таких задач. LLM получает число, контекст ответа и исходные данные и отвечает, обоснованно ли это число: могло ли оно получиться вычислением, агрегацией или сравнением периодов. Пример. Ответ утверждает, что выручка выросла на 12%. Точное сопоставление ищет 12% в данных и не находит, если в источнике лежат только абсолютные значения. Тогда LLM проверяет, равна ли разница между двумя числами 12%.
Ограничение очевидно: LLM тоже ошибается, поэтому второй этап дороже и медленнее первого и требует дополнительного контроля, например порога уверенности или проверки расчёта детерминированным кодом. Каскад оправдан тем, что большинство чисел проходят первый этап и второй не запускается. Общие подходы к измерению качества и борьбе с галлюцинациями в подобных системах собраны в гайде про метрики качества RAG и защиту от галлюцинаций.
Как пять техник работают вместе: цепочка зависимостей и итоговая точность 99%
Пять техник образуют многоуровневую цепочку, где каждый слой питает следующий. Вместе они позволяют достичь около 99% числовой точности при потоковой выдаче ответов.
Схема взаимодействия: от запроса до валидированного ответа
Путь запроса выглядит так: адаптивная оркестрация выбирает маршрут и ресурсы, генерация идёт с возможностью фейловера при троттлинге, потоковая оценка проверяет абзацы на лету, композитные оценщики выносят вердикт по качеству, двухэтапная верификация подтверждает числа. На каждом шаге возможны циклы обратной связи: проваливший проверку абзац уходит на регенерацию, не останавливая остальной поток.
Роли распределены чётко. Оркестрация решает, какие ресурсы задействовать. Фейловер держит систему доступной. Потоковая оценка даёт быструю обратную связь. Оценщики следят за качеством текста. Верификация чисел ловит галлюцинации. Каждая техника закрывает свой режим отказа, а вместе они работают как скоординированная система, а не как набор независимых проверок.
Ограничения и компромиссы: цена точности
За 99% приходится платить. Архитектура усложняется: несколько слоёв проверок, очередь и асинхронная обработка, управление несколькими аккаунтами Bedrock. Оценщики добавляют затраты на инференс, особенно LLM-based. Регенерация абзацев увеличивает задержку, пусть и локально. И главное уточнение: 99% - это числовая точность, а не общая корректность ответа. Формулировки, полнота и релевантность измеряются иначе.
Для части сценариев такой уровень избыточен. Внутренний чат-бот для черновиков не нуждается в двухэтапной верификации каждого числа. Там, где ответы влияют на решения руководителей, цена ошибки оправдывает сложность. Выбор уровня контроля - вопрос стоимости ошибки, а не технической моды.
Что можно перенять: практические выводы для своих LLM-пайплайнов
Несколько паттернов NarrateAI переносятся в собственный пайплайн без копирования всей архитектуры.
- Пороговая маршрутизация по объёму данных. Считайте простые запросы одним проходом, сложные отправляйте на полную обработку. Начните с грубого порога по числу сущностей и агрегаций, потом калибруйте по логам.
- Producer-consumer для потоковой валидации. Запускайте проверки параллельно генерации, держите очередь между генератором и пулом оценщиков. Абзац, проваливший проверку, перегенерируйте отдельно.
- Каскадная верификация чисел. Сначала дешёвый точный матчинг с нормализацией форматов, только потом семантическая проверка через LLM. Это снижает стоимость без потери покрытия.
- Несколько оценщиков параллельно. Разделяйте проверки по задачам и агрегируйте вердикты с разными порогами: жёстко для чисел, мягко для стиля.
Мультиаккаунтный фейловер требует организационных усилий и подходит не всем: управлять несколькими аккаунтами Bedrock и следить за их квотами заметно сложнее, чем работать в одном. Начинать разумно с одного-двух паттернов, измеряя эффект на своих метриках. Как измерять качество и не обманываться цифрами, подробно разобрано в статье о том, как evaluation awareness завышает safety-метрики в model card.
Практическая ценность набора NarrateAI в том, что он показывает: контроль качества LLM - это распределённая инженерная задача, а не один фильтр на выходе. Точность держится не на самой сильной модели, а на том, что каждый этап проверяет свою часть работы.