ИИ-агенты: как мы сделали DeepResearch по корпоративным данным и кодовой базе
- Задача: внешние DeepResearch-режимы (ChatGPT, Perplexity, Gemini) не имеют доступа к корпоративным данным; поэтому сделана внутренняя версия Deep Agent Yandex Team Ru для сотрудников.
- Эффект через 3 месяца: типичный ответ на внутренний вопрос ускорился с 10–20 минут до 30–60 секунд; оценка экономии — около 240 рабочих часов в день.
- Техническая схема: бэкенд DeepAgent обращается к локально поднятому поиску и инструменту поиска по внутренней Вики; агент сам решает, когда искать и когда отвечать, через системный промпт.
- Оценка качества: введены «корзинки» вопросов (простые и сложные, где ручной поиск занимает 20–60 минут) и автоматическая проверка LLM-as-a-judge с регулярной ручной перепроверкой.
- Рост качества: используются few-shot примеры в промпте и полное логирование запросов/ошибок; позже добавлено дообучение на отобранных траекториях действий разных LLM.
- Дальше: автор описывает планы расширить агент на инфраструктурные источники (Kubernetes, дашборды, графики, логи, Nirvana-графы) и длинные сценарии; цель — «единое окно» для сотрудников.
Почему это важно: кейс показывает, что ценность DeepResearch часто упирается в доступ к корпоративным данным и качество поиска по внутренним источникам, а не только в «умение говорить». Отдельно подчёркнуты практики эвалов и логирования как способ держать качество под контролем при частых изменениях системы.
На что обратить внимание: в тексте разделяются RAG, фиксированные AI workflow и агентный подход — различие связано с тем, кто выбирает шаги и инструменты при ответе. В описании качества много опоры на «корзинки» и на проверяемого LLM-судью, что задаёт рамки для сравнения версий. Также отдельно отмечена разница между Tool Calling и Code Execution как влияющая на скорость, ресурсы и устойчивость ответа.
Коротко
- Если внешние DeepResearch не видят внутренние знания, история про DeepAgent показывает типичную причину появления корпоративного поиска.
- Акцент на регулярной оценке: контрольные наборы вопросов и проверяемый LLM-судья помогают фиксировать прогресс и понимать, где качество падает.
- Автор разделяет RAG, AI workflow и ИИ-агента: ключевое различие в том, кто выбирает шаги и инструменты при дефиците информации.
- Сравнение Tool Calling и Code Execution полезно как сигнал: исполняемый кодовый блок может сокращать число итераций и время отклика агента.
- Мультиагентность описана как опция для реальных границ команд: иначе один агент и общий протокол agent-to-agent могут быть проще в поддержке.
FAQ
Зачем это важно: что меняется для компании, когда DeepResearch получает доступ к Вики, чатам и кодовой базе, и почему в статье подчёркнута экономия времени?
Внешние режимы DeepResearch не имеют доступа к внутренним данным, поэтому автор описывает корпоративную версию. Он приводит пример ускорения ответа на внутренние вопросы с 10–20 минут до 30–60 секунд и оценку экономии около 240 часов в день.
Чем DeepResearch отличается от обычного RAG по описанию автора, и какие дополнительные шаги он делает, когда ответа не хватает после первого запроса?
По тексту DeepResearch не ограничивается одним запросом: он анализирует множество страниц, делает дополнительные поисковые запросы и выполняет промежуточные проверки и уточнения. Это нужно для вопросов, на которые нельзя ответить одним поиском.
Как в статье предлагается измерять качество DeepAgent: из чего состоят «корзинки» вопросов и как используется подход LLM-as-a-judge?
Команда собрала тестовые наборы вопросов: простые, где ответ находится на первой странице Вики, и сложные, где ручной поиск занимает 20–60 минут. Результаты проверялись через LLM-as-a-judge, а «судью» регулярно перепроверяли вручную.
Почему автор сравнивает Tool Calling и Code Execution, и чем, по его наблюдению, вариант с исполняемым Python-блоком оказался эффективнее?
Tool Calling описан как более медленный и ресурсоёмкий из-за нескольких итераций явных вызовов тулов. Code Execution, по наблюдению автора, делает те же действия за один проход, экономит токены и даёт более устойчивое качество.
Читайте также
Память на миллион токенов, а толку ноль: как ИИ-агента спасали от «тупости»- Конец бесплатного кремния: как Google AI Studio превратилась из рая для инженеров в симулятор смены аккаунтов
- От RAG-прототипа к агенту в продакшн: путь по метрикам, а не по моде
Российские поисковики не пойдут по пути Google: ссылочная выдача сохранится — её не заменят ответы ИИ
Установки DuckDuckGo выросли на 30% на фоне отказа пользователей от навязанного AI-поиска Google
- Критерий необходимости корпоративного DeepResearch: Практический триггер для запуска внутреннего DeepResearch формулируется так: внешние режимы (например, в ChatGPT) не могут отвечать на вопросы о внутренних делах компании, потому что не имеют доступа к корпоративным источникам. В статье этот разрыв связывается с тем, что знания распределены по Вики, документации, почте и чатам, которые недоступны внешним моделям.
[Регламент: когда строить внутренний AI-поиск]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
В Яндексе описали, как собрали внутренний DeepResearch (DeepAgent) для ответа на сложные вопросы по корпоративным данным и кодовой базе. Через три месяца автор отмечает сокращение времени поиска и заметную экономию рабочих часов.