Когда банковский аналитик спрашивает «топ-5 филиалов по доходу от срочных депозитов за прошлый месяц», правильный ответ уже лежит в SQL. Безопасно его извлечь — задача нескольких уровней: авторизован ли пользователь, какое определение метрики применяется, не утечёт ли в результате ИНН/IBAN, совпадают ли числа с показанным dataframe? Pipeline AI BI Copilot CentraQL управляет этой поверхностью на 11 стадиях.
Цель пайплайна
Превратить вопрос на естественном языке в трассируемый, аудируемый и доказуемый ответ. *Трассируемый* — на каждой стадии логируется, какой LLM с каким контекстом запускался. *Доказуемый* — пользователю виден SQL и семантические определения, лежащие в основе ответа.
1. Guard
До того как запрос коснётся поверхности, работает policy-слой: роль пользователя, классификация данных, ComplianceProfile (например, RegulatedFinance). Паттерны prompt-injection отсекаются лёгким regex + similarity-фильтром; высокорисковый ввод отклоняется и логируется.
2. Intent
Короткий вызов LLM (обычно planner 7B) классифицирует тип вопроса: агрегация, тренд, drill-down, объяснение аномалии. Каждый тип маршрутизируется к своему шаблону и few-shot-набору.
3. Retrieve (Qdrant)
Сертифицированные few-shots и определения KPI из domain pack эмбеждируются nomic-embed-text. Семантические соседи вопроса извлекаются; top-k (~5) подаются planner-у как контекст.
4. Plan — QuerySpec JSON
Planner LLM получает few-shot + вопрос. Выход — не свободный SQL, а JSON QuerySpec: метрика, измерения, фильтры, сортировка, лимит. Schema-валидатор форсирует структуру; несоответствующий выход отклоняется, разрешён один retry.
5. Validate
QuerySpec проверяется относительно семантического слоя. Существует ли метрика, валидны ли измерения, имеет ли пользователь доступ к полю фильтра? Под RegulatedFinance — дополнительно rangeOf, joinDepthMax, allowFreeText=false. При отказе пользователь получает причину.
6. Synth — SQL
QuerySpec детерминированный билдер превращает в T-SQL. LLM здесь не используется, поэтому галлюцинация невозможна. SQL форматируется, хэшируется, пишется в аудит.
7. Execute (read-only)
SQL выполняется через read-only-соединение. Timeout по умолчанию 30 с, под RegulatedFinance — 10 с. Лимит строк связан с профилем (обычно 1000).
8. Mask (PII)
Dataframe фильтруется по ColumnPolicy: ИНН, IBAN, email, телефоны маскируются или удаляются. Маскирование выполняется после execute и до narrate — чувствительные поля никогда не доходят до LLM.
9. Chart
По форме результата выбирается тип графика (line, bar, pie, table) и оси. QuerySpec мог это предопределить; иначе — эвристика.
10. Narrate (LLM)
Маскированный результат + chart spec уходят narrator-LLM. Sanitization-стадия сверяет числа/проценты/валюту в нарративе с исходной таблицей; расхождения исправляются.
11. Audit
Метаданные каждой стадии пишутся в PromptAuditLog: query hash, пользователь, timestamp, имена и токены planner/narrator, возвращённые строки, маскированные колонки, p50/p95. По умолчанию 365 дней retention для BDDK.
Профиль латентности
На 1×RTX 4090 + Qdrant + SQL Server p95 ≈ 6-9 с:
- Guard + Intent: 200 мс
- Retrieve: 80 мс
- Plan (7B q4): 2-3 с
- Validate + Synth: 60 мс
- Execute: 150-800 мс
- Mask: 30 мс
- Narrate (14B q4): 1.5-3 с
- Audit (async): 20 мс
Заключение
Pipeline CentraQL Copilot — обратная парадигма «пусть LLM пишет SQL»: LLM работает только с языком и нарративом; SQL приходит из детерминированного билдера, проходит семантический слой и границу каталога, а маскирование идёт до того, как модель увидит данные. Итог — архитектура регуляторного класса с нулевым риском галлюцинаций по числам.
