3 · El contrato de recuperación
A mitad del primer libro apareció el manifiesto de datos, y con él una regla que acabó gobernando todo el corpus: si no está en el manifiesto, no existe. Un documento sin línea en ese inventario no se ingiere, no se valida, no se mantiene; es, a efectos del sistema, exactamente nada. Esa regla parecía una burocracia hasta que evitó el primer desastre: la tarde que alguien pretendió ingerir un lote de PDFs "solo de prueba" que duplicaba convenios con versiones distintas. No existía, y no entró.
Este capítulo traslada la misma idea al otro lado del mostrador. Si el manifiesto fue el pacto sobre lo que entra en el corpus, el acceso necesita su pacto sobre lo que sale: qué dominios se consultan, con qué garantías, qué puede devolverse, cuánto contexto se entrega, qué calidad se promete. Lo llamamos el contrato de recuperación, y es el documento más subestimado de la ingeniería RAG: no acelera nada, no calcula nada, y sin él cada discusión posterior —sobre filtros, sobre top-k, sobre métricas— se convierte en una pelea de opiniones.
Qué es un contrato de recuperación
Un contrato de recuperación es un documento corto —unas dos páginas— donde el equipo declara, antes de afinar nada, las reglas del juego del acceso. Su autoría es tan importante como su contenido: no lo escribe el que programa, lo negocian los que responden y los que preguntan. En el despacho, lo redactamos a tres bandas: el arquitecto de datos, un usuario y quien gestiona la relación con los clientes. Tardó una tarde. Ahorró un trimestre.
Un contrato completo responde, al menos, a estas preguntas. Alcance: qué dominios del corpus atiende este acceso y cuáles quedan fuera de su jurisdicción; en un sistema multi-dominio, el asistente de consultoría laboral no debe contestar sobre fiscalidad aunque los documentos estén en el mismo Rack. Unidad y límites de la entrega: cuántas píldoras se entregan como máximo, con qué presupuesto de contexto, y qué garantía de integridad tienen —nunca una píldora descapitada, nunca una tabla cortada. Vigencia: qué compromiso de frescura se asume; en derecho, devolver la redacción derogada de un artículo es peor que devolver nada, y el contrato debe decirlo en estas palabras. Permisos: qué documentos pueden llegar a manos de quién, y la regla de oro de que lo confidencial no se penaliza, no se degrada: no se muestra. Trazabilidad: toda afirmación del sistema debe poder remontarse a su píldora y su fuente; una respuesta sin cita rompe el contrato aunque el texto sea correcto. Y calidad: los objetivos numéricos —los que el capítulo dieciocho convertirá en métricas— expresados como promesa ante los usuarios, no como capricho del equipo.
Nada de esto es tecnología. Todo esto condiciona la tecnología: el alcance decide los filtros de dominio, la vigencia obliga a un filtro sobre metadatos de estado, los permisos exigen la capa del capítulo nueve, la trazabilidad determina qué guarda el ensamblado del capítulo diecisiete y la calidad fija los umbrales que el diecinueve vigilará. El contrato es el mapa del que cuelgan, una a una, las piezas del resto del libro. Por eso ocupa este lugar: se escribe antes de elegir un solo motor.
Por qué funciona: la política contra la opinión
Un equipo sin contrato decide cada parámetro dos veces: una al implementarlo y otra cada vez que alguien discute su valor. ¿Top cinco o top ocho? Cada sesión lo vuelve a plantear, y gana quien insiste más. Con el contrato, el parámetro se decide una vez, por escrito, con un porqué, y las discusiones cambian de naturaleza: no se discute el número, se discute si cambió la realidad que lo justificaba. Es la diferencia entre política y opinión: la política se revisa con procedimiento, la opinión se revisa a gritos.
El contrato también protege al equipo de sí mismo en el momento más peligroso de cualquier sistema de acceso: el de la optimización local. Alguien descubre que subiendo el top-k a veinte mejora la métrica interna del capítulo dieciocho, y lo sube. Nadie miraba que el presupuesto de contexto se duplica, que el coste por consulta se dispara y que la respuesta gana ruido; la métrica sube, el sistema empeora. Con contrato, ese movimiento es visible como lo que es —un cambio de política que hay que justificar— y pasa por la revisión de los que firmaron. En sistemas que contestan sobre derechos de trabajadores, esa travesía controlada no es pedantería: es deber profesional.
Y hay una tercera virtud, menos evidente: el contrato convierte al usuario en parte del sistema. Cuando el usuario indica que toda respuesta debe llevar cita a artículo y sentencia, deja de ser una queja puntual cuando falta —pasa a ser una incidencia de cumplimiento—. Cuando solicita que la vigencia es sagrada, el filtro de estado deja de ser una coartada técnica y se convierte en una promesa auditable. Los buenos sistemas de acceso tienen usuarios con deberes; los malos, usuarios desamparados.
Cómo se escribe: brevedad, ejemplo, revisión
La tentación al redactar un contrato es hacerlo largo. Resístase. Un contrato de diez páginas no se lee, y lo que no se lee no obliga. Dos páginas bastan si cada cláusula nace de un caso real: no "las respuestas deben ser trazables", sino "toda afirmación llevará cita que permita abrir la fuente original; caso de origen: la respuesta del despido objetivo sin cita del 14 de marzo". Ese patrón —cláusula con caso fundacional— cumple dos funciones: obliga a que cada regla tenga un motivo contable y crea el registro histórico que explica, meses después, por qué el sistema es como es. El apéndice A trae la plantilla completa con las cláusulas que sobrevivieron al contacto con la realidad.
Una cláusula merece mención aparte porque casi nadie la escribe y todos la echan de menos: la del vacío. El contrato debe decir qué pasa cuando el corpus no sabe: que el sistema responderá "no encuentro respuesta en el corpus" en lugar de improvisar, y que eso se considera un acierto del contrato y un defecto del corpus a registrar. El capítulo diez desarrolla el diseño del vacío; el contrato lo declara como política desde el primer día, y con eso desarma de entrada la pregunta que hunde más demos: "¿y si no lo sabe?".
Por último, el contrato lleva fecha y revisión, como todo lo vivo del sistema. Cuando cambie —y cambiará: aparecen tipos nuevos de consulta, suben los presupuestos de contexto, entran dominios— se revisa como se revisó el manifiesto del corpus: con quién lo pide, qué caso lo provoca y qué piezas técnicas arrastran el cambio. Un contrato que nunca cambia ya no describe el sistema; lo caricaturiza.
Criterio de salida
Un contrato de recuperación de dos páginas, firmado por técnica y negocio, que fija alcance, límites de entrega, vigencia, permisos, trazabilidad, objetivos de calidad y política del vacío — cada cláusula con su caso fundacional. Es el documento contra el que se juzgará cada decisión del resto del libro.
El contrato promete coordenadas: vigencia, permisos, dominios. Ahora hace falta saber dónde viven esas coordenadas. La respuesta corta es: en los metadatos. La respuesta larga —por qué los metadatos son el verdadero territorio de la búsqueda— es el próximo capítulo.