Métodos · Tema T3

Cómo se debe lograr que un LLM responda con los datos de la empresa y no invente

Revisado el 18 de octubre de 2026

Se imprime completa desde el navegador, en A4 o en carta.

Bloque 1

El problema

Lograr que el modelo responda con los datos de la empresa y no alucine, y medir que lo hace.

Síntesis en tres líneas

Al modelo no se le pide que recuerde: el conocimiento vive en contenido versionado que se indexa antes de la pregunta, y el modelo solo recibe los pocos fragmentos que la recuperación eligió, cada uno con su procedencia.
Los controles van en capas, los baratos primero —alcance, validación, recuperación, instrucciones—, y cada respuesta cita fuentes que navegan a algo visible, para que quien lee pueda comprobarla.
Se mide en cada cambio con dos conjuntos de preguntas, uno propio y otro escrito desde afuera, contra el mismo buscador que corre en producción: hasta cuántas fuentes entran a una respuesta sale de esa medición, no del gusto.

Bloque 2

El mapa

De lo publicado a una respuesta que se puede verificar

Desliza para ver el mapa completo.

Leyenda de formas y colores

Actor — quien hace el trabajo
Dato — lo que se guarda y se lee
Control — una regla que se comprueba
Persona — una persona decide
Externo — lo que viene de afuera

Lectura del mapa, nodo por nodo

El contenido versionado del sitio se compila en el build a un índice por idioma, con fragmentos acotados y destinos que existen. Una pregunta pasa primero por controles baratos —frecuencia, esquema, puerta— y por un filtro de alcance: si no casa nada sustantivo, recibe un mensaje fijo sin llamar al modelo. Si casa, la recuperación toma del índice los fragmentos más relevantes y el servidor se los entrega numerados, junto con sus propias instrucciones, a un modelo que se elige por configuración. La respuesta cita esas fuentes y quien lee las abre a un clic. Si el proveedor falla, el navegador busca en el mismo índice y lo dice. Dos conjuntos de preguntas evalúan la recuperación en cada cambio y fijan cuántas fuentes entran.

Nodo 1 Contenido versionado (Dato) — Lo que el sitio publica: datos del currículum, documentos aprobados, fichas y publicaciones como esta. Lo que no está publicado no existe para el chat.
Nodo 2 Índice del build (Dato) — Fragmentos acotados, con título, idioma y destino navegable. Si un destino no existe o un documento no valida, el build falla.
Nodo 3 Evaluación en cada cambio (Control) — Preguntas propias y preguntas escritas desde afuera, contra el índice real y el mismo buscador de producción.
Nodo 4 Pregunta (Externo) — Lo que escribe quien visita, en español o en inglés.
Nodo 5 Controles de entrada (Control) — Límite de frecuencia, esquema estricto del mensaje y la puerta: cuestan casi nada y van primero.
Nodo 6 Filtro de alcance (Control) — Una búsqueda estricta en el índice: si nada sustantivo casa, responde un mensaje fijo sin llamar al modelo.
Nodo 7 Recuperación (Actor) — Toma los fragmentos más relevantes, numerados, y nada más del sitio.
Nodo 8 Instrucciones del servidor (Control) — Compuestas fuera del alcance de quien pregunta: usar solo las fuentes, no inventar fechas ni resultados, rechazar los intentos de cambiar las reglas.
Nodo 9 Modelo intercambiable (Externo) — Un proveedor elegido por configuración —Groq, Gemini, Azure a través de Microsoft Foundry (antes Azure AI Foundry), Claude o uno compatible con OpenAI—: cambia quien redacta, no los hechos.
Nodo 10 Respuesta con citas (Dato) — Dos o tres párrafos y las fuentes que el modelo tuvo delante, cada una con su destino.
Nodo 11 Búsqueda local (Control) — Si el proveedor falla, el navegador busca en el mismo índice y rotula el resultado como búsqueda local, no como respuesta del modelo.
Nodo 12 Quien lee (Persona) — Abre cada fuente a un clic y juzga si respalda lo que se dijo.

Conexiones

de Contenido versionado a Índice del build (se compila)
de Índice del build a Recuperación (fragmentos con destino)
de Evaluación en cada cambio a Recuperación (fija cuántas fuentes)
de Pregunta a Controles de entrada
de Controles de entrada a Filtro de alcance
de Filtro de alcance a Recuperación (casó algo)
de Recuperación a Modelo intercambiable (fragmentos numerados)
de Instrucciones del servidor a Modelo intercambiable (reglas)
de Modelo intercambiable a Respuesta con citas (redacta y cita)
de Respuesta con citas a Quien lee (verifica)
de Modelo intercambiable a Búsqueda local (si falla)
de Búsqueda local a Quien lee (lo dice)

Bloque 3

Las fases

1
Fase 1
Decidir qué sabe el sistema
Entradas
- El contenido que la organización ya publica o aprueba.
- Quién puede ver cada cosa.
Actividades
- Listar las fuentes autorizadas y dejar fuera lo que no lo está.
- Dar a cada documento un estado: un borrador no se indexa.
- Escribir cada hecho con su fuente; lo que falta se pregunta, no se rellena.
Artefactos
- El corpus versionado, con estado por documento.
- La lista de fuentes autorizadas.
Quién decide
Quien es dueño del contenido.
Control que cierra la fase
Un documento en borrador no entra al índice; uno aprobado exige su gemelo en el otro idioma.
Estado del campo
Para los sistemas de recuperación, OWASP recomienda controles de acceso finos con almacenes que respeten los permisos, y canales robustos de validación para las fuentes de conocimiento.^[13]
2
Fase 2
Fragmentar e indexar por estructura
Entradas
- El corpus aprobado.
Actividades
- Cortar por la estructura del documento —la subsección—, con un tope de tamaño medido sobre el corpus real.
- Partir lo que pasa del tope en ventanas que conservan la misma ancla.
- Guardar con cada fragmento su título, su idioma y el destino visible al que lleva.
- Comprobar cada destino contra las rutas reales del sitio.
Artefactos
- Un índice por idioma, inspeccionable y regenerado en cada build.
Quién decide
Quien construye, con la medición al lado.
Control que cierra la fase
El build falla si un documento no valida, si un identificador se repite o si un destino no existe.
Evidencia
El tope de 180 palabras por fragmento se midió sobre el corpus real: la subsección típica tenía 143 palabras y la más larga 247, y con ese tope solo se parte el 4 % de las subsecciones.
3
Fase 3
Recuperar y medir cuántas fuentes entran
Entradas
- El índice.
- Un conjunto de preguntas con la fuente que cada una espera.
Actividades
- Elegir el tipo de búsqueda midiendo, no por costumbre.
- Fijar con el conjunto de preguntas cuántas fuentes entran y cuánto pesa cada tipo de fragmento.
- Separar dos modos: uno amplio para responder y uno estricto para decidir si se responde.
Artefactos
- La configuración de la búsqueda, versionada y con su medición al lado.
Quién decide
Quien construye, con los dos conjuntos de preguntas delante.
Control que cierra la fase
Ninguna pregunta del conjunto se queda sin su fuente entre las que entran.
Evidencia
Con tres fuentes por respuesta, seis preguntas del banco se quedaban sin la suya; con cuatro, ninguna, y con cinco el contexto crecía un 25 % sin rescatar a nadie: por eso entran cuatro.
4
Fase 4
Controlar antes y después del modelo
Entradas
- La pregunta.
- Los fragmentos recuperados.
Actividades
- Cortar lo ajeno antes de llamar al proveedor.
- Componer las instrucciones en el servidor, fuera del alcance de quien pregunta.
- Acotar la entrada, el historial y la salida con números, no con intenciones.
- Convertir cada fuente usada en una cita que navega.
- Degradar a búsqueda local, y decirlo, si el proveedor falla.
Artefactos
- Las defensas del servidor, en orden y cada una con su prueba de falla provocada.
Quién decide
Quien responde por el producto.
Control que cierra la fase
Cada control se ve fallar en la suite antes de darse por bueno.
Evidencia
En el servidor de este chat hay nueve defensas en orden; solo la última —el proveedor— tiene factura, y llega cuando las ocho anteriores ya hicieron su trabajo.
5
Fase 5
Evaluar la recuperación antes de publicar un cambio
Entradas
- El cambio: contenido, configuración o código.
- Los dos conjuntos de preguntas.
Actividades
- Correr las preguntas propias de cada documento y las escritas desde afuera contra el índice real, con el mismo módulo de búsqueda que usa producción.
- Comprobar que las preguntas ajenas se comportan como está declarado.
- Leer las respuestas de las preguntas propias: cada afirmación sostenida, nada ajeno al corpus.
- Tratar una palabra que el corpus no dice como un hallazgo de contenido, no de la prueba.
Artefactos
- El resultado de las dos suites en la integración continua.
- Un léxico obligatorio por documento.
Quién decide
Quien es dueño del contenido, con la integración continua delante.
Control que cierra la fase
Un cambio que deja una pregunta sin su fuente no se publica.
Evidencia
Cuando el banco descubrió que «ETL» y «lakehouse» no aparecían en los documentos del autor —que decían «integración de información»—, se corrigió el contenido, no la expectativa.
6
Fase 6
Operar, degradar y volver a medir
Entradas
- El chat publicado.
- El registro de cada respuesta.
Actividades
- Vigilar costo, latencia y modo de cada respuesta: modelo, mensaje fijo o búsqueda local.
- Volver a medir el umbral y cuántas fuentes entran cada vez que el corpus crece.
- Convertir cada pregunta mal contestada en una fila nueva del banco.
Artefactos
- Una fila por respuesta: fuentes, proveedor, tokens y milisegundos.
Quién decide
Quien paga la operación y quien es dueño del contenido.
Control que cierra la fase
Un techo de gasto escrito; si se acerca, se recorta contexto o extensión antes de cambiar de modelo.
Evidencia
Opera con un techo de US$20 al mes y un costo real observado de US$0: el uso cabe en la cuota gratuita del proveedor inicial y las preguntas ajenas no lo llaman.

Bloque 4

Las decisiones de diseño

Por qué el RAG no usa embeddings: léxica, vectorial o híbrida
Cuándo sí
Léxica, cuando el contenido está lleno de nombres, fechas, siglas y términos técnicos, y las preguntas de prueba no muestran paráfrasis perdidas.
Cuándo no
Cuando una familia de preguntas que el contenido no escribe con esas palabras —sinónimos, paráfrasis— se pierde de forma sistemática: ahí la vectorial o la híbrida pagan lo que cuestan.
Por qué
Estado del campo
Microsoft documenta que la búsqueda por palabras clave rinde mejor con códigos de producto, jerga muy especializada, fechas y nombres de personas, porque encuentra coincidencias exactas, mientras la vectorial encuentra lo conceptualmente parecido aunque no comparta palabras; la híbrida corre las dos en paralelo y funde los resultados.^[1]
Evidencia
El chat de este sitio busca con BM25, sin embeddings ni base vectorial, por una decisión escrita: entran el día que el banco muestre una familia de preguntas que la léxica pierde de forma sistemática, y hoy ninguna se queda sin su fuente entre las cuatro primeras.
Reordenar o no los resultados
Cuándo sí
Cuando la primera búsqueda trae lo correcto, pero no en los primeros puestos, y al contexto solo caben unos pocos fragmentos.
Cuándo no
Cuando lo correcto ya llega arriba en la medición: un reordenador suma latencia y costo en cada pregunta sin mover nada.
Por qué
Estado del campo
En Azure AI Search el ranker semántico reordena solo los 50 primeros resultados de la búsqueda léxica o híbrida, con modelos de lenguaje adaptados de Bing; no vuelve a buscar en todo el corpus, así que no rescata lo que la primera búsqueda no trajo.^[2]
Criterio
Antes de añadir un reordenador conviene mirar dónde cae la fuente correcta: si ya llega entre las primeras, el reordenador es gasto.
Cuántas fuentes entran a una respuesta
Cuándo sí
Más fuentes, cuando la medición muestra preguntas que se quedan sin la suya.
Cuándo no
Cuando subir el número ya no rescata ninguna pregunta: solo agranda el contexto, la factura y el ruido que el modelo tiene que ignorar.
Por qué
Estado del campo
Microsoft propone calibrar los parámetros de la búsqueda —el algoritmo, el top_k, el tamaño de los fragmentos— con un barrido: generar resultados con valores distintos y quedarse con los que dan la mejor calidad de recuperación, medida contra relevancias etiquetadas por personas.^[7]
Evidencia
En el chat de este sitio lo midieron dos conjuntos independientes, dos veces: con cuatro fuentes por respuesta, el golden set dio 75 de 75 y el banco 136 de 136; con cinco no se rescató ninguna más.
Qué hace el chat cuando la pregunta no es suya: el umbral de alcance
Cuándo sí
Un filtro antes del modelo, para las preguntas que no comparten una sola palabra sustantiva con el contenido: se responden sin gastar un token.
Cuándo no
Como garantía de corrección: si el umbral sube para bloquear más preguntas ajenas, empieza a rechazar las legítimas.
Por qué
Evidencia
Se midió y el hallazgo fue negativo: la pregunta legítima que peor puntúa da 5,92 y la ajena que mejor puntúa, 16,90; con el umbral en 7, diez legítimas recibían «eso se me escapa» a cambio de bloquear tres ajenas más. Por eso el umbral es 1 —«casó algo sustantivo»— y la corrección la garantiza el prompt.
Criterio
El peor fallo de un chat así no es gastar tokens en una pregunta ajena: es contestar «no sé» a una pregunta legítima.
Cómo evita el chat inventar respuestas: fuentes que se citan y se pueden abrir
Cuándo sí
Siempre: cada fuente que entra a la respuesta navega a una sección visible, y un destino roto detiene el build.
Cuándo no
No basta cuando la respuesta tiene consecuencias: ahí hace falta además comprobar por máquina que cada afirmación se apoya en la fuente que cita.
Por qué
Estado del campo
OWASP cuenta la desinformación entre los riesgos de las aplicaciones con LLM y recomienda, entre otras medidas, usar generación aumentada por recuperación para hacer más confiables las salidas, animar a quien usa el sistema a contrastarlas con fuentes confiables y validar automáticamente las salidas clave, sobre todo en entornos de alto riesgo.^[14]
Evidencia
En el chat de este sitio las fuentes que el modelo tuvo delante aparecen junto a la respuesta y cada una navega a su sección; a la fecha de revisión de esta publicación no existe un validador que compruebe que el modelo usó cada fuente en cada frase, y se dice así: esa relación la verifica quien lee.
Mandarlo todo en el contexto o recuperar: cuándo no usar RAG
Cuándo sí
Mandar el contenido entero cuando cabe holgado en la ventana del modelo y cambia poco: no hay índice que mantener.
Cuándo no
Cuando el contenido crece, cambia seguido o mezcla temas: con más texto delante el modelo rinde peor y cada pregunta cuesta más.
Por qué
Estado del campo
Anthropic dice que si la base de conocimiento tiene menos de 200.000 tokens —unas 500 páginas— se puede incluir entera en el prompt; Chroma midió 18 modelos y encontró que su rendimiento cae a medida que crece la entrada, aun en tareas simples.^[4]^[9]
Evidencia
Con cuatro fuentes de hasta 180 palabras, el contexto de una respuesta del chat de este sitio ronda las 540 palabras —del orden de 800 tokens—, aunque la base haya crecido de unas 30.000 a unas 158.000 palabras por idioma.
Caché de prompt sí; caché semántica, no en un chat de hechos
Cuándo sí
Caché de prompt, cuando muchas llamadas comparten el mismo comienzo —instrucciones, contexto fijo—: baja costo y latencia sin tocar la respuesta.
Cuándo no
Caché semántica, cuando la respuesta depende de hechos que cambian o de matices de la pregunta: devuelve la respuesta de otra pregunta parecida.
Por qué
Estado del campo
Microsoft documenta que la caché de prompt no cambia el contenido de la respuesta, solo reduce latencia y costo, y que exige un comienzo idéntico de al menos 1.024 tokens; de la caché semántica advierte que, como responde por parecido y no por coincidencia exacta, puede devolver respuestas incorrectas, desactualizadas o inseguras para la pregunta del momento.^[10]^[11]
Criterio
No conviene poner una caché semántica en un chat que responde por hechos sin un registro que muestre preguntas repetidas: devolver por parecido la respuesta de otra pregunta es una forma elegante de inventar.

Bloque 5

Lo innovador en 2026

Estado del campo
Búsqueda híbrida con reordenamiento semántico
Qué cambia frente a la práctica común
En vez de elegir entre palabras y significado, la búsqueda corre la léxica y la vectorial en paralelo, funde las dos listas por rango recíproco y un modelo de lenguaje reordena los primeros resultados. Microsoft documenta que, en pruebas con datos reales y de referencia, la híbrida con ranker semántico da beneficios significativos de relevancia.^[1]^[2]
Criterio
Si un día el banco muestra paráfrasis perdidas, este es el siguiente paso, no un reemplazo: la léxica seguiría ahí para los nombres y las siglas.
Estado del campo
Recuperación agéntica: la pregunta se planea antes de buscar
Qué cambia frente a la práctica común
Para preguntas con varias partes o que dependen de la conversación, un modelo las parte en subconsultas que corren en paralelo, cada una se reordena y el resultado se funde con referencias para citar. Microsoft advierte que agrega latencia frente a una sola consulta, y en Azure AI Search la planificación con modelo sigue en vista previa.^[3]
Criterio
Para preguntas cortas y directas, esa latencia solo se justifica si la medición muestra preguntas compuestas que se quedan sin su fuente.
Estado del campo
Contexto añadido a cada fragmento antes de indexarlo
Qué cambia frente a la práctica común
Un fragmento suelto pierde de qué documento y de qué sección viene. La recuperación contextual le antepone una explicación breve, generada a partir del documento entero, antes de los embeddings y del índice BM25: en las pruebas de Anthropic, los fallos de recuperación entre los 20 primeros fragmentos bajaron un 49 %, y un 67 % al sumar reordenamiento.^[4]
Evidencia
En el índice de este sitio cada fragmento conserva el título de su sección, el título pesa el doble que el cuerpo, y cada documento declara además cuándo usarlo: es contexto escrito a mano, sin un modelo de por medio.
Estado del campo
GraphRAG para preguntas sobre el conjunto entero
Qué cambia frente a la práctica común
La RAG vectorial rinde con preguntas locales —quién, qué, cuándo, dónde—; responder preguntas globales sobre todo un conjunto de datos es la ventaja de GraphRAG. Su variante LazyGraphRAG bajó el costo de indexar al de la RAG vectorial: el 0,1 % del de GraphRAG completo.^[5]
Criterio
Las preguntas de este sitio son locales —una empresa, una cifra, una decisión—; un grafo pagaría si se preguntara por patrones de toda la trayectoria y el banco mostrara que quedan sin respuesta.
Estado del campo
Citas ancladas a la frase exacta
Qué cambia frente a la práctica común
La API de citas de Anthropic parte los documentos en frases y devuelve, con la respuesta, las frases exactas que la sostienen; según sus evaluaciones internas, supera a la mayoría de las implementaciones propias, con hasta un 15 % más de exactitud de recuperación.^[6]
Evidencia
Las citas de este chat llegan a la sección, no a la frase: el destino está garantizado en cada build; la relación con cada frase, no.
Estado del campo
Evaluar la recuperación y la respuesta por separado, con un juez calibrado contra personas
Qué cambia frente a la práctica común
Microsoft separa la evaluación del proceso —si la recuperación trajo lo relevante, medido contra etiquetas humanas en el evaluador de recuperación de documentos o por un juez de modelo en el de recuperación— de la del sistema: si la respuesta se apoya en el contexto sin inventar, que es la precisión, y si no deja fuera lo esencial, que es la exhaustividad. Cuando el juez es un modelo, LangSmith propone calificar primero una muestra a mano y ajustar las instrucciones del juez hasta que coincida con esas notas.^[7]^[8]
Evidencia
En el chat de este sitio la recuperación se evalúa en cada cambio con dos conjuntos, contra el índice real y con el mismo módulo de búsqueda que corre en producción.
Estado del campo
El contexto largo no reemplaza la recuperación
Qué cambia frente a la práctica común
Las ventanas de contexto grandes invitan a mandarlo todo. Chroma midió 18 modelos y vio que el rendimiento cae al crecer la entrada, que un solo distractor ya lo baja y que importa cómo se presenta la información: elegir qué entra sigue siendo el trabajo.^[9]
Evidencia
El chat de este sitio le entrega al modelo solo los fragmentos recuperados, numerados, y no el contenido entero del sitio.
Estado del campo
Salidas que siguen un esquema exacto
Qué cambia frente a la práctica común
Las salidas estructuradas obligan al modelo a seguir el esquema JSON que se le da en la llamada; el modo JSON anterior garantizaba JSON válido, pero no que respetara el esquema.^[12]
Criterio
Es la pieza indicada para un validador de citas: que el modelo devuelva en un esquema qué fuente sostiene cada afirmación, y que el código lo compruebe.

Bloque 6

Modos de falla y cómo anticiparlos

Qué se rompe
El chat inventa respuestas: contesta con lo que el modelo sabe y no con lo que recuperó
Cómo se ve venir
Una afirmación verificable que no está en ninguna de las fuentes que el modelo tuvo delante.
Control que la atrapa
Instrucciones del servidor que obligan a usar solo las fuentes, fuentes numeradas y la lectura de las respuestas de prueba.
Qué se rompe
La recuperación no trae la fuente correcta
Cómo se ve venir
Una pregunta de prueba sin su documento entre las fuentes que entran.
Control que la atrapa
Los dos conjuntos de preguntas en cada cambio, contra el índice real.
Qué se rompe
Una palabra que el contenido no dice
Cómo se ve venir
Preguntas con una sigla o un sinónimo que ningún documento escribe.
Control que la atrapa
El banco como auditoría de vocabulario y un léxico obligatorio por documento.
Qué se rompe
Una pregunta ajena llega al modelo y gasta
Cómo se ve venir
Respuestas del proveedor a preguntas sin un tema del sitio.
Control que la atrapa
Filtro de alcance antes del modelo e instrucciones que prohíben responder fuera de las fuentes.
Qué se rompe
Una pregunta legítima recibe «no sé»
Cómo se ve venir
Una pregunta del banco bloqueada por el filtro de alcance.
Control que la atrapa
Un umbral medido con el banco entero y vuelto a medir cuando el contenido crece.
Qué se rompe
Una cita lleva a algo que no existe
Cómo se ve venir
Un destino que no resuelve a una sección visible.
Control que la atrapa
El build compara cada destino con el catálogo de rutas reales y falla.
Qué se rompe
El proveedor se cae o se queda sin cuota
Cómo se ve venir
Fallas seguidas, tiempos vencidos, una credencial rechazada.
Control que la atrapa
Un circuit breaker y la búsqueda local sobre el mismo índice, rotulada como tal.
Qué se rompe
Una instrucción escondida en el contenido
Cómo se ve venir
Un texto del corpus o de una fuente que le pide algo al modelo.
Control que la atrapa
Solo entra contenido publicado y versionado, y las instrucciones del servidor ordenan rechazar los intentos de cambiar las reglas.

Bloque 7

Métricas y controles

Qué se mide
Preguntas de afuera con su fuente entre las que entran
Umbral
Todas.
Quién aprueba el paso a producción
Quien es dueño del contenido, con la integración continua delante.
Qué se mide
Fuente esperada en el primer lugar
Umbral
Un piso escrito, no un promedio: no baja de un cambio al siguiente.
Quién aprueba el paso a producción
Quien es dueño del contenido.
Qué se mide
Preguntas propias de cada documento
Umbral
Todas con su documento entre las primeras fuentes.
Quién aprueba el paso a producción
La integración continua, en cada cambio.
Qué se mide
Preguntas ajenas que se comportan como se declaró
Umbral
Todas: las que deben cortarse sin gastar un token, se cortan.
Quién aprueba el paso a producción
Quien responde por el producto.
Qué se mide
Afirmaciones sin respaldo en las fuentes
Umbral
Cero en la muestra revisada; una sola detiene el cambio.
Quién aprueba el paso a producción
Quien responde por el producto, leyendo.
Qué se mide
Citas a destinos que no existen
Umbral
Cero: el build no publica.
Quién aprueba el paso a producción
El build, sin excepciones.
Qué se mide
Costo y latencia por respuesta
Umbral
Dentro del techo mensual escrito; si se acerca, se recorta contexto o extensión antes de cambiar de modelo.
Quién aprueba el paso a producción
Quien paga la operación.
Qué se mide
Servicio con el proveedor caído
Umbral
Quien pregunta sigue recibiendo fragmentos relevantes, rotulados como búsqueda local.
Quién aprueba el paso a producción
Quien responde por el producto.

Los umbrales son ejemplos del método, no cifras de un proyecto concreto.

Bloque 8

Evidencia en proyectos

EvidenciaNivel: Uso real
El chat de esta página
Se construyó y está en uso público desde julio de 2026: índice en el build, recuperación con BM25, nueve defensas en el servidor, citas que navegan a una sección visible y búsqueda local si el proveedor falla. Se puede abrir y probar.
Ver dónde
EvidenciaNivel: Uso real
El índice como puerta de calidad
Un script del build arma un índice por idioma con fragmentos de hasta 180 palabras, títulos y destinos; si un documento no valida su esquema, un identificador se repite o un destino no existe, el sitio no se publica.
Ver dónde
EvidenciaNivel: Uso real
Dos suites de preguntas en cada cambio
Cada documento declara las preguntas que debe contestar y la prueba exige su documento entre los cuatro primeros resultados; el banco, escrito como pregunta quien recluta, exige además la fuente esperada de primera en al menos el 60 % de los casos.
EvidenciaNivel: Uso real
Cuántas fuentes y cuánto pesa cada una, medido
Las cuatro fuentes por respuesta salieron de dos mediciones con dos conjuntos independientes —con cuatro, 75 de 75 y 136 de 136—, y el peso de 0,5 de las fichas del portafolio devolvió el banco de 94 a 102 aciertos de 131.
EvidenciaNivel: Uso real
La capa que adapta el proveedor, una variable de entorno
Una variable de entorno elige entre cinco proveedores adaptados e integrados sobre el Vercel AI SDK: Groq, el inicial, elegido en julio de 2026 —con gpt-oss-120b desde agosto, porque Groq retiró el modelo anterior—, Gemini 2.5 Flash, Azure a través de Microsoft Foundry, Claude con Haiku 4.5 y cualquier servicio compatible con la API de OpenAI. El índice y las defensas no cambian.
EvidenciaNivel: Uso real
La degradación, probada en una falla real
En el sprint 3 una credencial del proveedor devolvió un 401 en la integración, el circuito se abrió y la búsqueda local respondió sobre el mismo índice, diciendo que no era una respuesta del modelo.

Bloque 9

Límites y alcance

Evidencia
Embeddings y base vectorial no entran a este chat por una decisión escrita, no por desconocerlos: se comparó la búsqueda vectorial con la léxica, y entran el día que una medición lo justifique.
Evidencia
A la fecha de revisión de esta publicación no existe un validador que compruebe que el modelo usó cada fuente citada en cada frase: es trabajo futuro declarado.
Evidencia
Para la respuesta no hay un validador automático: las respuestas de prueba se revisan leyendo.
Evidencia
El chat no ajusta ni reentrena ningún modelo, y no es por no saber: el autor ajustó modelos en Microsoft Foundry, en varios prototipos propios. Un ajuste cambia cómo se comporta el modelo; lo que cambia en la trayectoria del autor cambia en la fuente y entra al índice en el siguiente build.
Evidencia
Con Microsoft Foundry, la experiencia es el adaptador de proveedor de este chat, esos ajustes y el estudio del AI-103, que está en curso; Azure AI Search se estudió a fondo en esa ruta.
Criterio
Lo que conviene hacer distinto hoy: un validador de citas desde el primer día —el modelo dice en un esquema qué fuente sostiene cada afirmación y el código lo comprueba— y un juez de la respuesta calibrado contra una muestra calificada a mano.
Criterio
Y no conviene empezar por la arquitectura más sofisticada: mejor empezar por un índice que se pueda abrir y un banco de preguntas escritas desde afuera; la búsqueda vectorial, el reordenador o el grafo entran cuando ese banco muestre qué falla.

Bloque 10

Fuentes y fecha de revisión

Revisado el 18 de octubre de 2026

[1]
Hybrid search using vectors and full-text search in Azure AI Search
Microsoft Learn · 31 de agosto de 2026
https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview
[2]
Semantic ranking in Azure AI Search
Microsoft Learn · 5 de agosto de 2026
https://learn.microsoft.com/en-us/azure/search/semantic-search-overview
[3]
Agentic retrieval in Azure AI Search
Microsoft Learn · 16 de septiembre de 2026
https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview
[4]
Introducing Contextual Retrieval
Anthropic · 19 de septiembre de 2024
https://www.anthropic.com/engineering/contextual-retrieval
[5]
LazyGraphRAG: Setting a new standard for quality and cost
Microsoft Research · 25 de noviembre de 2024
https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
[6]
Introducing Citations on the Anthropic API
Anthropic · 23 de junio de 2025
https://claude.com/blog/introducing-citations-api
[7]
Retrieval-Augmented Generation (RAG) evaluators
Microsoft Learn · 2 de junio de 2026
https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators
[8]
Introducing Align Evals: Streamlining LLM Application Evaluation
LangChain · 29 de julio de 2025
https://www.langchain.com/blog/introducing-align-evals
[9]
Context Rot: How Increasing Input Tokens Impacts LLM Performance
Chroma · 14 de julio de 2025
https://www.trychroma.com/research/context-rot
[10]
Prompt caching with Azure OpenAI in Microsoft Foundry Models
Microsoft Learn · 11 de agosto de 2026
https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching
[11]
Azure API Management policy reference: llm-semantic-cache-lookup
Microsoft Learn · 18 de agosto de 2026
https://learn.microsoft.com/en-us/azure/api-management/llm-semantic-cache-lookup-policy
[12]
How to use structured outputs with Azure OpenAI in Microsoft Foundry Models
Microsoft Learn · 24 de agosto de 2026
https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/structured-outputs
[13]
LLM08:2025 Vector and Embedding Weaknesses (OWASP Top 10 for LLM Applications 2025)
OWASP GenAI Security Project · 17 de noviembre de 2024
https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/
[14]
LLM09:2025 Misinformation (OWASP Top 10 for LLM Applications 2025)
OWASP GenAI Security Project · 17 de noviembre de 2024
https://genai.owasp.org/llmrisk/llm092025-misinformation/

Síntesis en tres líneas

De lo publicado a una respuesta que se puede verificar

Leyenda de formas y colores

Lectura del mapa, nodo por nodo

Conexiones

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Por qué el RAG no usa embeddings: léxica, vectorial o híbrida

Por qué

Reordenar o no los resultados

Por qué

Cuántas fuentes entran a una respuesta

Por qué

Qué hace el chat cuando la pregunta no es suya: el umbral de alcance

Por qué

Cómo evita el chat inventar respuestas: fuentes que se citan y se pueden abrir

Por qué

Mandarlo todo en el contexto o recuperar: cuándo no usar RAG

Por qué

Caché de prompt sí; caché semántica, no en un chat de hechos

Por qué

Búsqueda híbrida con reordenamiento semántico

Recuperación agéntica: la pregunta se planea antes de buscar

Contexto añadido a cada fragmento antes de indexarlo

GraphRAG para preguntas sobre el conjunto entero

Citas ancladas a la frase exacta

Evaluar la recuperación y la respuesta por separado, con un juez calibrado contra personas

El contexto largo no reemplaza la recuperación

Salidas que siguen un esquema exacto

El chat de esta página

El índice como puerta de calidad

Dos suites de preguntas en cada cambio

Cuántas fuentes y cuánto pesa cada una, medido

La capa que adapta el proveedor, una variable de entorno

La degradación, probada en una falla real