Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Семантические описания данных дают SQL-агентам основную прибавку к точности, а инструменты поиска лишь помогают применить эти знания вовремя. В нерецензированном препринте Qing Ye, где все числа получил сам автор, восстановление описаний подняло точность на сложных задачах как минимум на 26 процентных пунктов. Для архитектуры агента это меняет порядок работ: сначала стоит формализовать бизнес-смысл данных, затем строить поиск и только после этого выносить проблемные расчёты в готовые SQL-представления.
Как содержание отделили от способа доставки
Контекстный слой — это документация о таблицах, показателях и правилах предметной области, которую агент получает перед созданием SQL. Обычно такой слой одновременно добавляет знания, инструменты для их поиска и готовые представления. Сравнение системы со слоем и без него не показывает, какая часть дала результат.
В работе эти части разделили с помощью контракта данных в YAML. Полный контракт описывал таблицы, столбцы, связи, показатели и правила расчёта комиссий. Он также задавал список разрешённых таблиц и запрещал операции, способные изменить хранилище.
Для контрольного режима из контракта удалили весь содержательный текст и SQL-выражения, но сохранили структуру, названия, инструменты, инструкции поиска и правила доступа без изменений. Агент по-прежнему искал сведения тем же способом, но получал пустые определения. Так автор измерил пользу поисковой обвязки без семантики.
Ещё два режима проверяли крайние варианты. В одном те же знания целиком вставили в длинную системную подсказку, без отдельного поиска. В другом выражения из контракта превратили в заранее подготовленные SQL-представления, которые воспроизводили эталонные ответы на покрываемых ими заданиях. Последний режим показывал потолок для расчётов, заранее реализованных человеком.
Проверка охватила четыре модели и сложную часть DABStep — набора задач по платёжному хранилищу. Контракт описывал прежде всего комиссии: к этой области относились 294 из 332 сложных заданий. Каждый режим запускали по одному разу, а часть результатов сверяли с восстановленными эталонными ответами, поэтому абсолютные оценки могут быть немного завышены.
Семантика даёт прирост, поиск помогает её не потерять
Возврат содержательных описаний в пустой контракт добавил точности как минимум 26 процентных пунктов на каждой модели. Сама поисковая обвязка почти не помогла быстрым моделям, а на более способных дала около 15 пунктов. Значит, наличие инструмента поиска не заменяет словарь бизнес-правил, хотя способные модели лучше используют структуру вокруг него.
Полный контракт обошёл длинную подсказку на всех моделях, хотя знания в обоих режимах совпадали. Причина видна в созданном SQL: в лучшем случае агент с контрактом переносил нужное правило расчёта комиссии в запрос в 98% заданий, а с длинной подсказкой — в 4%. Короткий целевой запрос к контракту оказался надёжнее, чем поиск нужного фрагмента внутри большого текста.
Контракт также влиял на поведение агента до фактической проверки запроса. Режимы без правил доступа отправили 166 команд, способных изменить данные; режимы с контрактом не отправили ни одной. Это не доказывает достаточность текстовых запретов для защиты хранилища, но показывает, что декларативные правила могут отсечь опасное действие ещё до валидатора.
В архитектуре сначала нужен словарь бизнеса, потом макросы
Работа меняет не набор компонентов, а приоритет их разработки. Первый артефакт для SQL-агента — не векторный поиск и не библиотека готовых запросов, а единое описание значений столбцов, правил соединения таблиц, трактовки пустых значений и формул показателей. Его стоит хранить в форме, из которой агент может получить одно правило в момент создания запроса.
Поисковая обвязка становится вторым этапом. Она должна ограничивать доступный набор таблиц и выдавать небольшой фрагмент контекста по запросу модели. Простое добавление всей документации в системную подсказку сохраняет знания формально, но не гарантирует, что модель применит нужное правило.
Заранее вычисленные представления и макросы нужны там, где агент регулярно ошибается при выводе SQL из описания. Разрыв с готовым представлением сократился с 39 до 5 процентных пунктов по мере роста возможностей модели. Это аргумент против переноса каждого показателя в отдельный макрос: сначала можно измерить повторяющиеся ошибки, а затем закрепить только проблемные расчёты.
Вывод относится к узкому платёжному домену и концентрированному набору задач. За пределами области, которую описывал контракт, преимущества перед обычной подсказкой не было. Поэтому результат поддерживает доменные контракты, но не доказывает, что один общий семантический слой улучшит любые аналитические запросы.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
