PSB outlined its approach to RAG in fintech: architecture, metrics, and the testing cycle

ПСБ опубликовал практический разбор того, как оценивает и тестирует RAG-подход в задачах, где цена ошибки особенно высока. Вместо веры в «умную» модель банк делает ставку на связку из собственной базы знаний, векторного поиска, метрик качества и регулярной ручной проверки.

Как устроен RAG В ПСБ напоминают, что главная проблема LLM — не только

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

Но чтобы поиск работал быстро, материалы сначала нужно разбить на фрагменты и превратить в векторы через эмбеддинг-модель. Дальше многое решает качество разбиения на чанки. Для HTML и обычных текстов можно делить материал по абзацам, для формализованных документов — по пунктуации, а для сложных массивов данных — по числу токенов.

В статье отдельно подчеркивается, что токен — это не символ и не слово, а единица разбиения, зависящая от токенизатора конкретной модели. После векторизации система поднимает из индекса релевантные фрагменты, добавляет их в контекст и только затем просит модель сгенерировать ответ.

Чем мерить качество ПСБ предлагает смотреть на RAG не одной метрикой,

а сразу по трем направлениям: качество поиска, точность ответа и качество изложения. Если система не нашла нужный документ, никакая сильная LLM уже не спасет результат. Если документ найден, следующая проблема — поняла ли модель его корректно и не добавила ли лишнего. И только после этого есть смысл оценивать, насколько ответ вообще читаем, полезен и соответствует вопросу пользователя.

• Hit Rate — находит ли система релевантные документы в принципе MRR — насколько высоко в выдаче оказывается лучший документ Factual Accuracy — сколько фактически верных утверждений в ответе * Полезность и ясность — решает ли ответ задачу без лишних отклонений Для проверки точности в ПСБ используют и автоматический расчет, и сравнение с «золотым стандартом», то есть с ответами, подготовленными человеком. Еще один слой контроля — LLM-арбитр, когда отдельная модель оценивает результат основной. Но в финтехе автоматизация упирается в ограничения: персональные данные нужно вычищать из базы знаний, а распознавание таких данных само по себе не дает стопроцентной гарантии. Поэтому ручная верификация остается обязательной частью процесса.

«RAG — технология, а не магия».

Как тестируют в ПСБ В тестировании ПСБ переносит на RAG классическую

пирамиду качества, но с поправкой на архитектуру таких систем. На нижнем уровне проверяют не отдельные куски кода, а компоненты: саму LLM, векторную базу, настройки извлечения и разбиение документов. На следующем уровне идут API-тесты — здесь можно смотреть на нагрузку, ответы, объем возвращаемых чанков и число токенов.

Выше — E2E-сценарии, где уже важно, как система ведет себя в реальных пользовательских запросах. И, отдельно, ручное тестирование, без которого в чувствительных доменах пока не обойтись. Сам цикл оценки тоже описан как непрерывный процесс.

Сначала собирается тестовый датасет: с помощью LLM можно сгенерировать от сотни до тысячи вопросов. Затем RAG прогоняют по этому набору, сохраняют ответы и найденные документы, считают метрики, ищут узкие места и дорабатывают систему. Для автоматической оценки в ПСБ сейчас используют RAGAS, а в будущем рассматривают и собственные инструменты — в том числе дашборды, CI/CD-интеграции, A/B-сравнение версий и тепловые карты проблемных зон.

Такой подход нужен не ради академической чистоты, а чтобы отслеживать деградации и улучшения во времени.

Что это значит

Для компаний, которые не готовы тратить большие бюджеты на дообучение моделей, RAG остается самым практичным способом быстро повысить точность корпоративных AI-сервисов. Но статья ПСБ хорошо показывает важную вещь: сам по себе retrieval ничего не гарантирует. Нужны дисциплина в подготовке данных, понятные метрики, регулярные тесты и человек в контуре — особенно там, где ошибка в ответе может повлиять на деньги, комплаенс или безопасность клиента.