RAG correctivo para consultas de factura en WhatsApp

La mayoría de los demos de RAG los califica una audiencia que no puede verificar la respuesta. Le preguntas algo a un bot de documentación y vuelve un párrafo fluido y plausible — nadie en la sala sabe si la tercera oración está inventada, así que el demo funciona.

Facturación no es así. Cuando un suscriptor pregunta “¿por qué mi factura salió más alta este mes?”, tiene la factura en la mano. Va a verificar. Una respuesta equivocada con seguridad sobre el dinero de alguien no es una falla blanda que aparece en un eval después; es un ticket de soporte, un reclamo, y un cliente que ahora confía menos en el canal que antes de que lo automatizaras.

Construimos un asistente de WhatsApp para ABDO 77, un ISP de Guigue, Carabobo, que responde consultas de plan y facturación. Tiene dos fuentes: una base de conocimiento de documentos markdown, recuperada con RAG correctivo, y una llamada a un API que trae los datos del suscriptor concreto cuando la respuesta depende de su cuenta.

Esa separación es todo el diseño, y es lo que casi todas las implementaciones hacen mal — no porque sea difícil de construir, sino porque las dos fuentes fallan de formas completamente distintas y la gente le aplica la misma mitigación a ambas.

El modo de falla que el RAG naive no puede ver

El retrieval-augmented generation estándar es un pipeline sin dudas propias: embebe la pregunta, trae los top-k chunks, los mete en el prompt, genera. Al modelo se le instruye responder desde el contexto, y lo va a hacer — contenga o no el contexto la respuesta.

Ahí está todo el problema. El pipeline no tiene ningún paso donde algo pregunte “¿sirvió ese retrieval?”. Una consulta que no matchea nada útil igual devuelve k chunks, porque top-k siempre devuelve k. Y el modelo hace lo que hacen los modelos con contexto flaco: produce algo fluido a partir de material adyacente.

Para un bot de documentación eso degrada a vaguedad. Para facturación degrada a un número específico, verificable y equivocado.

Las consultas de plan y factura además son inusualmente hostiles a la similitud por embeddings. “¿Por qué subió mi factura?” está semánticamente cerca de la página de tarifas, la de promociones, los términos de servicio y la política de prorrateo — las cuatro hablan de cargos, y solo una explica el delta de este suscriptor. El retrieval te va a entregar con gusto al vecino equivocado que suena seguro.

Qué agrega de verdad el RAG correctivo

El RAG correctivo (Yan et al., 2024) inserta el paso que al RAG naive le falta: un evaluador de retrieval liviano que puntúa los documentos recuperados contra la consulta antes de generar, y emite un veredicto de confianza — el paper usa Correct, Incorrect y Ambiguous. Lo que sigue se bifurca según ese veredicto en vez de correr siempre el generador.

El mecanismo que importa en producción no es la mejora de accuracy en benchmarks. Es que la arquitectura tiene dónde poner el “no sé”. El RAG naive estructuralmente no puede abstenerse: no existe la rama. CRAG crea la rama, y de ahí en adelante decidir qué vive ahí es tu trabajo.

Nuestra razón para usarlo fue general: el retrieval correctivo es la técnica actual para que un pipeline de RAG cache sus propios malos retrievals en vez de generar encima de ellos. Lo que lo volvió no-opcional en vez de deseable fue el dominio. En la mayoría de las aplicaciones un retriever que se autocorrige mejora un promedio. En facturación es la diferencia entre “le pido a alguien que lo revise” y un número equivocado sobre dinero.

La respuesta del propio paper ante un mal veredicto es ampliar el retrieval: búsqueda web como extensión cuando el corpus local vuelve débil, más un paso de descomponer-y-recomponer para sacar el material irrelevante de los chunks que sí sobrevivieron. Para un asistente de facturación, ampliar a la web abierta es exactamente lo incorrecto: la respuesta a “por qué subió mi factura” no está en internet, está en el tarifario de este operador y en la cuenta de este suscriptor. Así que aquí la rama Incorrect no busca más lejos. Se detiene y entrega.

Ya existe además una reproducción open-source independiente de CRAG con análisis de explicabilidad, y vale leerla antes de comprometerse — el evaluador de retrieval es el componente del que cuelga toda tu política de abstención, y saber dónde se equivoca con seguridad es más útil que saber su puntaje promedio.

Dos fuentes, dos modos de falla, dos mitigaciones

Este es el error que vale la pena ahorrarte: tratar una llamada a un API como si fuera otro retrieval.

No son la misma clase de cosa, y la diferencia no es académica.

El corpus markdown se recupera por similitud. Puede devolverte al vecino equivocado que suena seguro — la página de promociones cuando preguntaste por prorrateo. La falla es de relevancia, y la relevancia es exactamente lo que un evaluador de retrieval está hecho para calificar. Ese es el trabajo de CRAG y lo hace bien.

El API del suscriptor es un lookup por clave. Pasas un identificador y te devuelve los datos de esa cuenta. Calificarlo por relevancia no significa nada: no es “probablemente sobre” el suscriptor correcto, o devolvió el registro correcto o dio error. No hay veredicto Ambiguous que computar, y correrle un evaluador de relevancia no te compra nada.

Pero el API introduce un modo de falla que el retrieval no tiene, y es fácil de pasar por alto porque los datos que entran son correctos: el modelo puede narrar mal números exactos. Dale a un LLM un saldo actual, un saldo previo y tres ítems de factura, y pídele que explique la diferencia — le acabas de pedir aritmética y atribución en prosa. Va a sonar completamente seguro en cualquiera de los dos casos. El evaluador de retrieval no te ayuda: nada se recuperó mal.

Así que las mitigaciones no se transfieren:

	Corpus markdown	API del suscriptor
Cómo se alcanza	Búsqueda por similitud	Lookup por clave
Cómo falla	Recupera el documento equivocado-pero-cercano	Devuelve datos correctos que el modelo describe mal
Qué lo atrapa	Evaluador de retrieval, rama de abstención	Que el modelo nunca calcule las cifras — pasar lo que devolvió el API
Qué no ayuda	—	Una calificación de relevancia

El principio general: los números que salieron de un sistema de registro deben llegarle al suscriptor como esos números, no como el resumen que el modelo hizo de ellos. El trabajo del modelo es la oración alrededor de la cifra, no la cifra. Todo lo que requiera un delta, un total o una comparación de fechas es un cálculo, y un cálculo va en código donde se puede testear — no en un párrafo donde solamente suena fluido.

Es la parte en la que más insistiríamos revisando el asistente de facturación de cualquier otro, porque sobrevive a cada upgrade de modelo. Un modelo mejor narra la aritmética equivocada de forma más convincente.

WhatsApp te quita las afordancias que normalmente usarías

La mitigación estándar para la incertidumbre del retrieval es mostrar el trabajo: citas inline, panel de fuentes, tarjeta al pasar el cursor, insignia de confianza. Las interfaces de chat web están llenas de lugares donde poner matices.

WhatsApp no tiene ninguno. Tienes texto plano, en un hilo que el usuario lee en el teléfono, en un canal que asocia con hablar con personas. No hay nota al pie. No hay panel lateral. Una URL larga pegada a mitad de frase se lee como spam, no como cita.

De ahí salen dos consecuencias, y las dos son restricciones de diseño, no detalles de implementación:

El matiz tiene que ser estructural, no tipográfico. No puedes atenuar una oración de baja confianza ni colgarle un superíndice. La única señal honesta disponible es qué dice el mensaje y si dice un número o no. Lo que significa que la decisión de confianza tiene que ocurrir antes de generar — exactamente lo que te da el evaluador — porque no puedes retro-inyectarle duda a una oración que ya afirmó una cifra.

La salida de emergencia tiene que ser una persona. En una app web, “no estoy seguro” puede degradar a un buscador o a un enlace de documentación. En WhatsApp el usuario ya está en una conversación; la degradación natural es entregarle esa conversación a un agente humano con el contexto adjunto. Esta es la parte que convierte todo esto en un proyecto de operaciones y no solo de IA — la ruta de abstención necesita dónde aterrizar, y eso quiere decir que la guardia de soporte es parte de tu arquitectura.

La ruta de abstención es el producto

El instinto es tratar las abstenciones como la tasa de falla y llevarlas a cero. Eso optimiza lo incorrecto. Cada abstención que eliminas aflojando el evaluador se convierte en una respuesta segura sobre una factura, y un subconjunto de esas está mal de una forma que el cliente va a notar.

El encuadre que sobrevive al contacto con un equipo de operaciones: el trabajo del asistente no es responder todo, es absorber el volumen que sí es respondible y entregar el resto de forma limpia. Comparaciones de plan, qué significa un ítem de la factura, cuándo cierra el ciclo, qué cubría una promoción y cuándo venció — ese es volumen real, repetitivo, con respuestas verificables que ya viven en documentos. Vale automatizarlo.

“¿Por qué mi factura está $14 más alta que el mes pasado?” es otra pregunta. Necesita la cuenta del suscriptor, no el tarifario — respóndela desde documentos y te equivocas con todo suscriptor cuyo delta vino de otra cosa. Para eso está la llamada al API.

Saber cuál de las dos estás mirando es el problema de ingeniería real, y ocurre antes de tocar cualquiera de las dos fuentes. Es una decisión de ruteo, y el evaluador de retrieval es lo que hace posible rutear.

En la práctica el handoff se dispara por tres condiciones, y solo la primera es la ingeniosa:

1. El evaluador devuelve un mal veredicto sobre lo que recuperó.
2. La pregunta no está en la base de conocimiento — ningún documento la cubre, así que no hay de qué estar seguro.
3. El usuario pide una persona. Sin condiciones, de inmediato, sin intentar satisfacerlo antes.

La tercera vale decirla en voz alta porque es la que los equipos discuten. Siempre hay presión para que el bot intente una vez más antes de soltar la conversación — mejora tu métrica de contención. También significa que el suscriptor que escribió “quiero hablar con una persona” recibe un párrafo que no pidió. En un canal que la gente usa para hablar con gente, ignorar ese pedido es cómo le enseñas que el bot es un obstáculo y no una puerta de entrada.

Qué medir

El accuracy sobre un set estático de eval es necesario y muy insuficiente, porque las fallas interesantes son las que el retrieval acertó a estar seguro y equivocado. Cuatro cosas que vale instrumentar desde el día uno:

• Tasa de abstención, medida a propósito — como una perilla que ajustas contra reclamos, no como un defecto a minimizar
• Calidad del handoff — cuando toma un humano, ¿recibió el contexto o arranca de cero y vuelve a preguntar todo?
• Respuestas verificadas como equivocadas — el conteo que de verdad importa y el único que el cliente siente; sale de soporte, no de tu harness de evals
• Desacuerdo del evaluador — muestrea dónde el veredicto de retrieval y la resolución humana final divergen; ese conjunto es donde vive tu próximo arreglo

La forma general de esto —evals, control de costos, guardrails— es la misma disciplina que necesita cualquier sistema de IA en producción. Facturación solo te quita el margen de error, lo que la vuelve una buena función forzante.

Dónde aplica

Cualquier operador con preguntas de volumen alto, repetitivas y respondibles desde documentos, en un canal donde el usuario espera un humano: ISPs, servicios públicos, aseguradoras, clínicas, administradoras de inmuebles. La forma común es una estructura tarifaria documentada, una base de suscriptores que hace las mismas cuarenta preguntas, y un equipo de soporte ahogado en las respondibles.

Si eso describe tu operación, cuéntanos el volumen de consultas y te decimos qué tajada vale automatizar y qué tajada necesita estado de cuenta — la segunda es normalmente donde los proyectos así se van al carajo.

Una nota honesta de alcance: esto es un sistema para un operador, descrito como arquitectura y no como benchmark. No te vamos a mostrar un gráfico de tasa de deflexión sobre una muestra de uno. Lo que sí podemos mostrarte es el razonamiento, y tres sistemas más que construimos y siguen corriendo.