RAG · PRODUCCIÓN · CONFIANZA
La demo responde.
El sistema explica por qué.
Después de trabajar en productos documentales con AI y de construir uno en público, dejé de pensar RAG como “buscar chunks y llamar a un modelo”. En producción, el trabajo difícil es preservar una cadena de evidencia mientras cambian los documentos, los permisos, los modelos y las condiciones de falla.
01 / LA DISTANCIA A PRODUCCIÓN
El happy path ocupa
una sola flecha.
Subir un PDF, partirlo, generar embeddings y obtener una respuesta es una prueba de integración. No prueba que el producto pueda sostener confianza.
La primera versión de casi todos los diagramas de RAG cabe en una línea: documento → chunks → índice → prompt → respuesta. La primera versión de casi todos los incidentes vive en lo que ese diagrama omite: un PDF escaneado sin texto, un reintento que duplica contenido, permisos que cambiaron, una nueva versión del embedding, un proveedor lento o una respuesta fluida construida sobre evidencia mediocre.
En mi experiencia, el modelo rara vez es la parte que más diseño necesita. El producto se vuelve serio cuando cada etapa tiene un contrato, un estado visible y una forma de fallar sin mentir. Eso cambia la conversación de “¿qué vector database usamos?” a “¿qué afirmación podemos defender?”.
DATA PLANE · ASÍ SE VUELVE BUSCABLE
- 01FUENTE
- 02VALIDAR
- 03EXTRAER
- 04CHUNKEAR
- 05INDEXAR
QUERY PLANE · ASÍ SE VUELVE RESPUESTA
- 06IDENTIDAD
- 07BUSCAR
- 08RANKEAR
- 09GENERAR
- 10VERIFICAR
La UI no debería ocultar esta máquina. Debería traducirla: procesando, listo, evidencia insuficiente, acceso denegado, proveedor no disponible y reintento seguro son estados de producto, no detalles internos.
02 / INGESTA
La calidad de respuesta
empieza antes del índice.
Retrieval no puede recuperar estructura que la ingesta destruyó. El pipeline documental es parte del modelo de calidad.
Identidad estable
Hash del archivo, versión de la fuente y versión del pipeline. Un retry debe continuar o reemplazar de forma deliberada, nunca crear una segunda verdad por accidente.
Extracción verificable
Texto, página, título, sección, tablas y offsets deben conservar suficiente provenance para volver al original. OCR y parsing fallan de maneras distintas; “terminó” no significa “extrajo bien”.
Estados explícitos
stored, extracting, extracted, indexing, indexed y failed dicen qué trabajo ocurrió y qué se puede reintentar. Un booleano ready borra información justo cuando más hace falta.
Reindexado reproducible
El índice es una proyección reconstruible. Guardá qué parser, reglas de chunking y embedding produjeron cada entrada, y hacé posible un rebuild sin perder el documento fuente.
ALGO QUE CAMBIÓ MI FORMA DE DISEÑARLOAntes pensaba el chunk como la unidad principal. Hoy pienso primero en la evidencia que una persona necesita abrir: documento, versión, página, sección y pasaje. El chunk es una optimización de retrieval; no debería convertirse en la identidad del conocimiento.
03 / RETRIEVAL
Medí el buscador
antes de culpar al modelo.
Una respuesta final mala mezcla, como mínimo, errores de búsqueda y errores de síntesis. Si solo puntuás el texto final, no sabés qué sistema corregir.
¿La evidencia correcta apareció?
Es el primer gate. Si el pasaje útil no llega al contexto, ningún prompt lo puede recuperar.
¿Apareció suficientemente arriba?
El orden importa cuando el presupuesto de contexto es chico y el modelo presta atención de forma desigual.
¿Cuánto ruido enviamos?
Más chunks pueden subir recall y, al mismo tiempo, diluir evidencia, aumentar tokens y empeorar la respuesta.
¿Detectamos cuando no alcanza?
El sistema también necesita casos sin respuesta. Recuperar algo no significa haber recuperado evidencia suficiente.
Mi orden de implementación
- 1Set de preguntas versionado
Preguntas reales, documento esperado, pasaje relevante y casos que deberían abstenerse.
- 2Baseline lexical
BM25 o full-text search: barato, explicable y excelente para nombres, códigos, fechas y términos exactos.
- 3Análisis de errores
Separar sinónimos, mala extracción, chunks rotos, filtros incorrectos y contenido ausente.
- 4Semántica o híbrido
Agregar vectores, expansión de query o reranking solo donde el set demuestra una brecha.
En mi proyecto público empecé con FTS5/BM25 y thresholds de Recall@3 y MRR@3 en CI. No porque lexical sea universalmente superior, sino porque una base simple y medible convierte “necesitamos embeddings” en una hipótesis comprobable.
04 / GENERACIÓN Y CITAS
El modelo redacta.
El servidor responde.
Grounding no es pegar fuentes debajo de un texto. Es limitar qué puede afirmar el sistema y hacer que cada referencia resuelva a evidencia que realmente estuvo en ese request.
- 01
EVIDENCIA LOCAL AL REQUEST
Asigná IDs opacos a los pasajes recuperados. El modelo puede citar esos IDs, no inventar nombres de archivo, páginas o URLs.
- 02
OUTPUT ESTRUCTURADO
Validá respuesta, citas y estado de abstención contra un schema. Un parse exitoso no prueba verdad, pero elimina estados ambiguos.
- 03
CITAS RESUELTAS POR SERVIDOR
Convertí cada ID válido en documento, versión, página, offsets y enlace. Rechazá IDs desconocidos en vez de mostrarlos.
- 04
ABSTENCIÓN COMO ÉXITO
Si la evidencia no cubre la pregunta, “no encontré respaldo suficiente” es un resultado correcto. Forzar texto es una falla de producto.
La distinción que más me sirve es simple: el modelo propone una composición; la aplicación decide qué evidencia existe, qué usuario puede verla y qué estructura acepta.
05 / SEGURIDAD
El índice también es
una frontera de autorización.
RAG puede filtrar información a usuarios que jamás podrían abrir la fuente. El prompt no es un control de acceso.
Autorizá antes de rankear
Aplicá tenant, ACL, clasificación y vigencia dentro de la consulta. Recuperar todo y filtrar después ya expuso datos al pipeline y deforma el ranking.
Sincronizá permisos
La autorización del índice es una réplica de la fuente. Medí su lag, procesá revocaciones y definí qué pasa mientras una ACL está desactualizada.
Tratá el contenido como no confiable
Un documento puede contener instrucciones para el modelo. Delimitá datos e instrucciones, reducí capacidades y nunca permitas que contexto recuperado otorgue permisos o habilite herramientas.
Minimizá telemetry sensible
Queries, chunks, prompts y respuestas pueden contener PII o secretos. Logs útiles no implican almacenar el contenido completo; preferí IDs, hashes, conteos y muestreo controlado.
Prompt injection no se resuelve con otra frase en el system prompt. Se contiene con arquitectura: mínimo privilegio, separación entre instrucciones y datos, validación de salida y ninguna acción sensible sin una autorización determinística fuera del modelo.
06 / OPERACIÓN
Diseñá para el día
en que una etapa falle.
Un request RAG cruza storage, búsqueda y un proveedor probabilístico. Latencia, costo y disponibilidad se componen; los retries ciegos también.
Un archivo parcial nunca aparece como fuente válida.
Se preserva el archivo; no se reinicia todo el flujo.
La respuesta puede declarar su corte de conocimiento.
No se llama al modelo para fabricar confianza.
El usuario recibe un estado honesto y el trabajo no queda huérfano.
Nunca se envía una forma inesperada al cliente.
Ingesta, OCR, embeddings masivos y reindexado pertenecen a jobs durables cuando superan el presupuesto HTTP. Eso exige idempotencia, backpressure, dead-letter handling y progreso persistido. Hacerlo async no elimina estados: los vuelve inevitables.
07 / OBSERVABILIDAD
Una latencia total
no explica nada.
Instrumentá la cadena como etapas conectadas y separá salud operativa de calidad. Un sistema puede estar rápido y contestar mal.
documentos por estado · bytes · páginas · tiempo de extracción · errores por parser
latencia · top-k · filtros · scores · cero resultados · versión de índice
modelo snapshot · tokens · TTFT · latencia · finish reason · costo estimado
citas abiertas · abstenciones · feedback · reformulaciones · tarea completada
request_idcorpus_versionretriever_versionprompt_versionmodel_snapshotevidence_idsoutcomeNo hace falta loguear el contenido para poder reconstruir una decisión. Hace falta correlación y versionado. El contenido sensible se captura solo bajo una política explícita de retención y acceso.
08 / RELEASE GATE
Lo que reviso
antes de llamarlo producción.
La checklist no garantiza calidad; evita confundir una integración funcional con un sistema operable.
- 01
¿Cada documento tiene identidad, versión, checksum y estado de procesamiento?
- 02
¿Puedo reconstruir el índice desde la fuente sin perder provenance?
- 03
¿Existe un set de evaluación con positivos, negativos y preguntas sin respuesta?
- 04
¿Retrieval y generación tienen métricas y gates separados?
- 05
¿Las citas se resuelven desde evidencia server-side del mismo request?
- 06
¿La autorización se aplica durante retrieval y refleja revocaciones?
- 07
¿Cada etapa tiene timeout, retry acotado, idempotencia y estado de falla visible?
- 08
¿Puedo atribuir latencia, tokens y costo por request y por tenant?
- 09
¿Modelo, prompt, parser, chunking, embeddings e índice están versionados?
- 10
¿El producto sabe abstenerse sin tratarlo como un error técnico?
LA IDEA EN UNA LÍNEA
No construyas un chatbot
sobre documentos.
Construí una cadena de evidencia que pueda ingerir, autorizar, recuperar, medir y explicar documentos. Después dejá que un modelo redacte sobre esa cadena. Ese orden produce menos magia en la demo y mucha más confianza cuando el sistema importa.
09 / PARA PROFUNDIZAR
Fuentes y
trabajo verificable.
- 01Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksPaper original de RAG · Lewis et al. ↗
- 02RAG in Azure AI SearchPipeline, chunking, retrieval híbrido y citas · Microsoft ↗
- 03Evaluation best practicesTests estructurados para sistemas variables · OpenAI ↗
- 04Document-level access controlAutorización por documento durante retrieval · Microsoft ↗
- 05LLM01: Prompt InjectionRiesgos de prompt injection · OWASP ↗
- 06AI Knowledge PlatformCódigo, ADRs, evals y decisiones mencionadas en este artículo →