Что меняется в банке и других регулируемых отраслях

Нарушение важнее пользы

В обычном продукте agent (модель, которая сама вызывает инструменты) хорош, если чаще помогает. В regulated industry (регулируемой отрасли: банки, страхование, медицина, госуслуги — там работу проверяет надзорный орган) одна ошибка может стоить дороже тысячи удачных ответов. Агент назвал неверную ставку, пообещал отменить комиссию, выполнил действие без подтверждения или прочитал клиенту чужие транзакции — это уже не «плохой ответ», а инцидент: жалоба, штраф, проверка регулятора.

Поэтому первая метрика — policy violation rate (доля разговоров с нарушением политики), и считают её отдельно от task success (доли решённых задач). В один балл их не складывают: агент, который решает 95% задач и в 0,5% разговоров раскрывает чужие данные, хуже агента с 85% и нулём утечек. На собеседовании это звучит так: «policy adherence outranks helpfulness».

«Никогда» — свойство архитектуры, а не теста

Тест не может доказать «никогда». Если в 3 000 попыток утечек ноль, rule of three (правило трёх: при 0 провалов в n независимых попытках верхняя граница 95-процентного доверительного интервала ≈ 3/n) даёт только «скорее всего, реже 1 раза на 1 000». Для банка с миллионом разговоров в месяц это до тысячи возможных утечек. Значит, гарантия должна жить в коде:

• доступ берётся из verified session (проверенной сессии клиента), а не из параметра, который заполнила модель: tool get_statement вообще не принимает номер счёта от модели;
• действия с деньгами и картами требуют явного confirmation (подтверждения клиентом), и проверяет его harness (обвязка, которая исполняет вызовы tools), а не модель;
• ставки, комиссии и лимиты приходят из tool, который читает справочник, а не из текста модели.

Тесты после этого подтверждают, что архитектура держит, и измеряют residual risk (остаточный риск) — то, что кодом не закрыть. Например, данные контрагента, которые клиент сам назвал в разговоре.

Свой набор задач с враждебными клиентами

Публичный benchmark (стандартный набор задач) говорит, что модель способная, но не говорит, что она соблюдает твою политику. Образец — τ-bench: симулированный клиент разговаривает с агентом, у агента настоящие tools и база, а оценивают конечное состояние базы, а не красоту ответа. Для банка такой набор собирают так:

• реальные регламенты и реальный набор tools (баланс, блокировка карты, спор по транзакции, смена лимита) поверх mock-базы (учебной копии core banking — главной учётной системы банка);
• задачи из обезличенных реальных разговоров, с перевесом в сторону тех, что прошли плохо;
• adversarial tasks (враждебные задачи): выдача себя за другого («я звоню за жену»), давление ради исключения, инструкция внутри описания транзакции. Последнее — indirect prompt injection (команда для модели, спрятанная в данных).

Оценка детерминированная: заблокирована ли карта, создан ли спор, остался ли чужой лимит прежним.

Отчёт по срезам, а не одно число

Общая цифра прячет сломанный сегмент. Если 90% трафика на английском и там всё хорошо, а арабский путь проваливается, средний балл выглядит здоровым. Поэтому результаты показывают отдельно по языкам, диалектам, каналам и типам задач. Типичные места тихой деградации: смена языка посреди фразы, местные диалекты, другие цифры (арабско-индийские ٠١٢٣), форматы дат.

Пример. Английский: 900 разговоров, 18 нарушений (2%). Арабский: 100 разговоров, 9 нарушений (9%). Вместе — 27 из 1 000, то есть 2,7%, и порог «не выше 3%» пройден. Срез показывает, что арабский путь в 4,5 раза хуже, и выпускать его нельзя.

Отраслевые галлюцинации и версии документов

Hallucination (уверенный, но неверный ответ) в регулируемой отрасли часто доменная: модель путает термины с юридическим смыслом. Пример из исламского финансирования: там говорят profit rate (ставка прибыли), а не interest (процент), а Murabaha (продажа с согласованной наценкой) и Ijara (аренда) устроены иначе, чем кредит. Такая ошибка — риск mis-selling (продажи клиенту не того продукта) и нарушения шариатских норм, которые банк обязался соблюдать. Похожие ловушки есть в страховании (что покрывает полис) и в медицине (дозировки). Защита — проверять ответ по найденным источникам и оценивать citations (ссылки на источник), а не правдоподобие.

Вторая ловушка — версии. Тарифы и правила меняются, и применимой может быть версия, действовавшая в день подписания договора. Каждый документ получает valid_from и valid_to, а фильтр по дате стоит в коде retrieval (поиска), а не в просьбе к модели «бери свежий документ».

Одна логика для банка, страховой и клиники

Отрасли разные, но вопрос один: что считается провалом и где стоит гарантия.

Отсюда порядок ответа на собеседовании. Сначала — что считается провалом, кто подписывает порог и о чём на самом деле спрашивают клиенты. Только потом — модель, harness и данные. Первое — ответ владельца продукта, второе — ответ сборщика; в регулируемой отрасли ждут первого.

Что ещё меняется в работе.

• Audit trail (журнал для проверки): каждое действие агента связано с сессией и версиями модели, prompt и tools, чтобы через полгода восстановить, почему агент поступил так.
• Human oversight (надзор человека): решения с большим влиянием на клиента принимает или выборочно проверяет человек.
• Online-половина: offline-набор решает, можно ли выпускать, а production показывает правду. Выпуск идёт через shadow (новая версия отвечает параллельно, клиент её не видит), затем canary (малая доля трафика), затем мониторинг жалоб, передач человеку и повторных обращений плюс еженедельная выборка разговоров, которую читают люди.