Оператору нужно быстро находить подходящую инструкцию в длинной и разветвлённой базе, учитывать обстоятельства клиента и готовить ответ. Прямая автоматизация не покрывает случаи вне документации, чувствительные разговоры и действия, требующие участия других людей.
Разделить работу между человеком и тремя моделями: искать целостные фрагменты базы, переранжировать кандидатов и готовить подсказку по трём выбранным материалам. Оператор решает, использовать ли её; распознанные сообщения о недостатке информации ему не показывают.
Среднее время от обращения до получения ответа сократилось на 15%. По оценкам клиентов качество ответов осталось прежним, общая удовлетворённость выросла без указанного численного значения. Это результаты работы помощника при сохранении оператора, а не полностью автоматической поддержки.
Объёмная и обновляемая документация трёх платформ и десятков сервисов требует поиска подходящих сведений. Постоянно дообучать генератор на изменениях источника команда считает дорогим и длительным решением.
Объединить полнотекстовый и семантический поиск, обучить общую модель переранжирования и передавать генератору три лучших фрагмента. Актуальность документов поддерживать отдельным ежедневным процессом загрузки и индексирования.
На показанном офлайн-наборе nDCG@3 составил 0.535876 у BM25 и 0.668312 у полного варианта с дообученным ранкером. Система показана работающей в production; измерений ускорения пользовательского поиска, роста лояльности и снижения нагрузки на поддержку в докладе нет.
Улучшить содержательность поисковых ответов, сохранив генерацию за единицы секунд и приемлемую стоимость при массовой нагрузке.
Сочетать энкодер–декодер с разреженными экспертными слоями, обучать модель по оценкам ответов и поведению пользователей, а входной контекст сокращать с учётом качества конечной генерации.
В итоговом A/B-тесте получено +0,34% по SPU. В отдельном парном сравнении с AI Overview (Google) результат составил 56,7% SbS.
Разрозненные MCP-интеграции команд дублировали инфраструктуру, усложняли обнаружение инструментов и не давали единых правил эксплуатации, безопасности и доступа к API.
MCP Registry автоматически собирает определения инструментов, но включает их только после решения владельцев; Proxy Gateway единообразно проверяет права, преобразует запросы и вызывает существующие или нативные MCP-сервисы. Omni MCP, Response Projection и Code Mode уменьшают объём схем и ответов, попадающих в контекст агента.
В статье от 1 октября 2026 года Uber сообщает о размещении более 800 MCP-серверов и более 5000 инструментов. Это самоотчёт о масштабе платформы, без опубликованных сравнительных замеров производительности агентов или бизнес-эффекта.
Корпоративные знания разбросаны по документам и командам; текстовый ответ без актуальных источников, прав и доступных действий не завершает повторяемый рабочий процесс. У команды возникла задача объединить поиск, специализированных помощников и проверяемую оркестрацию.
Растить агентов из полезных проектов с владельцами, эталонами и инструментами. PortalManager собирает дерево агентов и контекст каждого обращения, ADK Runner исполняет ReAct, RAG подбирает документы, MCP Hub отделяет вызовы внешних сервисов, а бенчмарки контролируют качество на четырёх уровнях.
Автор описывает работающую платформу и первого доменного консультанта корпоративного центра с ночным обновлением баз из Confluence, ответами со ссылками и маршрутизацией запросов. Измеренного бизнес-эффекта или таблиц результатов бенчмарков нет; 30 минут против пары минут — иллюстрация, 85% на схеме — целевой ориентир. Длительные процессы и LLM-вики остаются планами.
Внешние документы не гарантируют хороший ответ: компоненты RAG зависят друг от друга, а требования к источникам, безопасности и скорости различаются между продуктами.
Оценивать RAG на нескольких уровнях, проверять устойчивость к контексту, отбирать запросы для поиска и обучать поведение модели под правила конкретного продукта.
Алиса: −23% контекста при обновлении модели. Нейросаппорт: 19% роста качества относительно «полезных» моделей; точная метрика и протокол сравнения не раскрыты.
Сложные инциденты нужно решать в рамках SLA, но знания разбросаны по неполным и неоднородным Confluence/Jira, а симптомы формулируются по-разному.
Синхронизировать Confluence и Jira, искать релевантные фрагменты по смыслу и передавать их LLM вместе с вопросом, сохраняя ссылки на первоисточники.
Помощник несколько месяцев использовался командой и получил хорошие отзывы, но статья не даёт измеренного uplift по SLA/MTTR; человек и качество документации остаются критичными.
Сценарный чат-бот покрывал заранее описанные пути, а поиск по статьям жил отдельно; для новых задач требовались оператор, корпоративные знания и API.
Связать RAG по интентам и знаниям с оркестрацией специализированных агентов, общими LLM Gateway, MCP, памятью, guardrails и собственным Agent Runtime.
Команда описывает страховой MVP и платформу; для документов — до 30 тыс. файлов/день, 3–30 с и GPU до 95%. Task-success, ROI и бизнес-uplift не измерены.
В Confluence трудно находить объяснения статусов и связей компонентов. Простое подключение wiki к языковой модели оставляло слишком много неприемлемых ответов.
Сохранить смысл и контекст документов, объединить два поиска FRIDA и sparse-поиск через RRF, затем отфильтровать 50 кандидатов языковой моделью и составить ответ со ссылками.
На 400 QA-парах доля ответов без оценки 0 выросла с 75% до 90%, включая неясные ответы. Пилот — три отдела; отдельный вклад изменений не выделен, экономию денег не измерили.
Свежие события меняют смысл запроса, но таких запросов мало, пользовательские сигналы запаздывают, а ручная разметка с чтением новостей обходится дорого.
Поиск с Алисой собирает новости для запроса и даты; отдельная языковая модель оценивает свежесть. Разметку проверяют на эталоне, сравнением отборов и обучением ранжирования.
Precision 0,91, Recall 0,90; более шести месяцев работы. Экономия — 25% крауд-бюджета сервиса и около 95% расходов на крауд в этой задаче; 5% оставлено на мониторинг.
Поиск сотрудников состоит из множества связанных и повторяющихся шагов. Чат с разовыми вызовами инструментов плохо подходит для работы, которая длится в фоне, меняется после новых событий и требует объяснимых оценок и согласования решений.
Отдельный экземпляр агента на рекрутера получает сообщения, а центральный supervisor составляет и обновляет план. Исполнитель обращается к инструментам LinkedIn и специализированным подагентам; интерфейс получает события о ходе работы, рекрутер утверждает важные изменения, а обучение предпочтений и память поддерживают последующие задачи.
LinkedIn описала архитектуру Hiring Assistant, доведённого от ранней работы с клиентами до глобальной доступности. Заявлены фоновый поиск и оценка, непрерывное обновление списков и оценка за секунды специализированными LLM, но без опубликованных в этой статье сравнительных метрик качества, бизнес-эффекта или нагрузки.
Векторный поиск быстро выбирал возможные ответы, но хуже различал тонкие смысловые отличия. Качественное переранжирование через Cohere Rerank-v3.5 дорого обходилось, а проверенные альтернативы не удовлетворяли одновременно требованиям качества и задержки.
Обучить специализированную для англоязычной поддержки модель Fin-cx-reranker: ModernBERT совместно читает поисковый запрос и каждый найденный фрагмент, выдаёт оценку релевантности и учится упорядочивать кандидатов по оценкам LLM-учителя с помощью RankNet.
По данным Intercom, собственная модель превзошла Cohere Rerank-v3.5 на внутреннем бенчмарке и улучшила Resolution Rate в A/B-тесте на 1,5 млн разговоров (p < 0.01) без изменения заявленной медианной задержки около 150 мс. Расходы именно на переранжирование сократились на 80%; величина прироста Resolution Rate не опубликована.