Проблема: почему корпоративные ИИ-ассистенты все еще тупят
Представьте: 2025 год, ваша компания купила лицензию на GPT-5 Enterprise, развернула векторную базу, настроила RAG-пайплайн. Инженеры месяц пилили интеграцию. Итог? Система отвечает на вопросы о внутренних процессах с точностью чуть лучше случайного поиска по Confluence.
Знакомо? Я тоже через это проходил. В Яндексе мы столкнулись с той же проблемой в 2024-м. Наш первый корпоративный ассистент на базе RAG (Retrieval-Augmented Generation) работал по принципу "спросил-получил ответ". Результаты были... предсказуемо плохими.
Главная ошибка: мы думали, что достаточно закинуть документы в векторное хранилище и подключить LLM. Реальность оказалась сложнее. Внутренние данные компании — это не структурированные статьи из Википедии, а хаос из Slack-переписок, устаревших инструкций, противоречивых требований и полузабытых решений.
Типичный сценарий: разработчик спрашивает "Как настроить деплой для микросервиса Х?". RAG находил 5 разных инструкций от разных команд, каждая со своими нюансами. LLM пыталась их усреднить. Получалась каша из общих фраз без конкретики.
Решение: от статичного RAG к динамичному агенту
Вот где мы поняли: нужен не просто поисковик с языковой моделью, а полноценный исследовательский агент. Тот, который умеет не только искать, но и думать, планировать, проверять гипотезы.
Так родился DeepResearch — наш внутренний ИИ-агент для работы с корпоративными знаниями. Не публичный продукт, а внутренний инструмент, который сейчас используют тысячи яндексовцев ежедневно.
Архитектура DeepResearch: как мы разбили монолит
Первая версия была монолитом: один большой сервис, который делал все — от планирования до ответа. Масштабировалось это ужасно.
Текущая архитектура (на начало 2026 года) выглядит так:
| Компонент | Роль | Технологии (2026) |
|---|---|---|
| Оркестратор | Принимает запрос, управляет потоком работы агентов | YandexGPT 4.0 + кастомная логика на Go |
| Планировщик | Разбивает сложные вопросы на подзадачи | Mixtral 8x22B (fine-tuned) |
| Специализированные агенты | Выполняют конкретные задачи (поиск, анализ, проверка) | Разные модели под задачи |
| Векторный поиск | Быстрый поиск по embeddings | Qdrant + собственные доработки |
| Кэш-слой | Хранит результаты частых запросов | Redis с semantic caching |
1 Планировщик: как заставить ИИ думать, а не гадать
Самый критичный компонент. Плохой планировщик = бесполезный агент.
Ранние версии использовали простой prompt engineering: "Разбей вопрос Х на подвопросы". Результаты были случайными. Планировщик либо слишком детализировал (20+ подзадач для простого вопроса), либо слишком упрощал.
Решение: fine-tuned модель специально для декомпозиции корпоративных задач. Мы собрали датасет из 50 тысяч реальных вопросов сотрудников Яндекса и их оптимальных декомпозиций, размеченных экспертами.
Теперь планировщик учитывает:
- Контекст команды (разработка, маркетинг, аналитика)
- Сложность вопроса (базовый vs. экспертный)
- Временные рамки (срочно vs. можно подождать)
- Источники данных (документация, код, переписки)
2 Специализированные агенты: почему одна модель на все — плохая идея
Изначально мы использовали одну большую модель для всего. YandexGPT 4.0 обрабатывала и планирование, и поиск, и синтез ответов. Дорого и неэффективно.
Сейчас у нас 5 типов специализированных агентов:
- Поисковый агент — ищет информацию в разных источниках. Использует оптимизированную для поиска версию модели.
- Аналитический агент — сравнивает найденные данные, ищет противоречия.
- Проверочный агент — валидирует информацию, сверяет с авторитетными источниками.
- Синтезирующий агент — объединяет результаты в связный ответ.
- Формулировочный агент — адаптирует ответ под конкретного пользователя (технарь vs. менеджер).
Каждый агент использует модель, оптимальную для его задачи. Для поиска — модель с улучшенным пониманием контекста. Для анализа — модель с сильными логическими способностями. Это дешевле и дает качество на 30-40% выше.
Важный нюанс: агенты общаются между собой через структурированные сообщения (JSON schema). Это позволяет избежать "испорченного телефона", когда информация искажается при передаче между этапами.
3 Векторный поиск: почему Qdrant — не панацея
Мы начали с Qdrant — популярное решение, хорошая документация. Но для корпоративных данных оказалось недостаточно.
Проблемы, с которыми столкнулись:
- Медленный поиск при больших объемах (миллионы документов)
- Плохая работа с составными запросами
- Нет встроенной поддержки гибридного поиска (векторы + ключевые слова)
Решение: доработанный Qdrant с кастомными индексами и кэшированием промежуточных результатов. Плюс добавили слой BM25 для keyword поиска — иногда старый добрый TF-IDF работает лучше embeddings.
Если хотите глубже погрузиться в тему поиска для ИИ-агентов, рекомендую нашу статью про оптимизацию поиска для агентов, где мы разбираем, как снизили латентность с 3500 мс до 700 мс.
Пошаговый план: как построить свой DeepResearch
Хотите повторить наш путь? Вот практические шаги, основанные на нашем опыте.
Шаг 1: Начните с малого, но думайте о масштабе
Не пытайтесь сразу охватить все данные компании. Выберите одну конкретную область:
- Документация одной команды
- База знаний отдела поддержки
- Технические спецификации проектов
Соберите 100-200 вопросов, которые реально задают сотрудники в этой области. Это будет ваш тестовый датасет.
Шаг 2: Постройте базовый RAG (но правильно)
Возьмите открытые инструменты:
- LangChain или LlamaIndex для оркестрации
- OpenAI GPT-4o или Anthropic Claude 3.5 Sonnet как основную модель
- Chroma или Qdrant для векторного хранилища
Но сразу проектируйте с учетом будущего расширения. Каждый компонент должен быть replaceable.
Шаг 3: Добавьте планирование
Вместо простого prompt engineering используйте специализированные модели для планирования. На 2026 год лучшие варианты:
- Claude 3.5 Sonnet для сложной декомпозиции
- GPT-4o для более простых задач
- Open-source: Mixtral 8x22B или DeepSeek-V2 (если нужна экономия)
Настройте планировщик на ваши конкретные данные. Fine-tuning обязателен для корпоративного использования.
Шаг 4: Внедрите специализированных агентов
Начните с двух агентов:
- Поисковый (самый важный)
- Синтезирующий
По мере роста добавляйте аналитического и проверочного агентов.
Шаг 5: Добавьте семантический кэш
30-40% вопросов повторяются. Кэшируйте не по точному тексту запроса, а по семантическому смыслу.
Используйте embeddings для определения схожести вопросов. Redis с поддержкой векторного поиска отлично подходит.
Главные ошибки, которые мы совершили (чтобы вы их не повторили)
Ошибка 1: Доверять LLM без проверки
Ранние версии DeepResearch иногда генерировали убедительно звучащую, но полностью выдуманную информацию о внутренних процессах. Сотрудники верили. Были проблемы.
Решение: Добавили проверочного агента, который сверяет все утверждения с авторитетными источниками. Плюс система confidence scoring — если уверенность ниже порога, агент говорит "Не уверен, проверьте в документации".
Ошибка 2: Игнорировать временные метки
В корпоративных данных актуальность критична. Инструкция по деплою годичной давности может быть полностью нерелевантной.
Решение: Внедрили временные фильтры в поиске и систему приоритизации по дате обновления. Новые документы получают больший вес.
Ошибка 3: Одна модель на все задачи
Как я уже упоминал — это было дорого и неэффективно. Точность специализированных агентов на 40% выше при меньшей стоимости.
Что работает в 2026 году: наши текущие настройки
Архитектура постоянно эволюционирует. Вот что используем сейчас:
| Компонент | Текущее решение | Почему именно оно |
|---|---|---|
| Оркестратор | Кастомный на Go | Производительность и контроль |
| Планировщик | Fine-tuned Mixtral 8x22B | Баланс качества и стоимости |
| Основная LLM | YandexGPT 4.0 | Интеграция с экосистемой |
| Векторная БД | Qdrant с кастомными индексами | Производительность на больших объемах |
| Кэш | Redis с векторным поиском | Семантическое кэширование |
FAQ: частые вопросы от других компаний
Стоит ли использовать open-source модели?
Зависит от бюджета и экспертизы. Если у вас есть сильная ML-команда — да, можно сэкономить. Если нет — начинайте с коммерческих API (OpenAI, Anthropic, Yandex Cloud). Переход на open-source потом будет проще.
Как оценивать качество?
Мы используем три метрики:
- Accuracy — процент правильных ответов на тестовом датасете
- Latency — время от запроса до ответа (цель < 5 секунд)
- User satisfaction — оценка пользователей по 5-балльной шкале
Что делать с устаревшими данными?
Мы внедрили систему version-aware поиска. Каждый документ имеет метку "актуально до". Агент проверяет дату и предупреждает пользователя, если информация может быть устаревшей.
Что дальше? Будущее корпоративных ИИ-агентов
Тренд 2026 года — агенты становятся проактивными. Вместо ответов на вопросы они начинают предлагать информацию до того, как ее спросили.
Наша дорожная карта:
- Контекстная память — агент запоминает предыдущие взаимодействия с пользователем
- Мультимодальность — работа не только с текстом, но и с диаграммами, скриншотами, видео
- Автономные действия — агент может не только искать информацию, но и выполнять простые действия (создать тикет, назначить встречу)
Если интересна тема автономных агентов, смотрите наше подробное руководство по ИИ-агентам для бизнеса с реальными кейсами внедрения.
Важный прогноз: через 2-3 года корпоративные ИИ-агенты станут таким же стандартом, как CRM или ERP системы. Компании, которые не успеют адаптироваться, окажутся в проигрышном положении. Начинать нужно уже сейчас — даже с простых пилотов.
P.S. Если ваша компания только начинает digital-трансформацию, возможно, стоит сначала разобраться с основами — например, пройти курс на контекстную рекламу или SEO-продвижение. Без понимания digital-маркетинга сложно строить сложные ИИ-системы.
