Reducción de las alucinaciones en un pipeline de chatbot médico RAG
Aprenda cómo la búsqueda híbrida, el reclasificado y una política estricta de prohibición de fabricar información falsa se combinan para crear un chatbot RAG de investigación médica más confiable.
El proyecto comenzó con un objetivo sencillo.
Se quería crear un chatbot capaz de responder preguntas basándose en artículos de investigación médica.
Eso debería ser lo suficientemente simple, ¿verdad?
Resultó no serlo.
La implementación inicial siguió un enfoque RAG bastante convencional: se procesaron los documentos, se generaron embeddings, se almacenaron en una base de datos vectorial, se recuperaron los fragmentos relevantes y se pasaron al LLM.
Funcionó.
Pero no de manera fiable.
Y en un contexto médico, “no ser fiable” es un defecto grave.
Un chatbot que responde con confianza pero de forma incorrecta es mucho más peligroso que uno que admite: “No tengo suficiente información para responder a esto.”
Esa constatación llevó al proceso de recuperación a una fase de perfeccionamiento continuo.
El primer problema: alucinaciones
El problema más urgente que había que abordar era la alucinación.
Los modelos de lenguaje son excepcionalmente buenos para generar respuestas que suenan convincentes, a veces demasiado convincentes.
Cuando los documentos no contenían la respuesta, el modelo solía llenar ese vacío con su propio conocimiento interno en lugar de admitir la incertidumbre.
Ese comportamiento necesitaba cambiar.
Las respuestas del chatbot tenían que provenir estrictamente del material de investigación proporcionado, y no de la imaginación del modelo.
Por eso, la filosofía subyacente cambió.
En lugar de tratar al LLM como una autoridad en hechos, los documentos recuperados se convirtieron en la verdadera fuente de verdad.
El papel del LLM se redujo a interpretar ese contexto recuperado y darle forma para obtener una respuesta coherente.
¿Y qué sucedía cuando el contexto no era suficiente?
El sistema debía negarse a adivinar.
Comenzando con RAG básico
La primera versión de la arquitectura parecía sencilla:
Esto representa el patrón estándar RAG.
Un documento grande se divide en fragmentos más pequeños, cada uno de los cuales se incrusta y almacena dentro de una base de datos vectorial.
Cada vez que un usuario envía una pregunta, esa pregunta también se incrusta.
Luego el sistema busca fragmentos cuyas incrustaciones sean semánticamente similares.
Simple, en teoría.
Pero rápidamente surgió un problema.
La similitud semántica no garantiza la relevancia real.
Por qué la búsqueda vectorial no era suficiente
Imagínese a un usuario que pregunta:
"¿Cuáles son los efectos de la resistencia a la insulina?"
La búsqueda semántica es buena para comprender la intención general detrás de esa pregunta.
Eso es útil.
No obstante, los textos médicos están repletos de terminología precisa.
Términos como:
- resistencia a la insulina
- HbA1c
- hiperglucemia
- metformina
- tolerancia a la glucosa
Estas palabras específicas tienen una gran importancia.
A veces lo que se necesita es comprender el significado general.
Otras veces se requiere que el sistema localice el término exacto.
¿Por qué conformarse con solo una capacidad?
La solución fue combinar ambas.
Búsqueda híbrida
Es aquí donde la búsqueda híbrida se convirtió en una parte esencial del diseño.
En lugar de depender únicamente de la recuperación basada en vectores, se combinó la búsqueda semántica con la búsqueda por palabras clave.
La lógica detrás de esto es bastante intuitiva.
La búsqueda semántica, en esencia, pregunta:
“¿Qué contenido tiene un significado similar?”
La búsqueda por palabras clave, en cambio, pregunta:
“¿Dónde aparecen realmente los términos clave?”
Cada método tiene sus propias ventajas.
Y cada uno también tiene sus puntos ciegos.
Juntos, abarcan una gama más amplia de consultas.
El flujo resultante se veía así:
User Query
↓
┌─────────┴─────────┐
↓ ↓
Vector Search Keyword Search
↓ ↓
└─────────┬─────────┘
↓
Combined Results
↓
Reranker
↓
Best Context
↓
LLM
↓
Answer
Esto cambió la forma en que se abordaba la recuperación de información a partir de entonces.
Siguió habiendo otro problema.
Recuperar algo no significa que sea lo mejor
Supongamos que el paso de búsqueda híbrida devuelve 20 fragmentos.
Eso suena prometedor.
Pero, ¿es realmente útil cada uno de esos fragmentos?
No necesariamente.
Algunos fragmentos podrían ser muy relevantes para el tema.
Otros podrían simplemente compartir un vocabulario similar.
Y otros aún podrían estar relacionados de forma tangencial sin responder a la pregunta real.
Suministrarlos todos directamente al LLM no es una solución ideal.
Más contexto recuperado no se traduce automáticamente en mejores respuestas.
De hecho, puede perjudicar el resultado.
Añade más tokens, más ruido irrelevante y más latencia.
Por eso se introdujo una etapa adicional.
Reclasificación.
Por qué la reclasificación marcó la diferencia
El papel del recuperador puede resumirse como:
Presentar posibles candidatos.
El papel del reclasificador es diferente:
Determinar cuáles de esos candidatos son realmente relevantes.
Así que en lugar de la simple cadena:
Query → Search → LLM
el proceso evolucionó a:
Query
↓
Hybrid Search
↓
20 Candidate Chunks
↓
Reranker
↓
Top Relevant Chunks
↓
LLM
Esa separación de responsabilidades es importante.
La primera etapa de recuperación puede priorizar la cantidad de resultados, extendiendo la búsqueda.
Luego, la etapa de reclasificación puede centrarse específicamente en la relevancia y la precisión.
Para un chatbot de investigación médica, esta distinción resultó especialmente valiosa, ya que un fragmento que solo contiene la terminología adecuada no siempre es el que realmente responde a la pregunta del usuario.
Lo más importante: negarse a fabricar respuestas
Más allá de la recuperación y el reordenamiento, se añadieron restricciones estrictas en la fase de generación.
La instrucción principal se resumía en lo siguiente:
Use the provided context to answer.
Do not invent information.If the context doesn't contain enough information,
say that there isn't enough information available.
Parece casi demasiado simple como para ser importante.
No obstante, modifica notablemente el comportamiento del chatbot.
En lugar de presionar al modelo para que genere una respuesta sin importar nada, este enfoque le brinda una salida cuando simplemente no hay información disponible.
Esa vía de escape resulta ser esencial.
A veces, la respuesta honesta es algo como:
“No pude encontrar suficiente información en el material de investigación proporcionado.”
No toda pregunta merece una respuesta segura.
¿Entonces se eliminan por completo las alucinaciones?
No del todo.
Esto quedó claro durante el proceso de desarrollo del sistema.
RAG realmente reduce las alucinaciones y mantiene las respuestas más vinculadas a fuentes reales.
Pero afirmar que no hay alucinaciones sería exagerado.
Aún quedan muchos puntos de fallo.
El recuperador podría extraer el fragmento incorrecto.
El propio proceso de segmentación podría eliminar contexto importante.
El reordenador podría clasificar mal los elementos.
Los documentos subyacentes podrían carecer de información desde un principio.
E incluso cuando todo funciona correctamente, el LLM aún puede interpretar mal lo que ha recuperado.
Así que el objetivo real no es:
“Crear un chatbot que nunca se equivoque.”
Está más cerca de:
“Construir un sistema con menos posibilidades de cometer errores, y uno que reconozca los límites de lo que realmente sabe.”
Ese es un objetivo mucho más alcanzable.
El diseño en bloques resultó ser crucial
Una conclusión destacada: dividir los documentos en bloques no es un paso de preprocesamiento temporal que se configura una sola vez.
Los bloques demasiado grandes incluyen contenido no relacionado.
Los bloques demasiado pequeños pueden eliminar el contexto circundante del cual depende una afirmación.
Es útil tratar cada bloque como una unidad de conocimiento autónoma en lugar de un fragmento arbitrario de texto.
Los bloques bien diseñados conducen directamente a una recuperación más eficaz de la información.
Y una recuperación más eficaz tiende a producir respuestas finales de mejor calidad.
Acelerar el proceso
La corrección era solo la mitad del desafío; el tiempo de respuesta era la otra.
Una sola solicitud RAG puede activar varias operaciones distintas:
User Query
↓
Embedding
↓
Vector Search
↓
Keyword Search
↓
Merge Results
↓
Reranking
↓
LLM
Ejecutar todas ellas estrictamente una tras otra ralentiza todo.
Para solucionarlo, los pasos de recuperación independientes se convirtieron en operaciones asíncronas siempre que fue posible.
El flujo revisado se veía más o menos así:
User Query
↓
┌──────┴──────┐
↓ ↓
Vector Search Keyword Search
↓ ↓
└──────┬──────┘
↓
Rerank
↓
LLM
Esto redujo el tiempo de espera inactivo entre pasos que en realidad no dependían unos de otros.
Solo la precisión no es suficiente para tener un buen sistema RAG.
Los usuarios no quieren quedarse esperando una respuesta eternamente.
La arquitectura resultante
Después de varias rondas de perfeccionamiento, el proceso finalizó con algo similar a esto:
Medical Research Documents
↓
Document Processing
↓
Chunking
↓
Embeddings
↓
Vector Database
↓
User Query
↓
┌──────────┴──────────┐
↓ ↓
Semantic Search Keyword Search
↓ ↓
└──────────┬──────────┘
↓
Result Fusion
↓
Reranker
↓
Relevant Context
↓
Grounded Prompt
↓
LLM
↓
Final Response
Cada componente en ese diagrama tiene una responsabilidad específica.
Esa separación se convirtió en una de las lecciones más valiosas del proyecto.
La base de datos vectorial no existe para responder preguntas.
El recuperador no está ahí para generar respuestas.
El LLM no tiene, por defecto, la capacidad de saberlo todo.
Cada componente se encarga de una tarea específica.
Y, idealmente, la realiza bien.
Lecciones del proceso de desarrollo
La principal conclusión de todo este ejercicio es que RAG es mucho más que simplemente combinar un LLM con una base de datos vectorial. Hay varios componentes interconectados, y cada uno merece atención.
La calidad de la recuperación es indispensable
Incluso el modelo de lenguaje más potente no puede compensar por un contexto deficiente. Si se le proporcionan resultados de recuperación de mala calidad, las respuestas que obtendrá también serán de mala calidad. Es un caso claro de “lo que se ingresa, eso se obtiene”.
La búsqueda híbrida demuestra su valor
La búsqueda semántica destaca por capturar el significado y la intención. La búsqueda por palabras clave es óptima cuando importa una terminología precisa. Dado que la investigación médica está llena de términos exactos y frases específicas, combinar ambos enfoques resultó ser la decisión correcta.
El reclasificado merece más reconocimiento
Obtener veinte resultados candidatos ya es un desafío. Reducirlos a los cinco mejores es otro desafío completamente distinto. El reclasificado se sitúa entre estos dos pasos y cierra la brecha.
Unos ventanales de contexto más amplios no garantizan respuestas mejores
Al principio se asumió que incluir más contenido recuperado mejoraría naturalmente los resultados. Esa suposición no se cumplió. En la práctica, cinco fragmentos altamente relevantes suelen superar en rendimiento a veinte de calidad mediocre.
Admitir la incertidumbre es una fortaleza, no una debilidad
Esta podría ser la lección más importante de todas. Un sistema fiable no debería sentirse obligado a dar una respuesta bajo ninguna circunstancia. Cuando la información relevante simplemente no está disponible, el sistema debería estar dispuesto a indicarlo.
Hacia dónde vamos a partir de aquí
Aún queda mucho espacio para mejoras. Las áreas que merecen ser exploradas a continuación incluyen:
- Métodos más sólidos de evaluación de la recuperación
- Reescritura de consultas
- Filtrado de metadatos
- Modelos de reclasificación mejorados
- Respuestas que incluyan citas
- Evaluación de confianza y lógica de abstención
- Mejor capacidad de observación del proceso de recuperación
- Conjuntos de datos para evaluación automatizada
- Más mejoras en el caché y la latencia
Construir un pipeline de evaluación adecuado es una prioridad especial, ya que revisar manualmente unos pocos resultados de un chatbot no constituye una forma rigurosa de juzgar la calidad. Las preguntas que merecen medición incluyen si se obtuvo la información correcta desde un principio, si la respuesta generada realmente se basa en ese material recuperado, y con qué frecuencia el sistema falla por completo al mostrar el contexto adecuado. Esas métricas son mucho más importantes que una percepción subjetiva de si una respuesta “suena correcta”.
Conclusión
Lo que comenzó como un chatbot RAG sencillo se convirtió en una lección mucho más profunda sobre cómo funcionan realmente los sistemas de recuperación de información. La conversación sobre aplicaciones de IA tiende a centrarse en el modelo de lenguaje, pero en una configuración RAG, es el pipeline de recuperación quien realiza la mayor parte del trabajo en segundo plano.
Una configuración mínima podría consistir en documentos que fluyen hacia una base de datos vectorial y luego hacia un LLM. Una versión más fiable implica que los documentos pasen por procesos de fragmentación, luego búsqueda híbrida, seguidos de un nuevo ordenamiento, para finalmente llegar como contexto fundamentado antes de llegar al LLM. Incluso ese flujo aún tiene espacio para evolucionar.
Eso es precisamente lo que hace tan atractivo el desarrollo de sistemas RAG: no se trata solo de hacer que un modelo de lenguaje genere texto, sino de asegurarse de que ese texto esté basado en la información adecuada antes de que el modelo hable.
Nota: este proyecto está destinado únicamente a fines de investigación y experimentación técnica. No sustituye el asesoramiento médico profesional, ni el diagnóstico ni el tratamiento.
Lecturas relacionadas
- Un mapa estratificado de conceptos de ingeniería de IA y cuándo son importantes — Aprenda qué conceptos de ingeniería de IA determinan si un sistema funciona en absoluto, cuáles son relevantes una vez que se desarrolla para producción y cuáles pueden esperar.
- Segundo cerebro: Convierte transcripciones de reuniones en un grafo de conocimiento interrogable — Explica cómo un sistema agente extrae entidades de las transcripciones de reuniones y las almacena en Cosmos DB para permitir la recuperación mediante lenguaje natural y la exploración del grafo de conocimiento.