RAG es para encontrar. El contexto completo es para decidir..

El consejo de 2026 está asentado: trocea tus documentos, genera embeddings, recupera los top-k y pásaselos al modelo. No malgastes contexto. No malgastes tokens.

Construí un sistema que, a propósito, no hace nada de eso. Cada consulta recibe el CV entero del experto: 69 proyectos, publicaciones, formación, idiomas. Unos 34.000 caracteres, completos, cada vez.

Esta es la lógica, porque no fue pereza.

La tarea decide la arquitectura

El sistema busca licitaciones de la ONU para un experto concreto. Cada día rastrea 28 fuentes, normaliza y deduplica miles de anuncios de contratación y luego responde a una pregunta por licitación: ¿encaja esta persona?

Parece retrieval. No lo es. Es exclusión.

• Retrieval pregunta: ¿qué hay en este corpus más parecido a la consulta?
• Exclusión pregunta: ¿hay algo aquí que lo descalifique?

Son operaciones opuestas. La primera quiere las coincidencias más fuertes. La segunda necesita el eslabón más débil, y por definición el eslabón más débil es lo menos parecido a todo lo demás.

Por qué la similitud habría fallado

Un patrón real de los datos.

Una licitación se titula Public Financial Management. El experto tiene una docena de proyectos de finanzas públicas. La similitud del coseno entre licitación y perfil: muy alta.

# what a RAG pipeline does here
chunks = retrieve(query=tender.description, corpus=cv_chunks, k=3)
# returns: finance_project_2019, finance_project_2021, education_economics
# verdict: strong match

La licitación es para un responsable ambiental. Lo dice una vez, en la página cinco, en el apartado de responsabilidades.

O: el puesto encaja a la perfección, pero exige un consultor nacional con un idioma local obligatorio. Una frase, enterrada en los requisitos de elegibilidad.

El detalle descalificador nunca es el pasaje semánticamente más cercano. Eso es justo lo que lo hace descalificador: es la parte que no encaja en el patrón. Un sistema de retrieval está optimizado para no sacarlo a la luz.

Lo que destruye el troceado

Trocea un CV y conservas los hechos pero pierdes la forma.

Recupera tres fragmentos sobre finanzas públicas y el modelo ve a un experto en finanzas públicas. Envía los 69 proyectos y el modelo ve en qué países ha trabajado de verdad, qué idiomas tiene de verdad, a qué nivel de seniority opera y, sobre todo, qué nunca ha hecho.

La ausencia es información. Y la ausencia no se puede recuperar. No hay ningún fragmento que diga «esta persona no tiene experiencia ambiental». Solo lo aprendes leyéndolo todo y notando que no hay nada de eso.

RAG puede decirte qué hay en un documento. No puede decirte qué no hay.

La economía que me dijeron que temiera

34.000 caracteres son unos 9.000 tokens de contexto por juicio. Multiplícalo por cientos de licitaciones al día y se supone que es el error caro.

No lo es. La IA y los proxies juntos funcionan por unos pocos dólares al mes.

Dos razones:

1. El prefiltro hace el trabajo barato primero. Palabras vacías, tema, territorio, idioma, plazo, caducado: todo en código, sin llamadas al modelo. La IA solo ve candidatos que sobrevivieron a las reglas.

# rules run first, model runs last
candidates = [t for t in tenders if passes_rules(t)]   # cheap
verdicts   = [judge_with_full_cv(t) for t in candidates] # expensive, but few

2. El CV es idéntico byte a byte en cada llamada. El mismo prefijo, una y otra vez: la forma ideal para el prompt caching.

El panel registra el coste por ejecución y el coste por licitación encontrada, así que no es una suposición. Vigilo el número.

La lección generalizable: el coste de los tokens es una restricción real, pero es una que la gente aplica de memoria en lugar de medirla. Los precios cambiaron. La mayoría de los pipelines RAG que veo se diseñaron para una economía que ya no existe.

Lo que devuelve el modelo

No prosa. Un veredicto estructurado, registrado por completo:

{
  "fits": false,
  "short_reason": "requires national consultant, local language mandatory",
  "long_reason": "The role matches the expert's PFM background, but eligibility restricts applicants to nationals with working Portuguese...",
  "country": "Mozambique",
  "tor_attached": true
}

Juzga la sustancia del puesto, no su título. Ese es todo el objetivo.

Cuándo sí usaría RAG, y lo hago

Esto no es un argumento contra RAG. Es un argumento contra usarlo por defecto.

RAG es lo correcto cuando:

• el corpus es ilimitado: una base de conocimiento que crece sin fin, documentación, historial de soporte
• la latencia importa
• la tarea es genuinamente retrieval: encontrar el pasaje, responder a partir de él

Uso RAG en otros proyectos por exactamente esas razones. Otra tarea, otra forma, otra respuesta.

La advertencia honesta por mi parte: el contexto largo tampoco está libre de problemas. Los modelos atienden con menos fiabilidad a la mitad de un prompt largo que a su principio y su final. 34k caracteres caben cómodamente en lo que los modelos actuales manejan bien. En 300k tendría otra conversación, y probablemente estaría construyendo un híbrido.

La regla a la que llegué

Pregunta qué tiene que hacer el modelo con el documento.

• Encontrar algo → retrieval. El corpus puede ser enorme, y encontrar es en lo que los embeddings son buenos.
• Juzgar algo → dale todo. El juicio necesita la imagen completa, incluidas las partes que no son relevantes, porque la irrelevancia es la mitad del veredicto.

La mayoría de las tareas de negocio en las que la gente enchufa RAG son tareas de juicio disfrazadas de retrieval. ¿Encaja este candidato? ¿Es arriesgado este contrato? ¿Deberíamos presentarnos a esto? En cada una de ellas, lo que decide la respuesta es el detalle que nadie habría recuperado.

Lecturas relacionadas

• El sistema de licitaciones completo: 28 fuentes, 17 conectores, parsers que se autorreparan
• IA y automatización