KARL от Databricks сокращает расходы на запросы на 33%
Большинство корпоративных конвейеров RAG (генерации, дополненной поиском) оптимизированы под один сценарий поиска. На остальных они незаметно дают сбой. Модель, обученная синтезировать отчеты на основе множества документов, плохо справляется с поиском сущностей по жестким критериям. Модель, настроенная на простые задачи поиска, «сыпавется» при многошаговом логическом выводе по внутренним заметкам. Большинство команд узнают об этом только тогда, когда что-то ломается.
Компания Databricks решила исправить это с помощью KARL (Knowledge Agents via Reinforcement Learning — агенты знаний с использованием обучения с подкреплением). Компания обучила агента одновременно для шести различных сценариев корпоративного поиска с помощью нового алгоритма обучения с подкреплением. По утверждению компании, в результате получилась модель, которая не уступает Claude Opus 4.6 в специально созданном бенчмарке, обеспечивая при этом на 33% меньшую стоимость одного запроса и на 47% меньшую задержку. Модель была обучена исключительно на синтетических данных, которые агент сгенерировал самостоятельно, без какого-либо участия человека в разметке. Это сравнение основано на бенчмарке KARLBench, созданном Databricks для оценки сценариев корпоративного поиска.
«Многие крупные успехи в области обучения с подкреплением, которые мы наблюдали в ИИ-сообществе за последний год, были связаны с проверяемыми задачами, где есть правильный и неправильный ответ», — рассказал Джонатан Франкл (Jonathan Frankle), главный научный сотрудник по искусственному интеллекту в Databricks, в эксклюзивном интервью VentureBeat. — Задачи, над которыми мы работаем для KARL и которые являются обычным делом для большинства предприятий, в таком же ключе строго не проверяются».
К таким задачам относятся синтез аналитики по заметкам с встреч продакт-менеджеров, восстановление исходов конкурентных сделок по фрагментированным записям клиентов, ответы на вопросы об истории учетных записей, когда ни один отдельный документ не содержит полного ответа, а также генерация аналитических справок (battle cards) на основе неструктурированных внутренних данных. Ни для одной из этих задач не существует единственно правильного ответа, который система могла бы проверить автоматически.
«Заниматься обучением с подкреплением в мире, где у вас нет строгого «правильно» или «неправильно», и выяснять, как направлять этот процесс и гарантировать отсутствие взлома функции вознаграждения — это действительно непростая задача, — сказал Франкл. — Лишь малая доля того, что компании делают изо дня в день при решении задач с использованием знаний, поддается проверке».
Ловушка генерализации в корпоративном RAG
Стандартный RAG дает сбой при работе с неоднозначными многошаговыми запросами, опирающимися на фрагментированные внутренние данные, которые изначально не были предназначены для поиска.
Для оценки KARL компания Databricks создала бенчмарк KARLBench для измерения производительности в шести сценариях корпоративного поиска: поиск сущностей по критериям, синтез отчетов по нескольким документам, обход длинных документов с табличными и числовыми рассуждениями, исчерпывающий поиск сущностей, процедурные рассуждения по технической документации и агрегирование фактов по внутренним заметкам компании. Последняя задача называется PMBench и создана на основе собственных заметок продакт-менеджеров Databricks — фрагментированных, неоднозначных и неструктурированных таким образом, с которым передовые модели справляются плохо.
Обучение на любой отдельно взятой задаче и тестирование на остальных дает плохие результаты. Документ по KARL показывает, что многозадачное обучение с подкреплением (RL) обеспечивает такую генерализацию, которой однозадачное обучение не дает. Команда обучила KARL на синтетических данных для двух из шести задач и обнаружила, что модель хорошо справилась со всеми четырьмя, с которыми раньше никогда не сталкивалась.
Например, чтобы составить конкурентную аналитическую справку (battle card) для клиента из финансового сектора, агент должен идентифицировать соответствующие учетные записи, отфильтровать их по давности, реконструировать прошлые конкурентные сделки и сделать выводы об их исходах — и ничто из этого не размечено в данных.
Франкл называет то, что делает KARL, «обоснованными рассуждениями» (grounded reasoning): выполнение сложной цепочки рассуждений при одновременной привязке каждого шага к извлеченным фактам. «Вы можете думать об этом как о RAG, — сказал он, — но как о RAG с множеством плюсов вплоть до 200 вызовов векторной базы данных».
Механизм RL: почему важен OAPL
Обучение KARL работает на базе алгоритма OAPL (Optimal Advantage-based Policy Optimization with Lagged Inference policy — оптимальная оптимизация стратегии на основе преимуществ с запаздывающей политикой вывода). Это новый подход, разработанный совместно исследователями из Корнелла, Databricks и Гарварда и опубликованный в отдельной научной работе за неделю до анонса KARL.
В стандартном обучении с подкреплением для языковых моделей используются алгоритмы on-policy, такие как GRPO (Group Relative Policy Optimization), которые предполагают, что модель, генерирующая обучающие данные, и обновляемая модель синхронизированы друг с другом. При распределенном обучении этого не происходит никогда. Предыдущие подходы исправляли это с помощью вероятностного семплирования (importance sampling), что привносило дисперсию и нестабильность. OAPL же принимает внеполитическую (off-policy) природу распределенного обучения, используя регрессионную цель, которая остается стабильной при отставании стратегии более чем на 400 шагов градиента — это в 100 раз превосходит показатели предыдущих подходов. В экспериментах по генерации кода этот алгоритм не уступил модели, обученной с помощью GRPO, при этом используя примерно в три раза меньше обучающих выборок.
Эффективность OAPL в отношении использования выборок позволяет удерживать затраты на обучение в разумных пределах. Повторное использование ранее собранных траекторий вместо требования свежих on-policy данных для каждого обновления означало, что весь процесс обучения KARL уложился в несколько тысяч часов работы GPU. Именно в этом заключается разница между академическим исследовательским проектом и тем, что корпоративная команда может реально попытаться внедрить.
Агенты, память и стек контекста
В последние месяцы в индустрии велось много дискуссий о том, как RAG может быть заменен контекстной памятью, которую иногда также называют агентичной памятью.
По мнению Франкла, здесь нет дихотомии «или-или», скорее он рассматривает это как многослойный стек. В основе лежит векторная база данных с миллионами записей, которая слишком велика для контекста. Наверху находится окно контекста языковой модели. Между ними появляются уровни сжатия и кэширования, которые определяют, какую часть уже усвоенных агентом знаний он может перенести на следующие этапы.
Для KARL это не абстракция. Некоторые задачи в KARLBench требовали 200 последовательных запросов к векторной базе данных, в ходе которых агент уточнял поиск, проверял детали и сопоставлял документы, прежде чем выдать ответ, многократно исчерпывая окно контекста. Вместо того чтобы обучать отдельную модель суммирования, команда позволила KARL изучить сжатие данных «от конца до конца» (end-to-end) с помощью RL: когда контекст становится слишком большим, агент сжимает его и продолжает работу, причем единственным сигналом для обучения является вознаграждение в конце выполнения задачи. Отключение этого обученного сжатия привело к падению точности на одном из бенчмарков с 57% до 39%.
«Мы просто позволили модели самой разобраться, как сжимать собственный контекст, — сказал Франкл. — И это сработало феноменально хорошо».
В чем KARL уступает
Франкл откровенно рассказал о режимах сбоев. KARL сложнее всего даются вопросы со значительной степенью неопределенности, когда существует несколько верных ответов, а модель не может определить, является ли вопрос действительно открытым или просто сложным для ответа. Это суждение пока остается нерешенной проблемой.
Модель также демонстрирует то, что Франкл охарактеризовал как преждевременный отказ от поиска по некоторым запросам — остановку работы до выдачи окончательного ответа. Он возразил против трактовки этого как сбоя, отметив, что самые дорогие запросы — это обычно те, на которые модель все равно дает неверный ответ. Остановка часто является правильным решением.
Кроме того, KARL обучался и оценивался исключительно на векторном поиске. Задачи, требующие SQL-запросов, поиска по файлам или расчетов на Python, пока не входят в его область видимости. Франкл сообщил, что эти возможности следующие на очереди в дорожной карте, но в текущей системе они пока отсутствуют.
Что это значит для корпоративных команд по работе с данными
KARL ставит перед командами, оценивающими свою поисковую инфраструктуру, три вопроса, к которым стоит вернуться.
Первый — это архитектура конвейера. Если ваш агент RAG оптимизирован под один сценарий поиска, результаты KARL показывают, что в других сценариях он терпит неудачу. Многозадачное обучение на различных поисковых паттернах создает модели, способные к генерализации. Узкоспециализированные конвейеры на это не способны.
Второй — почему RL здесь имеет такое значение (и дело не только в деталях обучения). Databricks протестировала альтернативный вариант: дистилляцию из экспертных моделей с помощью контролируемой тонкой настройки (supervised fine-tuning). Такой подход улучшил производительность в рамках исходного распределения (in-distribution), но дал ничтожно малый прирост на задачах, с которыми модель никогда не сталкивалась. RL же сформировал общие поисковые паттерны, которые успешно переносились на новые задачи. Для корпоративных команд, сталкивающихся с разнородными данными и непредсказуемыми типами запросов, это различие имеет решающее значение.
Третий вопрос касается того, что на практике означает эффективность RL. Модель, обученная искать лучше, выполняет задачи за меньшее количество шагов, раньше прекращает работу над запросами, на которые не может ответить, диверсифицирует поиск вместо повторения неудачных запросов и сжимает собственный контекст вместо исчерпания отведенного пространства. Аргументы в пользу создания специализированных поисковых агентов, а не перенаправления всего через универсальные сторонние API, связаны вовсе не с экономией средств. Речь идет о создании модели, которая действительно умеет выполнять свою работу.
