Databricks представила KARL (Knowledge Agents via Reinforcement Learning) — нового AI-агента, призванного преодолеть ограничения традиционных конвейеров генерации с помощью поиска (RAG). Большинство корпоративных систем RAG превосходны в одном типе поиска, молчаливо терпя неудачу при столкновении с другими. Модель, оптимизированная для синтеза отчётов, столкнётся с трудностями при точном извлечении сущностей, в то время как модель, ориентированная на поиск, провалится при многоэтапном рассуждении. KARL решает эту проблему, обучая модель одновременно обрабатывать шесть различных корпоративных поисковых сценариев.
Проблема с существующими системами RAG
Существующие системы RAG хрупки. Обычно они подвергаются тонкой настройке для конкретных поисковых задач, делая их уязвимыми перед лицом реальной сложности. Агент, обученный для простого вопросно-ответного поиска, может дать сбой при попытке восстановления фрагментированных внутренних записей или синтеза данных из неструктурированных заметок с совещаний. Эта негибкость вынуждает команды создавать отдельные конвейеры для каждого варианта использования, что приводит к избыточным затратам на обслуживание и изолированному доступу к знаниям.
Как работает KARL: многозадаточное обучение с подкреплением
Databricks обучила KARL с использованием нового алгоритма обучения с подкреплением (RL), достигнув производительности, сравнимой с Claude Opus 4.6, при этом стоимость запроса на 33% ниже, а задержка — на 47%. Важно отметить, что модель была обучена исключительно на синтетических данных, сгенерированных ей самой, что устраняет необходимость в дорогой ручной разметке. Это стало возможным благодаря OAPL — политике Optimal Advantage-based Policy Optimization with Lagged Inference, которую Databricks разработала совместно с исследователями из Корнеллского и Гарвардского университетов.
Ключевым новшеством OAPL является её стабильность в распределённых обучающих средах. В отличие от традиционных подходов RL для LLM, она эффективно справляется с задержками политики, что позволяет проводить обучение с высокой эффективностью и снижать затраты на GPU. Это делает модель жизнеспособной для реального корпоративного развёртывания.
Шесть корпоративных поисковых сценариев, обрабатываемых KARL
Для оценки KARL Databricks создала KARLBench — эталон, оценивающий производительность по шести критически важным корпоративным поисковым сценариям:
- Поиск сущностей с ограничениями: извлечение конкретных сущностей при строгих условиях.
- Синтез отчётов из нескольких документов: объединение информации из нескольких источников в связный отчёт.
- Обход длинных документов с табличным рассуждением: извлечение информации из больших документов с числовыми данными.
- Исчерпывающее извлечение сущностей: идентификация всех соответствующих сущностей в заданном наборе данных.
- Процедурное рассуждение по технической документации: следование пошаговым инструкциям из сложных руководств.
- Агрегирование фактов из внутренних заметок компании: объединение фрагментированных данных для ответа на сложные вопросы.
KARL продемонстрировала высокую обобщающую способность, успешно справляясь с задачами, на которых она никогда явно не была обучена, в отличие от стандартных систем RAG.
Слой сжатия: управление контекстом
Одной из основных проблем корпоративного поиска является управление окном контекста больших языковых моделей (LLM). Традиционные системы RAG либо полагаются на массивные векторные базы данных, либо заставляют LLM обрабатывать слишком много информации одновременно. KARL решает эту проблему, обучая модель сжимать собственный контекст сквозным способом с помощью RL. Когда контекст превышает лимиты LLM, агент сжимает его, сохраняя точность и оставаясь в пределах границ. Без этого сжатия производительность модели значительно снижается.
Ограничения и будущая дорожная карта
KARL испытывает трудности с запросами, содержащими внутреннюю неоднозначность, когда существует несколько допустимых ответов. Модель иногда преждевременно отказывается от сложных запросов, что Databricks считает часто правильным поведением с точки зрения экономической эффективности. В настоящее время KARL поддерживает только векторный поиск; интеграция с SQL-базами данных, файловыми системами и вычислениями на Python запланирована на будущее.
Последствия для команд корпоративных данных
KARL выделяет три важных момента для команд, создающих свою инфраструктуру поиска:
- Архитектура конвейера имеет значение: узко оптимизированные конвейеры RAG не будут работать с разнообразными типами запросов.
- Обучение с подкреплением является ключевым: дистилляция от экспертных моделей не может сравниться с обобщающей способностью агентов, обученных с помощью RL.
- Эффективность — это больше, чем стоимость: специализированные поисковые агенты завершают задачи быстрее, сокращают количество бесполезных запросов и эффективно сжимают контекст.
Создание модели, которая знает, как искать, более ценно, чем просто перенаправление всего через универсальные API.
