TL;DR
Datalake Agent — система, которая позволяет LLM генерировать SQL-запросы из вопросов на естественном языке, запрашивая информацию о базах данных постепенно, а не всю сразу. Вместо одного промпта со всеми таблицами и колонками, LLM работает в цикле: сначала получает список баз данных, затем запрашивает нужные таблицы, потом колонки — и только после этого генерирует SQL.
Когда даёшь LLM всю информацию о базах данных сразу, промпт раздувается до 30-35 тысяч токенов при 300+ таблицах, хотя для ответа обычно нужны 1-2 таблицы. Стоимость растёт линейно с числом таблиц, а точность падает — модель теряется в избытке информации. При 42 таблицах direct solver (всё в одном промпте) работает хорошо, но при 319 таблицах точность проседает, а затраты вырастают в 8 раз.
Метод разбивает работу на три этапа: (1) получение информации — LLM запрашивает мета-данные по командам GetDBDescription, GetTables, GetColumns; (2) итеративное уточнение — LLM идёт от общего к частному, может вернуться на уровень выше если ошибся; (3) формулировка запроса — когда собрал достаточно информации, генерирует финальный SQL. Результат: сокращение токенов на 87% (с 34,602 до 4,264) при сохранении точности, на сложных задачах даже превосходит direct solver.
Схема метода
ЭТАП 1: Получение общей информации
├ GetDBDescription → список баз данных с описаниями
└ LLM выбирает релевантные БД
ЭТАП 2: Итеративное уточнение
├ GetTables → список таблиц в выбранной БД
├ GetColumns → колонки и типы данных для выбранных таблиц
└ Цикл: LLM может вернуться к GetTables или запросить другую БД
ЭТАП 3: Генерация запроса
└ DBQueryFinalSQL → финальный SQL-запрос
Каждый шаг — отдельный запрос к системе через API с реализацией команд.
Пример применения
⚠️ Метод создан для корпоративных баз данных через API, но принцип иерархического запроса можно адаптировать для работы с большими объёмами информации в чате.
Задача: У тебя 50 CSV-файлов с отзывами покупателей Wildberries (по одному на категорию: электроника, одежда, косметика и т.д.). Нужно найти в какой категории больше всего жалоб на задержки доставки. Вместо загрузки всех 50 файлов сразу — используй иерархический подход.
Промпт (шаг 1 — получение списка):
У меня 50 файлов с отзывами Wildberries по разным категориям товаров.
Вопрос: в какой категории больше всего жалоб на задержки доставки?
Вот список файлов с краткими описаниями:
1. electronics_reviews.csv — 15,000 отзывов на технику
2. clothing_reviews.csv — 22,000 отзывов на одежду
3. cosmetics_reviews.csv — 8,000 отзывов на косметику
[...список всех 50 категорий...]
Какие файлы нужны для ответа? Назови 3-5 категорий, где вероятнее всего будут упоминания доставки.
Промпт (шаг 2 — уточнение):
Хорошо, ты выбрал категории: электроника, бытовая техника, мебель.
[Загружаешь только эти 3 файла]
Проанализируй отзывы и найди упоминания задержек доставки.
Если нужны дополнительные категории — скажи какие.
Результат: LLM сначала выберет релевантные категории из списка (вместо обработки всех 50 сразу), потом проанализирует только их. Если первая выборка не дала ответ — запросит дополнительные категории. Ты сэкономишь токены и получишь более точный результат, чем при загрузке всех файлов одновременно.
Почему это работает
LLM страдает от эффекта "lost in the middle" — при промптах свыше 10-15 тысяч токенов модель хуже обрабатывает информацию из середины контекста. Когда в промпте 300 таблиц, а нужны 2, модель тратит внимание на нерелевантные данные и теряет точность. Исследование показало: точность direct solver падает с 75% (42 таблицы) до 45% (319 таблиц) на сложных задачах.
LLM отлично рассуждает пошагово и выбирает релевантное из небольшого набора. Если дать список из 20 баз данных с описаниями (500 токенов), модель точно определит какие 2-3 нужны. Затем из 50 таблиц выбранной БД (ещё 300 токенов) выберет нужные 3. Суммарно 3-4 тысячи токенов вместо 30 тысяч.
Метод использует иерархическую структуру данных (БД → таблицы → колонки) и позволяет LLM самостоятельно управлять процессом: модель решает когда достаточно информации, когда вернуться на уровень выше, какие детали запросить. Это автономное рассуждение в цикле, а не одноразовая генерация на основе перегруженного промпта.
Рычаги управления: - Уровни иерархии — можно добавить промежуточные (например, группы таблиц по темам) для больших БД - Лимит итераций — исследователи ограничили 10 запросами против зацикливания; уменьши до 5 для экономии, увеличь до 15 для сложных задач - Условие выхода — "когда собрал достаточно информации" можно заменить на конкретный критерий: "когда выбрал хотя бы N таблиц" или "когда уверенность выше X%"
Шаблон промпта
⚠️ Оригинальный метод требует API и реализацию команд — работает через код, не в чате напрямую.
Но принцип иерархического запроса можно применить вручную для работы с большими объёмами информации:
ШАБЛОН для работы с множеством документов/файлов:
ШАГ 1 — Обзор:
У меня {количество} файлов/документов по теме {тема}.
Вопрос: {твой вопрос}
Вот список с краткими описаниями:
{список: название — краткое содержание}
Какие источники наиболее релевантны? Выбери 3-5 и объясни почему.
ШАГ 2 — Детализация:
[Загружаешь/даёшь только выбранные источники]
Проанализируй эти источники и ответь на вопрос: {твой вопрос}
Если информации недостаточно — скажи какие ещё источники из списка нужны.
ШАГ 3 — Уточнение (если нужно):
[Даёшь дополнительные источники]
Дополнительная информация: {новые источники}
Теперь дай финальный ответ.
Как заполнять:
- {количество} — сколько у тебя источников (файлов, документов, таблиц)
- {тема} — общая тема массива данных
- {твой вопрос} — что нужно найти/ответить
- {список} — перечисление с краткими описаниями (название файла — 1-2 предложения о содержании)
🚀 Быстрый старт — вставь в чат:
Вот шаблон для иерархического запроса информации. Адаптируй под мою задачу: [опиши свою задачу — с какими данными работаешь, что нужно найти].
Задай вопросы, чтобы заполнить все поля шаблона.
[вставить шаблон выше]
LLM спросит какие у тебя источники, сколько их, что именно ищешь — чтобы создать список с описаниями для первого шага. Она возьмёт принцип "сначала обзор → выбор релевантного → детальный анализ" и применит к твоим данным.
Ограничения
⚠️ Требует инфраструктуры: Оригинальный Datalake Agent работает через API с реализацией команд (
GetTables,GetColumns, и т.д.). В обычном чате ChatGPT/Claude так не работает — нужна адаптация принципов вручную.
⚠️ Риск зацикливания: LLM иногда застревает в бесконечном цикле запросов одной и той же информации, не продвигаясь к ответу. Исследователи решили это ограничением в 10 итераций с принудительной генерацией ответа, но это может дать неточный результат.
⚠️ Не для простых задач: Если нужна одна известная таблица, direct solver (всё сразу) быстрее и точнее. Выигрыш заметен от 100+ таблиц и на сложных multi-table запросах.
⚠️ Больше запросов к API: Вместо одного запроса — 3-10 запросов в цикле. Экономия на токенах, но увеличение latency (времени ожидания) и числа API-вызовов. Если у тебя лимит на количество запросов в минуту — может быть проблемой.
Как исследовали
Команда из University of Freiburg проверила идею на реальной боли: что если у компании не 5 таблиц, а 300, и LLM не знает где искать ответ? Взяли 5 баз данных из RelBench (реальные данные: Формула-1, клинические испытания, Stack Exchange и др.) и добавили 18 симулированных БД (только структура, без данных) из разных доменов — спорт, политика, бизнес. Получилось три сценария: 42, 159 и 319 таблиц.
Создали 100 вопросов на естественном языке (по 20 на каждую реальную БД), разделённых на простые (одна таблица) и сложные (несколько таблиц, joins). Пример: "У какого пилота Формулы-1 больше всего побед?" или "Сколько комментариев у самого обсуждаемого поста на Stack Exchange?" Важно: модель не знала какая БД содержит ответ — как в реальной жизни.
Сравнили Datalake Agent с direct solver (всё в одном промпте) на GPT-4 Mini при temperature 0.1. Измеряли точность ответов и число токенов. Результаты удивили: на 42 таблицах direct solver лучше (75% vs 70%), но при 319 таблицах картина переворачивается — Datalake Agent держит 65%, direct solver падает до 50% на сложных задачах. Почему? Direct solver захлёбывается в 30-35 тысячах токенов мета-информации, теряя релевантное в шуме. Datalake Agent стабильно использует 3-4 тысячи токенов независимо от числа таблиц.
Инсайт для практики: чем больше контекста, тем сильнее нужна селективность. До 50 таблиц можно давать всё — модель справится. Свыше 100 — дробление на этапы становится критичным для точности и обязательным для экономии.
Адаптации и экстраполяции
🔧 Техника: Мануальная эмуляция в чате для анализа множественных источников
Datalake Agent создан для SQL через API, но его принцип иерархического запроса работает и вручную для других задач с большим объёмом структурированной информации.
Кейс: Анализ 30 статей научных исследований для литобзора
Вместо:
❌ [Загрузить все 30 PDF]
Напиши литобзор по теме X
Делай:
✅ ШАГ 1:
У меня 30 исследований по теме "влияние сна на продуктивность".
Вот список названий и абстрактов:
1. "Sleep Duration and Cognitive Performance" — исследование 500 студентов...
2. "REM Sleep and Memory Consolidation" — эксперимент с...
[...полный список...]
Какие 5 работ наиболее важны для литобзора? Ранжируй по релевантности.
ШАГ 2:
[Загружаешь только топ-5 выбранных]
Вот полные тексты топ-5 работ. Выдели ключевые находки по теме.
Нужны ли ещё работы из списка для полноты картины?
ШАГ 3:
[Если LLM просит — даёшь дополнительные 2-3]
Финальная информация: [новые тексты]
Теперь напиши структурированный литобзор с категоризацией подходов.
Эффект: Вместо 200-300 страниц в одном промпте (упрёшься в лимит контекста) обрабатываешь 30-50 страниц релевантного. LLM не теряет фокус, ты экономишь токены.
🔧 Техника: Добавление слоя "объяснения выбора" для прозрачности
В оригинале LLM просто выбирает таблицы. Добавь требование объяснения — увидишь логику и сможешь скорректировать.
✅ Модифицированный шаг 1:
Вот список из {N} источников: [список]
Для ответа на вопрос "{вопрос}" выбери 3-5 наиболее релевантных.
Для каждого выбранного объясни:
1. Какую информацию он содержит
2. Почему она нужна для ответа
3. Что конкретно будешь искать в нём
Формат:
Источник X — релевантен, потому что [причина]. Буду искать [что именно].
Теперь ты видишь рассуждения модели и можешь сказать "нет, возьми ещё источник Y, там есть данные про Z".
🔧 Техника: Комбинация с Chain-of-Thought для сложного выбора
Если RelBench-задача требует сложного рассуждения "какие таблицы нужны", добавь CoT:
У меня 23 базы данных: [краткий список с доменами]
Вопрос: "Какие спонсоры клинических испытаний наиболее активны в 2023 году?"
Прежде чем выбрать БД, рассуждай пошагово:
1. Какие ключевые сущности нужны для ответа? (спонсоры, испытания, даты)
2. В какой предметной области искать? (медицина/clinical trials)
3. Какие БД из списка относятся к этой области?
4. Какие таблицы внутри выбранной БД вероятно содержат нужное?
Только после рассуждения — выбери БД и таблицы.
Эффект: Снижаешь ошибки выбора на первом шаге — LLM реже запрашивает нерелевантные источники.
Ресурсы
Agentic NL2SQL to Reduce Computational Costs Dominik Jehle, Lennart Purucker, Frank Hutter University of Freiburg, Prior Labs, ELLIS Institute Tübingen NeurIPS 2025
Связанные работы из исследования: - RelBench — бенчмарк для deep learning на реляционных базах данных - Spider и Bird — бенчмарки для NL2SQL задач - TQA-Bench — оценка LLM на multi-table вопросах со скейлируемым контекстом