PSB expuso su enfoque de RAG en fintech: arquitectura, métricas y ciclo de pruebas

PSB publicó un análisis práctico de cómo evalúa y prueba el enfoque RAG en tareas donde el costo del error es particularmente alto. En lugar de confiar en la "inteligencia" del modelo, el banco apuesta por una combinación de su propia base de conocimiento, búsqueda vectorial, métricas de calidad y verificación manual regular.

Cómo funciona el RAG

PSB recuerda que el principal problema con los LLM no es solo respuestas débiles, sino también errores confiados. Es exactamente para esto que sirve el RAG: el modelo primero busca información en una matriz de datos confiable, y solo después genera una respuesta. La base de conocimiento puede ser cualquier cosa — documentos, un sitio web, un repositorio interno o una base de datos estructurada.

Pero para que la búsqueda funcione rápidamente, los materiales primero deben dividirse en fragmentos y convertirse en vectores a través de un modelo de embedding. La calidad de la división en chunks a menudo determina el éxito. Para HTML y texto simple, el material puede dividirse por párrafos; para documentos formalizados — por puntuación; para matrices de datos complejas — por conteo de tokens.

El artículo enfatiza por separado que un token no es un carácter o una palabra, sino una unidad de división que depende del tokenizador del modelo específico. Después de la vectorización, el sistema recupera fragmentos relevantes del índice, los agrega al contexto y solo entonces le pide al modelo que genere una respuesta.

Midiendo la calidad

PSB sugiere ver el RAG no a través de una única métrica, sino en tres dimensiones: calidad de búsqueda, precisión de respuesta y calidad de presentación. Si el sistema no encuentra el documento necesario, ningún LLM fuerte salvará el resultado. Si el documento se encuentra, el próximo problema es si el modelo lo entendió correctamente y no añadió nada innecesario. Y solo después tiene sentido evaluar si la respuesta es legible, útil y relevante para la pregunta del usuario.

• Hit Rate — ¿encuentra el sistema documentos relevantes en general?
• MRR — ¿qué tan alto clasifica el mejor documento en los resultados?
• Factual Accuracy — ¿cuántas afirmaciones factuales correctas hay en la respuesta?
• Utilidad y claridad — ¿resuelve la respuesta la tarea sin desviaciones innecesarias?

Para verificar la precisión, PSB utiliza tanto cálculos automáticos como comparación con un "estándar de oro" — respuestas preparadas por humanos. Otra capa de control es un árbitro LLM, donde un modelo separado evalúa el resultado del modelo principal. Pero en fintech, la automatización se encuentra con limitaciones: los datos personales deben eliminarse de la base de conocimiento, y reconocer tales datos no proporciona garantía del 100%. Por eso la verificación manual sigue siendo una parte obligatoria del proceso.

"RAG es tecnología, no magia."

Cómo se prueba en PSB

En las pruebas, PSB aplica la pirámide clásica de calidad al RAG, pero ajustada para la arquitectura de tales sistemas. En el nivel inferior, verifican no fragmentos de código individuales, sino componentes: el LLM en sí, la base de datos vectorial, configuraciones de extracción y división de documentos. En el siguiente nivel están las pruebas de API — aquí puede observar carga, respuestas, volumen de chunks devueltos y conteo de tokens.

Más arriba están los escenarios E2E, donde el comportamiento del sistema en consultas reales del usuario es importante. Y por separado, pruebas manuales, que aún son inevitables en dominios sensibles. El ciclo de evaluación en sí también se describe como un proceso continuo.

Primero, se recopila un conjunto de datos de prueba: con la ayuda de un LLM, puede generar de cientos a miles de preguntas. Luego, RAG se ejecuta a través de este conjunto, se guardan las respuestas y documentos encontrados, se calculan las métricas, se identifican los cuellos de botella y se refina el sistema. Para la evaluación automática, PSB actualmente usa RAGAS, y en el futuro considera sus propias herramientas — incluidos paneles, integración CI/CD, comparación de versiones A/B y mapas de calor de áreas problemáticas.

Este enfoque es necesario no por pureza académica, sino para rastrear degradaciones y mejoras a lo largo del tiempo.

Lo que esto significa

Para empresas no dispuestas a gastar grandes presupuestos en ajuste fino del modelo, RAG sigue siendo la forma más práctica de mejorar rápidamente la precisión de los servicios de IA corporativos. Pero el artículo de PSB muestra bien un punto importante: la recuperación por sí sola no garantiza nada. Necesita disciplina en la preparación de datos, métricas claras, pruebas regulares y un humano en el circuito — especialmente donde un error en la respuesta puede afectar dinero, cumplimiento o seguridad del cliente.