KDDI сократила задержку RAG-приложения Buffmee на 38%

Buffmee соединяет диалоговый интерфейс и лицензированный контент

KDDI вместе с Google Cloud описала инженерную работу над Buffmee — потребительским Retrieval-Augmented Generation приложением для поиска, краткого пересказа и изучения персональных интересов. Сервис опирается более чем на 100 источников, среди которых книги, журналы и веб-медиа, и показывает ссылки на материалы, использованные для ответа.

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

Google Cloud сообщает, что после оптимизаций общая задержка приложения снизилась на 38%, а Time To First Token улучшился почти на 18%. Эти показатели описывают кейс KDDI и не являются универсальным обещанием для любого RAG-приложения: исходная архитектура, документы, модель, длина контекста и инфраструктура у других продуктов будут отличаться.

Сотни тестов заменили ручную выборочную проверку

Команда построила автоматическую оценку на Gemini Enterprise Agent Platform Evaluation Service. В публикации названы LLM-as-a-Judge и Rule of Hundreds: корпус документов загружали в систему, генерировали сотни тестов и собирали benchmark dataset для проверки надёжности ответов по каждому сценарию использования.

По данным Google Cloud, этот цикл повысил groundedness score на 25%. AI генерировал вопросы и оценивал ответы, а люди калибровали пороги и разбирали пограничные ошибки. Последняя часть принципиальна: автоматический judge превращается в метрику только после сопоставления с продуктовым решением о том, какой ответ действительно достаточно хорош для выпуска.

Для критических характеристик команда отказалась от неоднозначной шкалы от одного до пяти в пользу бинарного pass/fail. Такой формат уменьшает вариативность, но требует точного определения условия прохождения. Если тест проверяет наличие ссылки, это относительно объективно; если он оценивает полноту сложного пересказа, человеческая калибровка и анализ ошибок всё равно остаются необходимыми.

Репрезентативная выборка сократила объём оценки на 75%

Проверять каждый документ отдельно оказалось непрактично. KDDI распределила корпус по двум измерениям: формат файла — веб-статья, EPUB, PDF или structured data — и состав медиа, то есть преимущественно текстовый, преимущественно визуальный или смешанный материал. Затем из каждой ячейки этой матрицы выбирали репрезентативные примеры.

Google Cloud оценивает сокращение нагрузки на evaluation в 75% при сохранении широкого покрытия типов контента. Это не означает, что три четверти тестов можно безопасно удалить из любого проекта. Метод работает, только если классификация действительно отражает источники трудности, а выборка включает редкие, но рискованные форматы и сценарии.

Практический урок шире конкретного сервиса: тестовый набор должен описывать пространство входных данных, а не повторять наиболее удобный формат. Средняя точность на текстовых веб-страницах мало говорит о таблице в PDF, иллюстрированном EPUB или документе со сложной структурой. Матрица KDDI делает эти различия явной частью evaluation design.

Production-логи показали цену длинных промптов

Для анализа задержек разработчики использовали BigQuery Agent Analytics и агент разбора логов на Agent Development Kit. По production-следам они визуализировали, как разделение skills, маршрутизация sub-agents и разрастание системного промпта влияют на TTFT. Особое внимание привлекли сложные многостраничные инструкции.

В кейсе говорится, что системные промпты объёмом более 800 строк способны вызывать attention drift и увеличивать задержку. Команда разделила логику по функциям на ADK Skills и загружала только нужные инструкции. Одновременно были пересмотрены inline integration навыков и маршрутизация sub-agents.

Модульность здесь нужна не ради более красивого репозитория. Если конкретный запрос получает только относящиеся к нему правила, модель обрабатывает меньше нерелевантного контекста, а трассировка показывает, какой маршрут создал задержку. Но разделение инструкций добавляет собственный риск: роутер должен стабильно выбрать нужный skill, иначе ускорение оплачивается потерянным ограничением или функцией.

Метрики кейса нужно читать вместе, а не по одной

В официальной публикации рядом стоят четыре результата: минус 38% общей задержки, почти 18% улучшения TTFT, плюс 25% groundedness score и минус 75% evaluation workload благодаря выборке. Такое сочетание сильнее одиночного ускорения, потому что команда заявляет одновременно производительность, качество и управляемость тестирования.

Однако Google Cloud не публикует абсолютные миллисекунды до и после оптимизации, размер benchmark dataset, точные формулы groundedness score или доверительные интервалы. Нет и независимого сравнения с альтернативной инфраструктурой. Поэтому числа позволяют понять направление и масштаб изменений внутри Buffmee, но недостаточны для прямого прогноза экономики другого приложения.

Формулировку о надёжности также важно не превращать в утверждение об абсолютном отсутствии hallucinations. Описанный процесс снижает измеренные ошибки на выбранном наборе и позволяет находить bottlenecks в реальных логах; он не доказывает невозможность неверного ответа на новом запросе. Для операционной команды полезен сам цикл: репрезентативный benchmark, бинарные критические проверки, человеческая калибровка, production telemetry и повторная оценка после каждого изменения.