RAG vs. fine-tuning: cómo elegir la arquitectura correcta para tu agente bancario con IA

Implementar Inteligencia Artificial en un banco no es lo mismo que implementarla en cualquier otra industria. Los márgenes de error son prácticamente nulos, la información cambia todo el tiempo y las consecuencias de una respuesta incorrecta pueden ser concretas y costosas. El desafío real no es acceder a un LLM poderoso: esos existen y son cada vez más capaces. El desafío es hacer que ese modelo sepa lo que tu banco necesita que sepa, en el momento en que lo necesita.

Para resolver eso, hay dos estrategias principales: RAG (Retrieval-Augmented Generation) y fine-tuning. Las dos abordan el problema desde ángulos distintos, y elegir mal puede comprometer todo el proyecto. En este post las explicamos en profundidad y argumentamos por qué, en el contexto de agentes bancarios, la decisión es bastante clara.

Primero: qué es un LLM y por qué solo no alcanza

Un LLM (Large Language Model) es un modelo estadístico entrenado sobre cantidades masivas de texto. Es la tecnología detrás de herramientas como ChatGPT, Gemini o Claude, y se ha convertido en la cara más visible de la IA generativa. Pero en la industria bancaria, usarlo directamente sin infraestructura adicional tiene limitaciones concretas que no se pueden ignorar.

La primera es temporal: el conocimiento de un LLM tiene fecha de corte. Lo que pasó después de su entrenamiento, para el modelo simplemente no existe. En banca, donde las tasas, los productos y la normativa pueden cambiar de un mes a otro, eso es un problema serio.

La segunda es de alcance: el modelo no tiene acceso a sistemas externos ni a datos transaccionales. No sabe el saldo de ningún cliente, no conoce el estado de una solicitud de crédito y no puede consultar el historial de movimientos de una cuenta en tiempo real. Por más capaz que sea el modelo base, sin integración externa su utilidad en un entorno bancario es limitada.

La tercera es de dominio: con documentación extensa, no alcanza con meter todo en el prompt. Y en dominios específicos, el modelo puede generar respuestas incorrectas con aparente confianza, lo que en banca tiene consecuencias directas.

RAG y fine-tuning son las dos estrategias principales para atacar estas limitaciones. Pero lo hacen de formas muy distintas.

Fine-tuning: especializar el modelo

El fine-tuning consiste en continuar el entrenamiento de un modelo base usando datos propios: documentos internos, conversaciones de ejemplo, terminología del dominio. El resultado es un modelo que "habla" el lenguaje de la organización con más naturalidad, entiende la jerga interna y mantiene un tono consistente con la marca.

Técnicamente, el proceso modifica los pesos del modelo. Eso significa que el conocimiento queda grabado en el momento del entrenamiento. Técnicas como LoRA permiten hacerlo de forma más eficiente, modificando solo un subconjunto de parámetros. Aun así, hay un riesgo concreto que vale la pena tener en cuenta: el catastrophic forgetting, que ocurre cuando el modelo pierde capacidades generales al especializarse demasiado.

¿Cuándo tiene sentido el fine-tuning? Para adaptar estilo, tono y comprensión de terminología interna, puede ser una capa complementaria valiosa. Pero como estrategia central de conocimiento, tiene un problema fundamental: el conocimiento que inyecta queda estático. El modelo entrenado hoy no sabrá nada de lo que cambie mañana.

En banca, ese es el problema central.

RAG: separar el conocimiento del modelo

RAG (Retrieval-Augmented Generation) funciona de una manera diferente: en lugar de incorporar el conocimiento al modelo, el sistema lo busca en el momento en que lo necesita.

El flujo es el siguiente: la consulta del usuario se convierte en un vector, se compara contra una base de documentos indexados y el sistema recupera los fragmentos más relevantes. Esos fragmentos se pasan al modelo como contexto, y el modelo genera una respuesta basada en esa información.

La base de documentos, que típicamente vive en una vector database como Pinecone, Weaviate o pgvector, puede actualizarse de forma independiente al modelo. Cuando la documentación del banco cambia, se re-indexa. El modelo sigue siendo el mismo. No hay que reentrenar nada.

Para consultas que requieren datos transaccionales en tiempo real, RAG se complementa con llamadas directas a APIs externas desde el backend. El LLM recibe tanto el contexto recuperado como el resultado de esas consultas, y sintetiza una respuesta que combina ambas fuentes.

Esa combinación, RAG + APIs directas, es lo que permite construir un agente bancario realmente funcional.

Por qué RAG + APIs directas gana en banca

Un agente bancario tiene requerimientos que definen rápido qué arquitectura es viable. Trabaja con información que cambia con frecuencia. Necesita acceder a datos del cliente en tiempo real. Y tiene tolerancia prácticamente cero al error: confundir un saldo o inventar una condición de crédito tiene consecuencias concretas para el cliente y para el banco.

El fine-tuning como estrategia central no escala bien en ese contexto. El conocimiento más crítico es dinámico, y el fine-tuning lo congela. Mantenerlo actualizado requiere reentrenar periódicamente, con el costo computacional y operativo que eso implica. Y aun así, no resuelve el acceso a datos transaccionales: un modelo entrenado con los productos del banco no sabe el saldo de ningún cliente en runtime, así que la integración externa la tenés que resolver igual.

La combinación RAG + APIs directas resuelve las dos dimensiones del problema al mismo tiempo. El knowledge base, productos, condiciones, FAQs, normativa, se mantiene en una vector database actualizable sin tocar el modelo. Las consultas en tiempo real se resuelven llamando directamente a las APIs del banco desde el backend. El LLM actúa como capa de síntesis: recibe contexto recuperado más datos transaccionales y genera la respuesta.

Hay otro factor que en entornos regulados no es menor: la auditabilidad. Con RAG, cada respuesta es trazable. Se puede saber de qué documentos vino el contexto y qué versión estaba indexada al momento de la consulta. Eso es algo que un modelo fine-tuneado no puede ofrecer con facilidad.

Cómo se ve el stack en producción

El flujo de un agente bancario con RAG + APIs directas funciona así:

Cuando el usuario envía un mensaje, la consulta se vectoriza para buscar contexto relevante en la base documental, en paralelo con cualquier llamada a API que la consulta requiera. El sistema de retrieval recupera los fragmentos más relevantes, productos, condiciones, FAQs, normativa, y si la consulta requiere datos en tiempo real, se llaman los endpoints correspondientes: saldo, movimientos, estado de solicitudes. Finalmente, el LLM recibe el contexto recuperado más los datos de API y genera la respuesta. No recuerda entre conversaciones: razona sobre lo que recibe en cada turno.

Es una arquitectura con más piezas que un prompting simple, sí. Pero es la arquitectura que resuelve el problema real.

La decisión en resumen

Para conocimiento documental, productos, condiciones, FAQs, normativa, la respuesta es RAG: actualizable sin reentrenar, trazable por fuente, sin necesidad de tocar el modelo cada vez que algo cambia.

Para datos transaccionales, saldos, movimientos, estado de trámites, la respuesta son APIs directas desde el backend: más control, tiempo real y sin ambigüedad.

Para la generación de respuestas, el LLM opera como capa de síntesis sobre el contexto inyectado por las dos fuentes anteriores.

El fine-tuning sigue siendo útil como capa complementaria, para que el modelo entienda terminología interna o mantenga un tono consistente, pero no es la estrategia central de conocimiento en un dominio dinámico.

‍