PSB a présenté son approche du RAG dans la fintech : architecture, métriques et cycle de tests

PSB a publié une analyse pratique de la manière dont elle évalue et teste l'approche RAG dans des tâches où le coût de l'erreur est particulièrement élevé. Au lieu de se fier à la « sagacité » du modèle, la banque parie sur une combinaison de sa propre base de connaissances, de recherche vectorielle, de métriques de qualité et de vérification manuelle régulière.

Comment fonctionne le RAG

PSB rappelle que le principal problème avec les LLM n'est pas seulement les mauvaises réponses, mais aussi les erreurs confiantes. C'est précisément pour cela que le RAG sert : le modèle recherche d'abord des informations dans un tableau de données fiable, puis génère une réponse. La base de connaissances peut être n'importe quoi — des documents, un site web, un référentiel interne ou une base de données structurée.

Mais pour que la recherche fonctionne rapidement, les matériaux doivent d'abord être divisés en fragments et convertis en vecteurs via un modèle d'embedding. La qualité du chunking détermine souvent le succès. Pour l'HTML et le texte brut, le matériel peut être divisé par paragraphes ; pour les documents formalisés — par ponctuation ; pour les matrices de données complexes — par nombre de tokens.

L'article souligne séparément qu'un token n'est ni un caractère ni un mot, mais une unité de division qui dépend du tokeniseur du modèle spécifique. Après la vectorisation, le système récupère les fragments pertinents de l'index, les ajoute au contexte et demande ensuite au modèle de générer une réponse.

Mesurer la qualité

PSB suggère d'examiner le RAG non pas par une seule métrique, mais selon trois dimensions : la qualité de la recherche, la précision de la réponse et la qualité de la présentation. Si le système ne trouve pas le document nécessaire, aucun LLM puissant ne sauvera le résultat. Si le document est trouvé, le problème suivant est de savoir si le modèle l'a compris correctement et n'a rien ajouté d'inutile. Ce n'est que puis qu'il est judicieux d'évaluer si la réponse est lisible, utile et pertinente par rapport à la question de l'utilisateur.

• Hit Rate — le système trouve-t-il des documents pertinents en général ?
• MRR — quel rang occupe le meilleur document dans les résultats ?
• Factual Accuracy — combien de déclarations factuellement correctes se trouvent dans la réponse ?
• Utilité et clarté — la réponse résout-elle la tâche sans digressions inutiles ?

Pour vérifier la précision, PSB utilise à la fois des calculs automatiques et une comparaison avec un « standard or » — des réponses préparées par des humains. Une autre couche de contrôle est un arbitre LLM, où un modèle séparé évalue le résultat du modèle principal. Mais en fintech, l'automatisation se heurte à des limitations : les données personnelles doivent être nettoyées de la base de connaissances, et reconnaître telles données ne fournit pas de garantie à 100%. C'est pourquoi la vérification manuelle reste une partie obligatoire du processus.

« RAG est une technologie, pas de la magie. »

Comment les tests sont menés chez PSB

Pour les tests, PSB applique la pyramide classique de qualité au RAG, mais ajustée pour l'architecture de tels systèmes. Au niveau inférieur, ils vérifient non pas des fragments de code individuels, mais des composants : le LLM lui-même, la base de données vectorielle, les paramètres d'extraction et le chunking de documents. Au niveau suivant se trouvent les tests API — ici vous pouvez regarder la charge, les réponses, le volume des chunks retournés et le nombre de tokens.

Plus haut se trouvent les scénarios E2E, où le comportement du système sur les requêtes réelles des utilisateurs compte. Et séparément, les tests manuels, qui restent inévitables dans les domaines sensibles. Le cycle d'évaluation lui-même est aussi décrit comme un processus continu.

D'abord, un ensemble de données de test est collecté : avec l'aide d'un LLM, vous pouvez générer de centaines à milliers de questions. Puis le RAG est exécuté sur cet ensemble, les réponses et documents trouvés sont sauvegardés, les métriques sont calculées, les goulots d'étranglement sont identifiés et le système est affiné. Pour l'évaluation automatique, PSB utilise actuellement RAGAS, et envisage à l'avenir ses propres outils — incluant des tableaux de bord, l'intégration CI/CD, la comparaison de versions A/B et les cartes thermiques des zones problématiques.

Cette approche est nécessaire non pas pour la pureté académique, mais pour suivre les dégradations et améliorations au fil du temps.

Ce que cela signifie

Pour les entreprises non disposées à dépenser de grands budgets pour le fine-tuning de modèles, le RAG reste le moyen le plus pratique d'améliorer rapidement la précision des services d'IA d'entreprise. Mais l'article de PSB illustre bien un point important : la récupération seule ne garantit rien. Vous avez besoin de discipline dans la préparation des données, de métriques claires, de tests réguliers et d'un humain dans la boucle — en particulier là où une erreur dans la réponse peut affecter l'argent, la conformité ou la sécurité du client.