Для многих предприятий обещания получить ценные инсайты с помощью ИИ наталкиваются на структурную преграду. Хотя Retrieval-Augmented Generation (RAG) стал стандартом для подключения больших языковых моделей (LLM) к частным данным, он всё чаще оказывается недостаточно эффективным для решения сложных, реальных бизнес-задач.
Новое исследование Databricks показывает, что проблема заключается не в интеллекте самих моделей, а в архитектуре, используемой для запросов к ним. Исследование подчеркивает критический сдвиг: переход от одноэтапного поиска к многошаговым агентским рабочим процессам (agentic workflows).
Проблема «гибридных данных»
Большинство задач бизнес-аналитики требуют объединения двух разных миров:
1. Структурированные данные: точные числа, показатели продаж и реляционные таблицы (SQL).
2. Неструктурированные данные: отзывы клиентов, научные статьи и справочные документы.
Стандартная система RAG рассчитана на второй тип. Она отлично справляется с поиском текста, который «похож» на запрос, но ей трудно выполнять точные математические фильтрации или объединять данные из разных форматов.
«RAG работает, но он не масштабируется», — говорит Майкл Бендерски, директор по исследованиям в Databricks. «Если вы хотите понять, почему продажи падают, вы должны помочь агенту увидеть таблицы и проанализировать данные о продажах. Ваш RAG-конвейер окажется некомпетентным в такой задаче».
Архитектура против интеллекта: разрыв в 21%
Чтобы доказать, что проблема заключается в способе доступа к данным, а не в «умности» модели, Databricks провела серию тестов, используя бенчмарк STaRK (охватывающий товары Amazon, Microsoft Academic Graph и биомедицинские данные).
Они сравнили высокопроизводительную, современную одноэтапную систему RAG с многошаговым агентским подходом. Даже при использовании значительно более мощной базовой модели, одноэтапная система RAG проиграла:
* На 21% в академической области.
* На 38% в биомедицинской области.
Этот разрыв в производительности демонстрирует, что даже самая «интеллектуальная» модель не может компенсировать архитектуру поиска, которая фундаментально не способна преодолеть пропасть между электронной таблицей и текстовым документом.
Как работает «Агент-супервизор» (Supervisor Agent)
Решение от Databricks — Supervisor Agent — отказывается от идеи «гибридного поиска» (попыток объединить эмбеддинги и таблицы) и вместо этого рассматривает проблему как оркестрацию инструментов. Агент функционирует за счет трех ключевых возможностей:
- Параллельная декомпозиция инструментов: Вместо одного масштабного поиска агент одновременно запускает SQL-запросы для получения чисел и векторный поиск для текста. Затем он анализирует комбинированные результаты, чтобы сформировать связный ответ.
- Самокоррекция: Если первоначальный поиск не дает результатов (например, при поиске конкретного автора с точным количеством публикаций), агент не сдается. Он переформулирует запрос, выполняет операцию
JOINв SQL и проверяет результат с помощью повторного поиска. - Декларативная конфигурация: В отличие от традиционных конвейеров, требующих от инженеров «сглаживания» или нормализации данных в текстовые фрагменты, этот агент использует описания на обычном языке. Чтобы добавить новый источник данных, инженеру достаточно просто описать, что это за данные; агент сам научится их использовать.
Переход от инженерии к конфигурации
Последствия для инженерии данных весьма значительны. В традиционной архитектуре RAG каждый новый источник данных требует огромного количества «сантехнических работ» с данными: преобразования JSON, нормализации таблиц и управления эмбеддингами. Это создает «узкое место», которое растет вместе с расширением предприятия.
Агентский подход меняет эту модель: «Просто подведите агента к данным».
Ключевые выводы для внедрения:
- Масштабируемость: Агентская модель более устойчива для растущих наборов данных, так как добавление источника — это задача конфигурации, а не написания кода.
- Пределы сложности: Несмотря на свою мощь, этот подход лучше всего работает с 5–10 источниками данных. Подключение слишком большого количества противоречивых источников одновременно может снизить скорость и надежность.
- Целостность данных: Хотя агент может перемещаться между различными форматами, он не может исправить принцип «мусор на входе — мусор на выходе». Исходные данные должны быть фактически точными, чтобы агент был эффективным.
Заключение
Переход от RAG к многошаговым агентам представляет собой фундаментальную эволюцию корпоративного ИИ: переход от систем, которые просто находят информацию, к системам, которые могут рассуждать в рамках разнообразных экосистем данных. Рассматривая источники данных как инструменты, а не просто как наборы текста, компании могут, наконец, начать отвечать на сложные, кросс-функциональные вопросы, которые определяют бизнес-решения.
