Recuperación de información
Ahora tenemos tres niveles informacionales.
La organización puede poseer un conjunto amplio de knowledge.
Ese conocimiento se encuentra distribuido en resources concretos.
Para cada ejecución el modelo recibe solamente un context.
La pregunta inevitable es:
¿cómo elegimos qué entra?
Supongamos que una organización dispone de:
5.000 contratos
20.000 anexos
300 políticas y estándares
15.000 aprobaciones
40.000 correos relevantesEl modelo no necesita recibir todo para responder una pregunta sobre una cláusula.
Necesita encontrar la información que resulte pertinente.
Ése es el problema de la recuperación de información.
Recuperar información significa transformar un universo amplio de recursos en una selección de información pertinente para una necesidad concreta.
En esta página estudiaremos cuatro operaciones:
buscar documentos → seleccionar fragmentos → incorporarlos al contexto → conservar evidencia.
La recuperación es un problema más antiguo que los modelos generativos. La informática jurídica lleva décadas trabajando sobre clasificación, indexación y legal information retrieval. Los LLM no eliminan ese problema. Lo vuelven especialmente visible porque la calidad de una respuesta puede depender directamente de qué información fue recuperada antes de generarla.
Buscar documentos
Comencemos con la operación más intuitiva.
El abogado necesita saber:
¿Cuál es el estándar vigente sobre limitación de responsabilidad para proveedores SaaS críticos?
Una primera búsqueda podría utilizar:
limitación de responsabilidad SaaS críticoLa finalidad es obtener candidatos.
Todavía no estamos generando una respuesta final.
La consulta y el documento pueden usar palabras distintas
Supongamos que el estándar utiliza:
tope agregado de responsabilidadmientras el usuario escribe:
cap contractualUna búsqueda exclusivamente literal podría perder el documento.
Por eso existen distintas estrategias de recuperación.
Búsqueda léxica
Busca términos, palabras o expresiones relacionadas con la consulta.
La intuición es:
“encuentra documentos que contengan esto”Puede ser muy eficaz cuando la terminología es precisa.
En Derecho es especialmente útil porque existen conceptos técnicos, las citas importan y las palabras exactas pueden ser materialmente relevantes.
Búsqueda semántica
Intenta recuperar contenido relacionado por significado aunque no exista coincidencia exacta de palabras.
La intuición es:
“encuentra documentos que traten de esto”Puede ayudar cuando:
consulta:
tope de responsabilidady el documento dice:
maximum aggregate liabilityBúsqueda híbrida
Combina señales léxicas y semánticas.
Chip Huyen señala precisamente que sistemas de producción suelen combinar algoritmos de recuperación porque cada uno tiene fortalezas distintas.
La lección para esta página no es elegir un algoritmo universal.
Es comprender que buscar no es una operación única.
Filtrar antes de buscar
En trabajo jurídico no todo depende del contenido textual.
Podemos tener metadatos:
tipo = política
estado = vigente
unidad = corporativa
materia = contrataciónUn filtro puede excluir:
borradores
versiones derogadas
documentos de otra unidad
precedentes no aprobadosantes o durante la búsqueda.
Esto puede ser tan importante como la similitud semántica.
Un ejemplo
La consulta:
cap responsabilidadencuentra:
Estándar v4
Estándar v3
Contrato ACME
Borrador comité 2025
Presentación internaTodos contienen palabras similares.
El filtro:
tipo = estándar
estado = vigentereduce el universo.
Buscar bien requiere combinar significado con gobernanza.
La pregunta del usuario no siempre es la consulta de recuperación
El usuario puede preguntar:
“¿Podemos aprobar esta cláusula?”
Esa frase no contiene necesariamente los términos que debe utilizar la búsqueda.
La aplicación puede necesitar descomponerla:
estándar cap responsabilidad SaaS
precedentes cap inferior
matriz aprobación desviaciones
carve-outs confidencialidadEsta transformación de una necesidad profesional en consultas de información es una parte importante del diseño.
No toda consulta debe ser generada por un modelo.
Puede estar predeterminada por la skill.
Puede construirse a partir de metadatos.
Puede combinar ambas cosas.
Lo importante es distinguir:
pregunta profesional
≠
consulta de búsquedaSeleccionar fragmentos
Encontrar el documento correcto tampoco significa que debamos introducirlo completo.
Imagine:
Manual de contratación tecnológica
180 páginasLa regla necesaria se encuentra en dos párrafos.
Si el sistema envía las 180 páginas cada vez, consume contexto, añade ruido, aumenta costo, puede mezclar reglas de otros casos y dificulta identificar evidencia.
Por eso una segunda operación consiste en seleccionar fragmentos.
¿Qué es un fragmento?
Un fragmento es una unidad del resource suficientemente pequeña para ser recuperada y utilizada.
Puede corresponder a:
- párrafo;
- sección;
- cláusula;
- artículo;
- conjunto de párrafos;
- unidad semántica.
En inglés suele hablarse de chunks.
Fragmentar no es inocuo
Considere:
14.1 La responsabilidad total no excederá doce meses de fees.y:
14.2 El límite anterior no aplicará a fraude, dolo
ni incumplimiento de confidencialidad.Si el sistema recupera solamente 14.1, la regla queda incompleta.
El fragmento contiene una proposición verdadera.
No contiene el régimen completo.
Por eso la selección debe conservar suficiente contexto para interpretar correctamente.
Estructura jurídica como señal
Los documentos jurídicos ya poseen estructura.
Podemos utilizar artículos, secciones, cláusulas, subcláusulas, anexos o considerandos como unidades potenciales.
No existe una regla universal.
Una cláusula puede ser demasiado grande.
Un párrafo puede ser demasiado pequeño.
La pregunta correcta es:
¿qué unidad conserva el significado necesario para esta tarea?
Chip Huyen enfatiza que no existe un tamaño universal óptimo y que fragmentos pequeños pueden perder información importante, mientras fragmentos mayores consumen más contexto.
Seleccionar candidatos
Una búsqueda puede devolver:
100 fragmentospero el modelo quizá sólo necesita:
5Por eso podemos distinguir:
buscar
↓
obtener candidatos
↓
ordenar / filtrar
↓
seleccionarSistemas más sofisticados pueden utilizar una etapa de reranking: una primera búsqueda obtiene candidatos y otro mecanismo los reordena para escoger los más pertinentes.
No necesitamos implementar reranking para entender su función.
La idea es:
el primer resultado de búsqueda no tiene por qué ser la selección final de contexto.
Relevancia y cobertura
Existe una tensión recurrente.
Si seleccionamos demasiado poco, podemos omitir algo importante.
Si seleccionamos demasiado, introducimos ruido.
La disciplina de information retrieval utiliza conceptos como precision y recall para describir dimensiones relacionadas.
Podemos entenderlos sin fórmulas.
Problema de cobertura
El sistema encuentra:
regla generalpero omite:
anexo con excepción decisivaTenemos información relevante que quedó fuera.
Problema de precisión
El sistema recupera:
regla general
anexo correcto
40 contratos irrelevantes
3 políticas de otra unidadEncontró lo importante, pero lo rodeó de ruido.
Una buena recuperación debe equilibrar ambos problemas.
Incorporar los fragmentos al contexto
Una vez seleccionados los fragmentos, debemos entregarlos al modelo junto con la tarea.
Supongamos que tenemos:
cláusula nueva
fragmento del estándar
fragmento de matriz de aprobación
precedente comparableEl context podría organizarse así:
[TAREA]
Evaluar desviación de responsabilidad.
[CONTRATO]
Cláusula 14.2 ...
[ESTÁNDAR]
Estándar v4 §8.4 ...
[APROBACIÓN]
Matriz v3 ...
[PRECEDENTE]
ACME 2025 ...La operación importante es que aquello que antes existía fuera de la ejecución ahora está disponible dentro del contexto.
Más contexto no siempre es mejor
Berryman y Ziegler advierten un problema especialmente útil: fragmentos irrelevantes pueden inducir al modelo a sobreinterpretarlos simplemente porque fueron incluidos.
La selección de contexto no es neutral.
Si incorporamos un precedente que no es comparable, el modelo puede intentar utilizarlo.
Si incluimos una política derogada, puede mezclarla con la vigente.
Si agregamos demasiadas fuentes, la relación entre pregunta y evidencia puede hacerse menos clara.
Por eso:
cantidad de contexto
≠
calidad de contextoCitar evidencia
Recuperar información es sólo una parte del trabajo.
En aplicaciones jurídicas necesitamos conservar la procedencia.
Supongamos que el output dice:
“El estándar exige doce meses.”
Una persona debería poder volver a:
Estándar v4
§8.4
fragmento exactoLa evidencia puede representarse mediante:
documento: "Estándar de contratación tecnológica"
version: "4.0"
seccion: "8.4"
texto: "..."
estado: "vigente"El formato es ilustrativo.
La función es permitir trazabilidad.
Fuente, evidencia e inferencia
Una buena salida debería distinguir:
FUENTE
qué resource se utilizó
EVIDENCIA
qué fragmento relevante contiene
INFERENCIA
qué concluimos a partir de élPor ejemplo:
Fuente:
Estándar v4.
Evidencia:
“Cap mínimo = 12 meses.”
Inferencia:
La cláusula propuesta de 3 meses se aparta del estándar.La inferencia no está literalmente escrita en la política.
Es resultado de comparar dos piezas.
Esta distinción evita presentar razonamiento como cita.
Citar no significa demostrar automáticamente
Una referencia real puede no respaldar la afirmación.
Ejemplo:
Afirmación:
“Confidencialidad está fuera del cap.”
Cita:
§14.Si §14 no contiene esa excepción, la referencia existe pero no demuestra el punto.
Por eso una skill de verificación puede necesitar comprobar:
¿la evidencia citada respalda realmente la afirmación?No basta con exigir una columna llamada “fuente”.
Recuperación jurídica: relevancia no es autoridad
Un algoritmo puede considerar altamente relevante un contrato anterior.
Pero ese contrato puede representar:
una excepcióny no:
el estándar vigenteLa recuperación responde principalmente:
¿qué contenido parece pertinente?
La evaluación jurídica debe añadir:
¿qué estatus tiene?
Esta separación explica por qué la gobernanza de knowledge es inseparable del retrieval.
Un ejemplo completo
Pregunta:
¿El cap de tres meses cumple el estándar para este proveedor?
Resources:
Estándar_v4.pdf
Estándar_v3.pdf
ACME_2025.pdf
Acta_ACME.pdf
Matriz_Aprobaciones.xlsxBúsqueda
limitación responsabilidad SaaS críticoFiltrado
estándar vigenteSelección
Estándar v4 §8.4
Matriz §3.2
ACME §15
Acta ACME §4Context
cláusula actual
+
fragmentos anterioresEvidencia
Cada fragmento mantiene documento, versión, sección y estatus.
Todavía no hemos explicado el patrón completo de generación que utiliza estos fragmentos.
Ese será RAG.
Recuperación no es RAG
Esta frontera es importante.
Podemos recuperar información sin utilizar un modelo generativo.
Un buscador jurídico clásico ya recupera documentos.
Un sistema documental puede devolver cláusulas relevantes.
RAG aparece cuando conectamos:
recuperación
+
generaciónLa recuperación es el R.
La página siguiente estudia la arquitectura completa.
Qué debes recordar
Recuperar información consiste en seleccionar desde un universo amplio aquello que importa para una tarea.
El proceso puede incluir:
consulta
→ búsqueda
→ candidatos
→ selección
→ fragmentos
→ contextoLa búsqueda puede utilizar señales léxicas, semánticas o híbridas.
Los metadatos pueden ser decisivos para vigencia y aplicabilidad.
La fragmentación debe preservar contexto suficiente.
Más documentos no significan mejor respuesta.
Y una cita útil debe permitir volver desde la afirmación a la evidencia y al resource correspondiente.
El problema que todavía queda abierto
Ahora sabemos recuperar información y llevarla al contexto.
El siguiente paso es combinar ese mecanismo con generación.
Cuando el sistema busca primero información pertinente y luego genera una respuesta utilizando aquello recuperado, aparece el patrón conocido como:
Retrieval-Augmented Generation — RAG.