claudio.cool
CCAR-PLecciones

CCAR-P · Integración

Recuperación según la forma de los datos, y precisión contra latencia

⏱ 3 min de lecturaBorrador

Un equipo de ventas exportó dos millones de filas de pedidos, generó un embedding por fila y conectó una búsqueda semántica. Pregunta “pedidos pendientes de más de 10.000 de la región norte del último trimestre” y recibe un puñado de filas parecidas, con faltantes y algunas de otro trimestre: los totales salen mal. Las preguntas sobre el campo de notas (“clientes que se quejan de demoras”) funcionan perfecto. No es un problema de embeddings: es usar un solo tipo de recuperación para datos de formas distintas.

La forma de los datos manda

Datos y consultas Recuperación que conviene
Tablas, con filtros exactos, rangos, conteos o sumas Consulta estructurada (structured query): una herramienta de solo lectura sobre vistas o la base
Texto libre, preguntas conceptuales (“quién puede rescindir sin causa”) Búsqueda semántica (semantic search)
Códigos, números de cláusula, términos definidos, IDs Búsqueda por palabras clave (keyword search), por ejemplo BM25
Las dos clases de consulta sobre el mismo corpus Búsqueda híbrida (hybrid search): ambas listas combinadas y después un reordenamiento (reranking)
Un documento chico, estable, con respuestas que cruzan secciones Sin recuperación: el documento entero en contexto

Algunas aclaraciones que el examen explota:

  • La similitud nunca es un filtro exacto. Ni un embedding mejor ni más resultados convierten “parecido” en “monto > 10.000 y estado = pendiente”. Para eso, una consulta de solo lectura (que además respeta los permisos de la base) y la búsqueda semántica queda para las notas.
  • “Cláusula 14.2” o “PROV-20417” son, para un embedding, temas parecidos a otras cláusulas. Sumar BM25 junto a la semántica arregla esas consultas sin perder las conceptuales; reemplazar todo por palabras clave rompe las que andaban.
  • No todo necesita RAG. Una política de 60 páginas que cambia dos veces por año entra entera y no pierde secciones; un archivo de medio millón de páginas que crece cada mes no entra en ninguna ventana y pide indexar y recuperar con cita. Unificar las dos funciones “por mantenimiento” es la trampa.

Precisión contra latencia: cada camino con su requisito

Más etapas de recuperación (más candidatos, reordenamiento, el modelo más capaz) suelen sumar precisión y también segundos. La decisión no es “lo más preciso en todos lados”: es lo que cumple el requisito de cada camino.

Un asistente que sugiere respuestas a operadores durante la llamada tarda seis segundos, casi todo en recuperar y reordenar. El reordenamiento suma cuatro puntos de precisión en la evaluación offline, pero los operadores ignoran las sugerencias que llegan después de dos segundos. Una sugerencia que llega tarde vale cero, por precisa que sea. En cambio, el resumen posterior a la llamada nadie lo lee hasta el día siguiente.

La configuración justificada: el camino en vivo con una recuperación más liviana y un modelo más rápido que cumplan los dos segundos; el resumen con el pipeline completo. El streaming no alcanza cuando la demora está antes de generar el primer token, y sacar la recuperación del todo pierde las respuestas basadas en las políticas.

Las trampas típicas

  • Búsqueda semántica sobre datos tabulares que piden filtros y sumas.
  • Cargar la tabla entera en el contexto para que el modelo filtre y sume.
  • Reemplazar la semántica por palabras clave en todo el sistema.
  • Pedirle al modelo que responda solo si ve el número de cláusula, sin arreglar la recuperación.
  • Fragmentar un documento chico que hoy funciona entero, para tener “una sola arquitectura”.
  • “La configuración más precisa en todos lados” aunque un camino tenga meta de latencia.

En el examen

Primero mirá qué consultas funcionan y cuáles no: esa diferencia te dice la forma de los datos. Filtros exactos sobre tablas piden consulta estructurada; códigos e IDs piden palabras clave o híbrida; texto conceptual sigue con semántica. Si una opción dice que la base ya ofrece BM25 o vistas de solo lectura, es una pista. En los escenarios de latencia, buscá la opción que separa los caminos y justifica cada configuración con su requisito.

Pregunta rápida

Una pregunta del simulacro sobre este dominio. Cuenta para tu progreso.

An insurer's RAG assistant answers staff questions from a 900-page underwriting manual. The manual was split into fixed 300-token chunks and embedded. Answers are often wrong in a specific way: retrieved chunks contain sentences like 'this limit does not apply in the cases listed above' with no indication of which limit or which cases, and coverage tables are cut in the middle of a row.

The team tried halving the chunk size and then raising the number of retrieved chunks to 50. Neither helped, and the second made answers slower and more expensive.

Which change to the chunking and indexing is most likely to fix the problem?

Practicá este dominio en el simulacro →