Governed SQL analyst agent

Где здесь настоящая сложность

Заставить модель написать SQL это не интересная задача. В витрине, где неверное число двигает деньги, интересное начинается дальше: что решает, можно ли отдать полученное число человеку, и сумеет ли кто-нибудь потом восстановить это решение.

Поэтому агент построен вокруг границы: модель оценивает, предлагает и формулирует, решает управляемый код. Агент не может расширить себе доступ, не может пропустить собственные проверки, и каждый его ход воспроизводится из лога.

Один вопрос от начала до конца

Порядок здесь и есть суть. Валидация статическая и дешёвая, поэтому идёт до выполнения, и небезопасный запрос до базы не доходит. Cross-check идёт после того, как ответ написан, потому что проверяется именно то число, которое агент собирается назвать.

вопрос
  -> входной скрининг       сообщение-инструкция отклоняется и логируется
  -> план                   модель пишет SQL и объявляет, какой канонической
                            метрике должно равняться её главное число
  -> валидация              AST: один оператор, только чтение, только
                            разрешённые таблицы, без закрытых колонок,
                            без файловых и сетевых функций, лимит строк
       отклонено -> правило возвращается модели, до 2 попыток починки
  -> выполнение             соединение только на чтение, таймаут 15 секунд
  -> формулировка           ответ пишется строго по вернувшимся строкам
  -> проверки               пустой результат, обрезка, свежесть данных,
                            отрицательные счётчики, канонический cross-check
       любой провал -> число не уходит, ход эскалируется
  -> ответ + доказательство + запись в аудит

Слой управления запросами

Правила проверяются по разобранному синтаксическому дереву, а не по тексту запроса, поэтому трюки с комментариями и склейкой строк не проходят. Вся политика лежит в одном читаемом файле, и любая её правка это один понятный диф.

Защита многослойная, а не сведённая к входному фильтру. Инъекция, проскочившая скрининг, всё равно не даст запроса за пределы белого списка, а модель, решившая помочь с адресами почты, всё равно не сможет выбрать эту колонку.

Проверки до того, как число уйдёт

Провалившаяся проверка не даёт осторожный ответ с оговоркой. Она не даёт числа вообще, вместо него уходит trace id, по которому человек откроет ход целиком. И последнее слово о том, запускать ли cross-check, не за моделью: если запрос вернул одно число, чей алиас называет каноническую метрику, проверка выводится из самого запроса. Контроль, который срабатывает, только когда модель о нём вспомнила, это не контроль.

Что видит ревьюер

Каждый ход дописывает полную запись в аудит-лог, и консоль ревью генерится из этого лога: отклонённые запросы стоят рядом с правилом, которое их отклонило, а кнопки оценки экспортируются как данные для evals.

Дашборд, по которому команда рулит

Агент записывает каждое своё решение, поэтому его собственные рабочие показатели достаются одним запросом. Дашборд генерится из этого лога и истории прогонов: объём решений, причины, по которым ход не дал числа, поведение каждой проверки, дрейф сверки относительно порога 0,5%, задержки, история набора и очередь ходов, на которые человеку стоит посмотреть.

Обе поверхности живые, откройте и потыкайте:

дашборд производительностиконсоль ревью

Консоль это поверхность ревью: разверните любой ход и увидите предложенный SQL, правило, которое его отклонило, строки, проверки, и сможете поставить оценку. Оценки выгружаются в JSONL, том самом формате, в котором написаны кейсы набора.

Проверка качества

Для недетерминированной системы один зелёный прогон это не доказательство, поэтому набор показывает стабильность каждого кейса на повторных прогонах.

Все пять промахов это один и тот же кейс: среднее число ставок на активного игрока в день, которое модель примерно в трети случаев не вытягивает. Она либо не успевает написать запрос за три попытки, либо выдаёт число, которое отклоняет проверка. Неверного числа по нему не ушло ни разу: уходит отсутствие числа. Кейс остаётся в наборе со своей настоящей долей прохождения, а не переформулирован до зелёного. Остальные пятнадцать не упали ни разу за шестнадцать прогонов.

Что набор поймал по ходу разработки, и каждое стало правкой, а не заметкой:

• Агент сравнивал колонку timestamp с голой конечной датой и молча терял последний день каждого диапазона. Поймано cross-check'ом на расхождении 10.9%.
• Он суммировал все выводы средств там, где каноническая витрина считает только проведённые. Именно так в проде уплывает определение метрики. Поймано на 29.6% и оставлено постоянным регрессионным кейсом.
• Он отказался отвечать на вполне отвечаемый вопрос, потому что указание предпочитать витрины прочиталось как запрет на базовые таблицы. Лишний отказ это дефект, и набор оценивает его как дефект.
• Когда набор начал проверять, запустился ли cross-check вообще, а не только выглядит ли ответ правильным, один кейс упал до 1 из 5: агент отвечал верно, но пропускал объявление, и число уходило непроверенным. Починка была не в промпте. Вывод проверки переехал в детерминированный код, и кейс вернулся к 5 из 5.
• Потом багом оказалась сама сверка. Прогон банка из 40 живых вопросов дал четыре ответа, заблокированных по бессмыслице: бонусная сумма сравнивалась с игровыми выплатами, счётчик отклонённых выводов с суммой в евро, самый крупный вывод оказался «на 1862% мимо» месячного итога. Проверка опознавала метрику по названию колонки. Теперь она ещё требует, чтобы метрика бралась из таблицы, где она определена, чтобы агрегат совпадал по типу (максимум это не сумма, среднее на игрока это не количество) и чтобы запрос не отвечал по срезу. Все четыре стали постоянными регрессионными кейсами.
• Чистые депозиты приходили с обратным знаком, выводы минус депозиты, и так весь батч прогонов. Починка была не в промпте: определения метрик переехали в каталог витрины, который читает агент, прямо к колонкам, которые они описывают, потому что определению место там.
• Запрос, прошедший валидацию и упавший уже в базе, раньше обрывал ход. Ошибка базы это такая же исправимая ошибка, поэтому теперь она возвращается модели так же, как отклонённый запрос.
• Два кейса всё же не прошли на более раннем этапе. В одном число по чистым депозитам разошлось с канонической витриной, и cross-check его заблокировал: пользователь получил не неверное число, а никакого. Во втором верный ответ не прошёл проверку оценки и не повторился на двенадцати дальнейших прогонах. Оба записаны, потому что набор, который всегда зелёный, это набор, из которого никто ничего не узнаёт.

Что здесь настоящее, а что упрощено

Все данные в проекте синтетические и генерятся с фиксированным зерном. Никаких реальных компаний, клиентов и транзакций в нём не используется. Сделано в августе 2026 года. Исходный код показываю по запросу.