No se puede recuperar un número que nadie anotó: OKF frente a una base de datos vectorial RAG.

Cada proyecto tiene un punto al que siempre vuelve, y ese punto es: compilar las figuras y recuperar el texto narrativo. Esa idea surgió de un chatbot que comenzó de la forma habitual. Una docena de documentos del CDC, incluyendo la descripción de la encuesta, el código de procedimientos, el informe resumido y los PDF de metodología, fueron cargados en una Base de Conocimientos Bedrock, con la esperanza de que un repositorio bien surtido proporcionara buenas respuestas.

Pero no fue así. La razón es el malentendido más común sobre la generación reforzada por recuperación de información: que más documentos significan respuestas más precisas. Una base de datos vectorial solo puede devolver texto que ya se encuentre dentro de ella. Para cualquier pregunta cuya respuesta nunca se haya escrito, el tamaño de la colección no tiene ninguna importancia.

Esos doce documentos describían en detalle las variables relacionadas con la diabetes: qué significaban, a quién se les preguntó y cómo se codificaban las respuestas. Ninguno contenía las estadísticas que un usuario realmente solicitaría. Esos números se calculan a partir de 29,522 filas de datos de la encuesta y no aparecen en ningún PDF, por lo que ninguna cantidad de búsquedas podrá encontrarlos.

Esto conduce a un error aún mayor. La gente asume que, una vez que un tema aparece en los documentos, RAG puede manejar cualquier pregunta al respecto. En realidad, solo puede manejar preguntas cuyas respuestas están escritas en un pasaje específico. Todo lo que requiere cálculos está fuera de su alcance.

Así que se reconstruyó el chatbot. Comenzó como una aplicación tutorial que combinaba Amazon Bedrock Flow, AWS Amplify Gen 2 y Next.js, y en la reconstrucción se sustituyó su motor de búsqueda por un paquete verificado en formato Open Knowledge Format (OKF). Para una comparación justa, también se creó una base de conocimientos real de Bedrock a partir de los mismos documentos, y ambas se probaron cara a cara en las únicas preguntas relevantes: ¿es correcta la respuesta? ¿Y con qué rapidez llega?

Al plantear la pregunta clave, la base de conocimientos identificó cinco variables relevantes y luego indicó con precisión la limitación: los documentos no incluyen las estadísticas realmente calculadas. Incluso recomendó el análisis adecuado, una proporción ponderada de personas con una marca que también poseen otra, que es precisamente lo que OKF ejecuta en el momento de la compilación, especificado correctamente por un sistema que no puede ejecutarlo. Se reduce a una frase: no se puede obtener un número que nadie anotó. El equipo de OKF respondió con una cifra calculada a partir de los microdatos bajo la definición de población correcta y las ponderaciones adecuadas.

Cómo se configuró la prueba

La configuración fue deliberadamente simétrica. Claude Sonnet 4.5 generó respuestas en ambos lados, en us-east-1, mediante un transporte SDK en proceso y con el mismo prompt del sistema que utiliza Lambda desplegado. El método se definió antes de que existieran resultados; se registran las siete preguntas y cada prueba, además de conservarse las respuestas en bruto. Una advertencia sobre los tiempos de respuesta: el sistema llama directamente a retrieval y a Bedrock, mientras que la aplicación en vivo enruta primero a través de AppSync y Lambda. El código OKF que se está probando es el código real de la aplicación, no el método de transporte; por lo tanto, los tiempos de respuesta comparan dos diseños medidos de la misma manera y no reflejan lo que vería un usuario en un navegador.

El cambio: un solo Lambda

El chatbot Amplify expone las herramientas como herramientas de datos Amplify, siendo cada una una instancia de Lambda detrás de una consulta GraphQL, y Bedrock Flow era una de ellas. Por lo tanto, el cambio consiste en una segunda herramienta, askOkf, que responde a partir de un paquete verificado en lugar de un Flow. El esquema, la interfaz de usuario y el despliegue permanecen igual.

// amplify/functions/askOkf/handler.ts — the essence
export const handler: Schema["askOkf"]["functionHandler"] = async (event) => {
   // in-process TF-IDF over the bundle
  const hits = search(event.arguments.question, 3);
  const top = hits[0];

  // Grounded-or-refuse: below the score floor,
  // nothing verified matches → refuse
  // before ever calling the model.
  if (!top || top.score < MIN_SCORE) {
    return { answer: refusal().text, citation: "", grounded: false, mode };
  }

  // read the verified figure straight from frontmatter
  if (mode === "extractive") {
    // 0 model calls - sub-millisecond
    const a = extractiveAnswer(hits);
    return { answer: a.text, citation: a.citations[0] ?? "", grounded: true, mode };
  }

  // generative: ground Claude on the ONE retrieved concept,
  // safety-prompted grounded-or-refuse
  const concept = top.concept;
  const context = `Concept: ${concept.label}\nSource: ${conceptSource(concept.frontmatter)}\n\n${concept.text}`;
  const response = await bedrock.send(
    new ConverseCommand({
      modelId: env.MODEL_ID,
      // grounded-or-refuse; declines medical-advice intent
      system: [{ text: SYSTEM_PROMPT }],
      messages: [{ role: "user", content: [{ text: `Verified concept:\n${context}\n\nQuestion: ${question}` }] }],
      inferenceConfig: { maxTokens: 400, temperature: 0 },
    })
  );
  const text = response.output?.message?.content?.[0]?.text ?? "";
  return { answer: `${text}\n\nSource: ${citation}`, grounded: true, mode };
};

Dentro del procesador, search() examina cuatro archivos de Markdown verificados que vienen incluidos con Lambda. No se utiliza ninguna base de datos vectorial, ningún servicio de embedding ni se realizan viajes de red. Solo se incluyen los conceptos que superaron la verificación, lo que significa que alguien realizó el análisis y comprobó el resultado. La cifra errónea y tentadora, la tasa de insulina de toda la muestra sin ponderación del 3,66%, no aparece en ninguno de ellos, por lo que nunca puede ser presentada.

Se envían dos rutas y el benchmark mide ambas. La ruta extractiva lee la cifra verificada del frontmatter sin realizar ninguna llamada al modelo. La ruta generativa realiza una llamada a Converse basada en datos reales.

La línea de referencia: un RAG vectorial real

El oponente tenía que ser fuerte. Se trata de una base de conocimientos gestionada en Bedrock sobre S3 Vectors que alberga el material real de CDC 2023 NHIS: la descripción de la encuesta, el código de muestra para adultos, los informes de resumen y metodología, la nota técnica de imputación y el README de pesos por pares. Un ingeniero competente construiría exactamente esto. Dado que el modelo es idéntico, la única variable que queda es de dónde proviene la respuesta: un almacén de vectores o un paquete verificado dentro de la función.

Se subieron trece archivos y diez fueron indexados. Las tres fallas ocurrieron con archivos .zip, que Bedrock rechaza, y resultaron ser los microdatos en formato bruto. Esto suena como una laguna que salva a la base de datos vectorial, pero no lo es. Cada documento que describe las variables relacionadas con la diabetes se indexó correctamente. Lo que falta son las filas en bruto, y de todas formas la recuperación de esas filas no podría generar estas cifras, ya que un porcentaje ponderado por encuestas entre 29,522 registros con un patrón de omisión es un cálculo y no un texto. No se puede llegar a él dividiéndolo en partes.

Otra observación sincera: la versión basada en vectores era la más económica. Una docena de documentos y una base de conocimientos se procesaron en cuestión de minutos. Por su parte, el método OKF requería trabajo real, como modelar conceptos y realizar análisis en los microdatos para verificar cada cifra. Confundir la rapidez de recuperación con la precisión resuelta es un error en sí mismo. Una solución barata y una corrección rigurosa son problemas separados, y la facilidad de uso es una razón para mantener la base de datos vectorial, no para eliminarla.

Corrección

El conjunto de preguntas incluía tres preguntas numéricas con respuestas verificadas, tres pruebas de rechazo y una pregunta sobre metodología. Las respuestas se evaluaron según una rúbrica establecida previamente: 30 intentos por cada pregunta numérica y dos por cada prueba, todos registrados. En las tres preguntas numéricas, el sistema RAG basado en vectores no logró producir la cifra verificada en ningún intento.

Latencia

En cuanto a las preguntas relacionadas con figuras que tienen 30 intentos cada una (donde los intentos 2 a 30 son pruebas de calentamiento), se informó que el método generativo OKF es de 1,4 a 2,4 veces más rápido, ya que omite el paso de recuperación a través de la red y funciona con un contexto mucho más reducido. El método extractivo es casi instantáneo, ya que no se llama a ningún modelo. Hay que considerar la amplitud de las diferencias y no el promedio: la brecha es mayor en el caso de la insulina, de aproximadamente 2,4 veces, y menor en el caso de la edad, de unos 1,4 veces, donde ambos métodos están casi empatados; por lo tanto, las filas correspondientes a cada pregunta representan el resultado real y no una sola razón general. De todos modos, la velocidad no es el factor decisivo. Los 3,3 a 3,7 segundos del banco de conocimientos son aceptables, y pierde en precisión, no en tiempo.

El hallazgo: recuperar versus compilar

En cada uno de los ensayos, el vector RAG no logró proporcionar ninguna de las cifras verificadas, y la mala ingeniería no es la explicación. Esas cifras simplemente no están presentes en los documentos. El 31,96% ponderado por la encuesta se deriva de los microdatos utilizando la población y los pesos correctos, pero no existe en ningún PDF. Un recuperador de información solo puede devolver texto ya existente. OKF puede responder porque la cifra se calculó y verificó con antelación, mientras que la base de conocimientos no tiene nada que recuperar.

Observe cómo falla la base de conocimientos: indica que no puede encontrar el porcentaje en los documentos y no inventa una cifra. Eso es honesto y refuerza el argumento. Incluso un vector RAG bien diseñado y construido estructuralmente es incapaz de responder a preguntas sobre estadísticas calculadas a partir de documentos.

Aquí surgen dos conceptos erróneos más.

• El anclaje en datos reales no garantiza la corrección. Esta base de conocimientos rechazó las solicitudes y no fabricó información, pero eso se debe a buenas prácticas por defecto y no es una característica inherente al RAG. Un modelo un poco más entusiasta, o un documento de resumen que por casualidad contuviera una frecuencia sin ponderación, podría proporcionar un número incorrecto con total confianza.
• Una cita no demuestra mucho. Un enlace a la fuente indica que se obtuvo un documento, pero no que la respuesta provenga de él. Una cita OKF es algo diferente, ya que menciona un valor calculado a partir de los datos y verificado en el momento de la compilación, y no texto encontrado junto a una oración similar.

Mejores instrucciones o más fragmentos de texto no solucionarán este problema. La solución es dejar de obtener estos números y dejar de compilarlos.

Límites y compromisos de OKF

OKF no es un motor de respuestas universal, y las pruebas de rendimiento muestran hasta dónde llega su capacidad.

Responde a "cuánto" y no a "por qué". En cuanto a la pregunta cualitativa de cómo la ponderación de las encuestas afecta la prevalencia, el vector RAG proporcionó una respuesta detallada y fundamentada extraída directamente de la descripción de la encuesta, mientras que el conjunto de cuatro conceptos OKF solo pudo ofrecer un número relacionado. Un conjunto de cifras verificadas es preciso en cuanto a las estadísticas calculadas pero no ofrece información narrativa. Eso es una limitación y no un defecto, y señala directamente a la arquitectura descrita a continuación.

Rápido significa sin juicios. La ruta extractiva responde en menos de un milisegundo, pero al solicitar consejo médico simplemente devuelve “31.96%”, porque no puede interpretar qué busca el usuario. La ruta generativa rechaza dar consejos y ofrece la cifra demográfica con una advertencia clara de que eso no dice nada sobre la situación de ningún individuo. Ese discernimiento cuesta una llamada al modelo, alrededor de dos segundos. Considere la respuesta instantánea y la ruta sensible a la intención como herramientas separadas e informe sobre ambas sin combinarlas.

El complemento: una tercera herramienta

Estos límites llevan a una conclusión. OKF proporciona la capa verificada, mientras que la base de datos vectorial es eficaz en la capa cualitativa y narrativa a la que OKF no puede acceder. Un diseño sensato utiliza ambas como herramientas distintas de las que el agente elige.

El agente basado en hechos ya utiliza dos herramientas con este propósito, ambas verificadas, en proceso y limitadas a datos agregados: una búsqueda de conceptos (search_okf) y una consulta de datos agregados con lista de permisos (analyze_rows). Cada una devuelve únicamente lo que puede confirmar. La base de conocimientos de Bedrock se convierte en la tercera herramienta, marcada claramente como narrativa no verificada. El agente luego ofrece una cifra verificada para preguntas numéricas, texto explicativo basado en hechos para las explicaciones y un rechazo cuando ninguna de las dos opciones es aplicable, manteniendo separadas esas tres opciones.

Esta división también representa el uso adecuado de los recursos. Minutos para la base de conocimientos, horas para el conjunto de datos verificados. Obtenga la narrativa de forma económica y reserve el trabajo más arduo únicamente para aquellos casos en que la cifra debe ser precisa: no compile lo que la recuperación le ofrece de forma gratuita, ni recupere lo que debe ser verificado.

Una vista previa de un resultado relacionado

Al incluir cuatro funciones en un mismo agente (verificación, cálculo, recuperación de datos y actualización en tiempo real), surge una pregunta natural: ¿un modelo más grande mantiene estos procesos organizados? Se mostró un titular de noticias falsificado con una estadística inventada a tres modelos, y los tres repitieron esa cifra en nueve de los nueve intentos, calificándola como una afirmación no verificada de un tercero. Cada vez, la cifra inventada sobre salud llegaba igualmente al lector. Solo una verificación de origen implementada en el código logró detenerlo en los nueve casos. El modelo elegido no supuso diferencia alguna en cuanto a seguridad.

Eso cambia la forma en que se debe interpretar esta prueba de rendimiento. Un conjunto de datos verificados proporciona la cifra correcta, lo cual ya representa la mitad del trabajo. La otra mitad consiste en evitar que la cifra incorrecta se difunda bajo la misma etiqueta, y eso depende del código y no del modelo.

Actualizado en tiempo real y revisado de forma independiente

Nada de esto se quedó en una laptop. askOkf se puso en funcionamiento en un entorno de pruebas real de Amplify (Cognito, AppSync, Lambda) y respondió con “Actualmente el 31.96% toma insulina” junto con su fuente, mientras rechazaba la pregunta sobre consejos médicos, bajo el rol IAM real. Antes de eso, una revisión de seguridad independiente analizó el contrato a partir del código fuente y determinó contract-satisfied: la consulta requiere autenticación, el permiso bedrock:InvokeModel tiene el nivel mínimo de privilegios y está restringido a un único modelo, no se puede inyectar nada, y cada solicitud está limitada a una sola llamada al modelo.

Una nota sobre los modelos: Bedrock acababa de marcar a Claude 3 Sonnet como obsoleto, por lo que tanto el Lambda de OKF como la prueba de rendimiento utilizan Claude Sonnet 4.5. Mantener el modelo idéntico en ambos lados es lo que hace que la comparación sea justa.

Conclusión

Una base de datos vectorial es la opción óptima y merece su lugar para preguntas abiertas y cualitativas. Una vez que el chatbot debe indicar una cifra, como una prevalencia, un KPI, un monto de ingresos o un umbral de cumplimiento, la recuperación de información no es el instrumento adecuado, ya que una versión fiable de dicha cifra ya fue calculada y nunca se registró en forma de texto. RAG o bien la omitirá, lo cual es honesto, o bien la inventará, lo cual no lo es. OKF calcula la cifra, la verifica contra la fuente al crearla y la envía: cuatro archivos en formato Markdown en una instancia de Lambda, sin necesidad de configuración adicional, y está disponible en cada prueba.

Los doce documentos no eran el problema; lo que faltaba era la cifra, y llenar aún más la base de datos nunca permitiría obtenerla. Calcule sus propias cifras.

Leer más

• Cómo funciona RAG: Embeddings, bases de datos vectoriales y chunking: Sigue un fragmento de texto desde su tokenización, pasando por el proceso de agrupamiento, hasta la búsqueda por similitud coseno, y comprende por qué el chunking y los modelos de embeddings determinan la calidad de RAG.
• El significado como coordenadas: De los embeddings a las bases de datos vectoriales y RAG: Una explicación sencilla sobre los embeddings de oraciones, la similitud coseno, las bases de datos vectoriales y el ciclo de RAG, con cuatro oraciones cortas sobre perros, gatos y París que ilustran cómo funciona la búsqueda por significado.