Diez errores de recuperación silenciosa en RAG en producción, y cómo se soluciona cada uno de ellos.
Desde el tamaño de los bloques y la superposición hasta la búsqueda híbrida, RRF, el reclasificado, la elección de embeddings y las evaluaciones de CI: diez errores de recuperación detrás de respuestas incorrectas en RAG y sus soluciones.
Un chatbot de soporte explicó una vez, con una prosa encantadora, la incorrecta política de reembolso. El sistema recuperó un párrafo en el que se utilizaba la palabra “reembolso” cuatro veces. Era temáticamente relevante y describía una línea de productos descontinuada. El modelo de lenguaje hizo lo que se le indicó: responder con confianza basándose en el contexto proporcionado. Nadie le había dicho que el contexto era incorrecto.
Ese es el patrón de la mayoría de los fallos en los sistemas RAG que terminan en sesiones de depuración. Un equipo pasa dos semanas cambiando el modelo, reescribiendo el prompt del sistema y añadiendo en negrita “solo responder con base en el contexto”, pero la tasa de alucinaciones apenas cambia. El problema nunca estuvo en la generación de texto; el modelo razonó correctamente a partir de evidencias que ya eran erróneas desde un principio.
Diez errores específicos dañan la calidad de la recuperación en los sistemas RAG en producción. Suelen manifestarse en una secuencia fija: primero los errores de fragmentación, ya que ocurren antes que todo lo demás; luego el diseño de la recuperación; seguidamente la elección del proceso de reclasificación y las representaciones vectoriales; y finalmente la brecha en las mediciones que impide detectarlos. Cada sección a continuación explica por qué ocurre el error, cuál es su costo y qué se debe cambiar, y donde los estudios son contradictorios, se indica abiertamente dicha contradicción.
Por qué la recuperación es el punto en el que fallan los sistemas RAG
Los informes de los especialistas sobre el RAG en producción durante 2026 siguen arrojando el mismo diagnóstico: la mayoría de las respuestas erróneas se deben a la fase de recuperación de información. Regresan documentos incorrectos, se pasan por alto los correctos, o ocupan un lugar demasiado bajo en la clasificación como para ser utilizados. Una estimación común es de alrededor del 70% o más. Esa cifra varía según el informe y el dominio, por lo que solo sirve como guía aproximada, pero fuentes independientes coinciden en la tendencia. Cuando un sistema RAG comete un error, la explicación más probable es que al modelo LLM nunca se le mostraron las pruebas adecuadas, por lo que el primer paso es examinar qué devolvió el sistema de recuperación antes de editar la instrucción.
Los diez errores se agrupan en cuatro categorías según la etapa del proceso. Los números del 1 al 4 afectan lo que se introduce en el almacén de vectores. Los números del 5 al 7 se refieren a la arquitectura de recuperación. Los números 8 y 9 corresponden a la fase de clasificación y embeidamiento. El número 10 se refiere al hecho de que nada de esto se mide.
Términos utilizados a continuación
- Chunking se refiere a dividir los documentos de origen en fragmentos antes de indexarlos. Tanto los modelos de incrustación como las ventanas de contexto funcionan mejor con unidades cortas y específicas que con archivos completos.
- Recuperación densa (búsqueda vectorial) coloca las consultas y los fragmentos en un mismo espacio de incrustación y devuelve los vecinos más cercanos. Es eficaz para la paráfrasis, pero menos útil para cadenas de texto literales.
- Recuperación dispersa, como BM25, clasifica los fragmentos según las palabras en común con la consulta, dando mayor importancia a las palabras poco frecuentes. Los códigos, nombres y jerga coinciden bien, pero los sinónimos no.
- Búsqueda híbrida ejecuta ambos métodos de recuperación de forma simultánea y fusiona las dos listas ordenadas, generalmente mediante Fusión de rangos recíprocos (RRF). RRF utiliza las posiciones de rango en lugar de las puntuaciones brutas, lo que soluciona el problema de que los valores de BM25 y las similitudes coseno no son comparables.
- Reranking vuelve a calificar una lista corta de candidatos, generalmente de 20 a 100 elementos, mediante un codificador cruzado que procesa conjuntamente la consulta y el texto en lugar de analizarlos por separado. El resultado es un orden mucho más preciso antes de que los k mejores elementos sean enviados al LLM.
Cuatro errores en el particionamiento
1. Usar un particionamiento de tamaño fijo como predeterminado sin probar otros
Los tutoriales suelen comenzar dividiendo cada documento en ventanas de 500 tokens, independientemente de su contenido. Esto lleva cinco minutos, funciona lo suficientemente bien para demostraciones, y los equipos lo implementan sin volver a revisarlo.
Los estudios difieren al respecto, y decirlo es más útil que fingir consenso. Varias comparaciones realizadas en 2026 favorecen la división de tokens fija o recursiva sobre el fragmentación semántica. En una gran prueba de rendimiento que evaluó numerosas estrategias, ganó la división recursiva de 512 tokens, en parte porque la fragmentación semántica producía fragmentos de solo 43 tokens en promedio, demasiado pequeños para contener contexto. Otros estudios en distintos campos indican lo contrario: una evaluación revisada por pares de sistemas de soporte para la toma de decisiones clínicas reportó una precisión del 87% con la fragmentación adaptativa al tema, frente al 50% con un método de referencia fijo (p = 0.001). Una tercera comparación reveló que un tamaño fijo bien ajustado podía igualar o superar a la división semántica en conjuntos de datos reales, en línea con los pasajes de 100 palabras fijos utilizados en el artículo original sobre RAG.
Ninguna estrategia funciona en todas las situaciones. Lo que todos los autores coinciden en señalar es que el error radica en no elegir una división de tamaño fijo, sino en seleccionar cualquier estrategia sin probar primero una alternativa en el corpus real.
La respuesta práctica es medir en lugar de teorizar. Reúna de 20 a 50 pares representativos de preguntas y respuestas, indexe el mismo corpus bajo dos o tres estrategias candidatas y compare el recall@5 con la precisión contextual. El contenido con estructura incorporada, como las documentaciones de API, los documentos legales y los informes financieros, suele rendir mejor si se divide primero siguiendo esa estructura, ya que esas unidades son coherentes por sí mismas:
from langchain_text_splitters import RecursiveCharacterTextSplitter
# Recursive splitting respects structure first, falls back to
# character boundaries only when a section is still too large.
splitter = RecursiveCharacterTextSplitter(
chunk_size=512, # tokens, not characters, if you swap in a token-aware splitter
chunk_overlap=75, # ~15% overlap, a reasonable starting point
separators=["\n## ", "\n### ", "\n\n", "\n", ". ", " "],
)
chunks = splitter.split_text(document_text)
2. Un tamaño de bloque para cada tipo de documento
Se elige un tamaño una sola vez, de forma preliminar, basándose en una regla práctica, y luego se aplica a una colección mixta. Las referencias de API, los documentos de políticas extensos y las transcripciones de chat reciben todos el mismo tamaño de bloque.
Los bloques de tamaño excesivo diluyen la señal de relevancia. Un bloque de 2,000 tokens que abarca cinco temas genera un vector que es un promedio difuso de los cinco temas y no coincide bien con ninguno de ellos. Los bloques de tamaño insuficiente pierden el contexto que necesita un lector, como una firma de función sin sus notas de parámetros o una cláusula sin la sección que modifica.
El tamaño debe ajustarse a la densidad del contenido. La documentación técnica suele contener entre 256 y 512 tokens, lo que permite mantener enfocados los conceptos individuales. Los textos narrativos o normativos, por lo general, necesitan de 1,024 a 2,048 tokens para conservar el contexto circundante. Estos son puntos de partida para validar, ya que la cifra adecuada depende del modelo de embedding y de la forma en que los usuarios formulan sus preguntas.
3. Olvidar la superposición
La superposición se establece una vez y se olvida, o se omite porque se considera que desperdicia espacio de almacenamiento. Sin ella, una oración que cruza el límite entre bloques se divide en dos. Un bloque termina con la introducción y el siguiente comienza con la conclusión, y ninguno de ellos puede recuperarse como un pensamiento completo. Este es un motivo común y totalmente evitable para las quejas de que la respuesta está en algún lugar pero el modelo no puede encontrarla.
Un solapamiento del 10 al 20 % del tamaño del bloque es un valor por defecto razonable: de 50 a 100 tokens para un bloque de 500 tokens, lo cual es económico en comparación con los fallos que evita. Más no siempre es mejor. Un solapamiento mucho mayor generalmente solo aumenta el almacenamiento y genera ruido; además, al menos un análisis sistemático de 2026 realizado con la recuperación SPLADE no encontró beneficio medible del solapamiento en ese entorno. El conjunto óptimo debería ser el que resuelva el problema, no el valor por defecto.
4. Ignorar la estructura propia del documento
Tratar cada archivo como un único bloque es más sencillo, ya sea que se trate de una referencia de API en Markdown, un contrato con cláusulas numeradas o un informe financiero repleto de tablas; sin embargo, la división sin considerar la estructura suele separar un encabezado de su sección correspondiente o una tabla del párrafo que la explica. La víctima típica es la descripción de una función separada de su lista de parámetros, por lo que una consulta sobre dicha función solo devuelve la mitad de la respuesta.
La solución es dividir primero por la estructura, siguiendo encabezados, secciones, listas y tablas, y utilizar la división basada en el tamaño únicamente dentro de las secciones que siguen siendo demasiado grandes. A mediados de 2026, la mayoría de los pipelines de fragmentación de producción son híbridos por esta razón: estructura primero, división semántica dentro de segmentos largos no estructurados, tamaño fijo como último recurso, y sin imponer un único método a un corpus mixto.
Tres errores en la arquitectura de recuperación
5. Utilizar únicamente la búsqueda vectorial
Las plantillas iniciales usan por defecto la búsqueda vectorial. Se trata de una sola llamada a la API, y parece excelente en una demostración donde las consultas de prueba son paráfrasis conversacionales, exactamente lo que mejor hacen los embeddings densos.
El tráfico real difiere del tráfico de demostración. Los usuarios ingresan códigos de productos, cadenas de errores, nombres de indicadores, números de ticket y nombres propios, que son tokens literales cortos. Los modelos densos entrenados para agrupar significados tienden a confundirlos con elementos relacionados pero incorrectos. Los estudios de referencia demuestran repetidamente esta brecha: una configuración híbrida ajustada superó a cada método por separado en una prueba de clasificación de comercio electrónico, y un estudio práctico mostró que el sistema basado únicamente en vectores obtenía un rendimiento menor en la recuperación@10 en comparación con un sistema híbrido adecuadamente fusionado, principalmente debido a la omisión de identificadores exactos. Las cifras varían según los corpus, pero la tendencia se mantiene en todos los lugares donde se ha probado. Cada vez que las consultas combinan estilos conversacionales y de coincidencia exacta, lo cual ocurre casi siempre, el enfoque híbrido gana.
El cambio consiste en agregar un índice BM25 o SPLADE junto al índice vectorial. Weaviate, Elasticsearch, OpenSearch, Qdrant y Milvus ahora admiten consultas híbridas nativas, y tanto LangChain como LlamaIndex incluyen recuperadores de fusión que las gestionan:
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
bm25_retriever = BM25Retriever.from_texts(chunk_texts)
bm25_retriever.k = 20
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# weights are a starting point for RRF-style blending; tune against your eval set
hybrid_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.4, 0.6],
)
results = hybrid_retriever.invoke(user_query)
6. Fusión mediante promedio ponderado, no RRF
Después de añadir BM25, el paso lógico es normalizar ambas listas de puntuaciones al rango de 0 a 1 y combinarlas con un peso. Parece razonable en una hoja de cálculo. Pero las puntuaciones de BM25 y las similitudes coseno provienen de distribuciones ilimitadas y de formas diferentes, y la normalización min-máx es frágil. Un documento atípico que repite un término de consulta decenas de veces puede hacer que todas las demás puntuaciones de BM25 se acerquen a cero tras la normalización, distorsionando el ranking resultante de maneras difíciles de detectar a menos que se busquen intencionadamente.
La Fusión de Rangos Recíprocos evita este problema al utilizar la posición de rango de cada documento en cada lista e ignorar por completo las puntuaciones. Por eso, el RRF, y no el promedio ponderado, es el método predeterminado en prácticamente todas las implementaciones híbridas de producción mencionadas en los informes técnicos de 2026. La fórmula estándar asigna a cada documento la suma de 1 / (k + rank) para todas las listas en las que aparece, siendo k=60 un valor predeterminado común que atenúa la influencia de cualquier rango extremo.
7. Un k para cada etapa
Top-k suele ser una constante global que se reutiliza en la recuperación de la primera etapa, en la fusión y para el prompt final. Cuando la primera etapa obtiene solo los pocos fragmentos que puede contener el prompt, la capacidad de recuperación ya se ha perdido antes de que el reordenador pueda corregir algo: un fragmento que la búsqueda vectorial colocó en el puesto 14 nunca llega hasta él. El error opuesto ocurre al enviar cientos de candidatos a un reordenador sin realizar ningún proceso de poda posterior, lo cual consume tiempo y dinero y llena el prompt con material de baja calidad. La atención del LLM se degrada bajo esa carga (el efecto “perdido en el medio”), y esto anula silenciosamente los beneficios obtenidos con el reordenamiento.
Considere k como un embudo. En la primera etapa, seleccione un grupo amplio, de unos 20 a 100 candidatos, para que el mecanismo de reclasificación tenga espacio para corregir errores en el orden inicial; luego reduzca el conjunto a un grupo final pequeño, de aproximadamente 3 a 8 elementos, para el prompt. Ajuste el valor de k en cada etapa por separado según el conjunto de evaluación, ya que un único valor no puede servir para ambos propósitos.
Dos errores en el ranking y las embeddings
8. Omitir la reclasificación
La reclasificación implica una llamada a la red o un paso de inferencia, lo que genera latencia y, en el caso de servicios alojados, costos adicionales. Bajo presión de plazos, es lo primero que se elimina, y el orden de la primera etapa se considera definitivo.
La búsqueda vectorial de primera etapa se basa en bi-encoders, que comprimen un texto en un vector fijo antes de que exista cualquier consulta. Eso es lo que los hace rápidos a gran escala, pero también limita su precisión, ya que se pierde la interacción detallada entre una consulta específica y un texto específico. Los cross-encoders la recuperan al leer ambos al mismo tiempo. Informes independientes de 2026 describen el reordenamiento con cross-encoder como la mejor adición para un proceso con una recuperación de primera etapa decente: son típicos aumentos de varios puntos en precisión o NDCG, y se logran resultados positivos incluso en conjuntos de datos léxicamente difíciles, todo ello con una latencia adicional de menos de 200 ms en tamaños de conjunto razonables. Una cuenta de consultoría atribuyó un aumento de 23 puntos en precisión en un proyecto de cliente al reordenamiento, un valor mayor que cualquier cambio en los embeddings o en el tamaño de los fragmentos. Una vez que funcione la búsqueda híbrida, este es el siguiente paso a probar.
El cambio consiste en insertar una etapa de reclasificación entre la fusión y el prompt final. Para el autoalojamiento sin costo por llamada, bge-reranker-v2-m3 es un codificador cruzado abierto popular con buena cobertura multilingüe. La API Rerank de Cohere es la alternativa gestionada habitual cuando no se desea infraestructura GPU. Ambos se integran con LangChain y LlamaIndex:
from FlagEmbedding import FlagReranker
reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True)
def rerank(query: str, candidates: list[str], top_k: int = 5) -> list[str]:
pairs = [[query, c] for c in candidates]
scores = reranker.compute_score(pairs, normalize=True)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [text for text, _ in ranked[:top_k]]
final_context = rerank(user_query, fused_candidates, top_k=5)
9. Un modelo de embedding general en un corpus especializado
El modelo de embedding que viene incluido con el framework suele aplicarse directamente a un corpus legal, médico o financiero, justificado por unas pocas verificaciones manuales. Los modelos de uso general aprenden a partir de textos amplios de la web y de enciclopedias, por lo que no distinguen con tanta claridad el jerga especializada como los modelos entrenados con material específico del dominio. Esta deficiencia afecta especialmente en los casos donde las consecuencias son más graves. En campos regulados, un error leve, como incluir un pasaje sobre el procedimiento estándar en lugar de la excepción concreta que alguien preguntaba, genera una respuesta que parece plausible pero está errónea de forma contundente, lo cual es peor que un fallo evidente.
Antes de proceder con el compromiso, ejecute al menos un incrustador adaptado o ajustado al dominio frente al valor predeterminado general en el conjunto de referencia. Cuando no es posible realizar el ajuste de un incrustador, un reclasificador de codificador cruzado entrenado con un pequeño conjunto de consultas de dominio etiquetadas suele cerrar la mayor parte de la brecha de manera más rápida y económica, ya que corrige los errores de la primera etapa sin volver a incrustar todo el corpus.
El error que oculta a los demás
10. Facturación por impresiones
La infraestructura de evaluación parece un gasto adicional además del trabajo en nuevas funcionalidades, y parece suficiente echar un vistazo a algunos resultados cuando la demostración se ve bien. Con creces, esto representa el mayor costo secundario, ya que oculta los otros nueve problemas. Las alucinaciones basadas técnicamente en el contexto recuperado, los documentos corregidos en el orden incorrecto y los fragmentos cortados justo en el límite equivocado no pueden detectarse de manera fiable al leer los resultados, y para cuando los usuarios los reportan ya se encuentran en producción.
La solución consiste en un conjunto “oro” de 50 a 200 pares de preguntas y respuestas representativas que abarcan casos límite como frases ambiguas, preguntas de múltiples pasos que requieren dos documentos y reformulaciones adversarias. Se evalúa mediante un panel estándar dividido en dos partes: el recuperador se juzga por la precisión y el recuerdo contextual, mientras que el generador se evalúa por su fidelidad y por el grado de relevancia de la respuesta. Dos frameworks lideran este campo, y los equipos suelen combinarlos. Ragas es el lugar habitual para explorar métricas, y su generador sintético puede crear un conjunto “oro” a partir del corpus para que una persona lo refine. DeepEval, desarrollado sobre pytest, es la forma habitual de convertir la evaluación en una verdadera barrera de integración continua. Una división común es utilizar Ragas para la exploración y generación de datos, y DeepEval para validar cada solicitud de integración:
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, ContextualPrecisionMetric
from deepeval.test_case import LLMTestCase
def test_refund_policy_query():
test_case = LLMTestCase(
input="What is the refund window for the Pro plan?",
actual_output=rag_pipeline.run("What is the refund window for the Pro plan?"),
retrieval_context=rag_pipeline.last_retrieved_chunks,
expected_output="Pro plan purchases can be refunded within 14 days of purchase.",
)
faithfulness = FaithfulnessMetric(threshold=0.8)
precision = ContextualPrecisionMetric(threshold=0.7)
assert_test(test_case, [faithfulness, precision])
Integre un conjunto como este en CI de modo que cualquier ajuste relacionado con el fragmentado de datos, cambio en la integración de información o actualización de la base de conocimientos que deteriore la capacidad de recuperación interrumpa el proceso de construcción antes de arruinar el día de un cliente.
Cómo varían los errores según el entorno
- Búsqueda empresarial interna y preguntas y respuestas sobre documentos, la configuración más común, depende en gran medida de la recuperación híbrida. El personal pega números de ticket, códigos de políticas y códigos SKU junto con preguntas en lenguaje sencillo, y la búsqueda basada únicamente en texto denso sigue pasando por alto la parte literal de las preguntas.
- Botones de soporte dirigidos a clientes se benefician al máximo de la reclasificación de resultados. Una respuesta correcta pero errónea en estos casos se convierte en un ticket o en una cuenta perdida, en lugar de que un colega simplemente ignore la consulta.
- Industrias reguladas (finanzas, salud, derecho) requieren embeddings adaptados al dominio o herramientas de reclasificación, además de una evaluación estricta, ya que una recuperación cercana al error genera riesgos de incumplimiento y responsabilidad legal.
- Productos de consumo de alto tráfico operan bajo los límites de latencia más estrictos para la fusión de resultados y la reclasificación. El objetivo es lograr la mayor precisión posible dentro de un presupuesto de recuperación de menos de 200 ms, lo que favorece a los codificadores pequeños o a las herramientas de reclasificación basadas en GPU autohospedadas en lugar de los modelos más grandes.
- Asistentes de programación y plataformas de herramientas para desarrolladores representan un caso reciente y en rápido crecimiento en el que el particionamiento consciente de la estructura es más importante que en el texto prosaico. Los códigos y las referencias a APIs son altamente estructurados, y una división descuidada destruye precisamente esa estructura que los hace buscables.
Elegir el siguiente paso
En la fase previa al lanzamiento, o mientras aún se está probando si RAG es viable en absoluto, la búsqueda basada únicamente en vectores es el punto de partida adecuado: es la más rápida de implementar y permite responder a la cuestión arquitectónica en un día. Una vez que existan consultas reales de usuarios, se deben analizar los registros en busca de patrones de coincidencia exacta como códigos de producto, IDs de ticket y valores de configuración. Si aparecen, se debe añadir BM25 con fusión RRF antes que nada, ya que las fuentes indican consistentemente que representa la mayor mejora individual en la recuperación de información, y con una gran ventaja. A continuación se procede con el reclasificado, cuando la búsqueda híbrida funciona y el objetivo es la precisión en lugar de la mera recuperación. Es económica teniendo en cuenta los resultados que ofrece y no requiere reconstrucción del índice. SPLADE o embeddings ajustados al dominio deberían esperar a que los equipos cuenten con un proceso de evaluación maduro que ya haya demostrado que la combinación de búsqueda híbrida y reclasificado deja un margen de mejora, ya que implican más esfuerzo y mantenimiento, y es difícil justificar su uso sin una métrica de referencia.
El número de empleados y el presupuesto cambian la respuesta. Con dos ingenieros, una API de reclasificación gestionada (Cohere es la opción habitual) es mejor que ejecutar un codificador cruzado internamente: con un tráfico moderado, las tarifas son bajas en comparación con las horas que consumen los servidores GPU. Cuando ya se cuenta con personal de MLOps y GPUs, o el tráfico es lo suficientemente intenso como para que la facturación por solicitud se convierta en un gasto importante, tiene más sentido alojar un modelo abierto como bge-reranker-v2-m3.
Qué cuesta aún un buen pipeline
RAG no es una solución perfecta. Su principal ventaja radica en su base de datos: las respuestas pueden citar fuentes recuperadas en lugar de basarse únicamente en lo que el modelo memorizó, y la base de conocimientos puede actualizarse sin necesidad de volver a entrenarlo. Sin embargo, este mecanismo adicional supone un verdadero costo operativo. Hay dos índices que deben mantenerse alineados, un sistema de reclasificación para detectar desviaciones, un proceso de evaluación que debe conservarse como un elemento fundamental, y un esquema de fragmentación que necesita ser revisado cuando cambia la combinación de documentos.
RAG tampoco elimina las alucinaciones. Reduce la fabricación de información debido a la falta de conocimientos, pero no aborda los casos en los que el LLM interpreta o aplica incorrectamente un contexto que le fue proporcionado correctamente. Existen métricas de fidelidad porque “basarse en un contexto recuperado” y “ser correcto” son propiedades diferentes, y un proceso maduro mide ambas.
Preparación para producción
- Evaluación en CI. Ejecutar la combinación de Ragas y DeepEval en cada cambio de prompt, recuperador o base de conocimientos, en lugar de realizar la verificación solo una vez al lanzar.
- Sincronización del índice. Actualizar los índices BM25 y vectoriales juntos o según el mismo horario. Cuando un índice obsoleto coexiste con embeddings recientes, la recuperación de información se desvía de formas difíciles de detectar.
- Observabilidad. Registrar los fragmentos recuperados para cada consulta, no solo la respuesta final. Eso permite rastrear una mala respuesta hasta su origen en la recuperación o en la generación, sin necesidad de especular.
- Credenciales. Mantener las claves API de reclasificación y de embeddings fuera del repositorio y rotarlas a través del gestor de secretos habitual.
La lección clave
Mire lo que devolvió el recuperador antes de cambiar la instrucción o el modelo. Nueve de los diez errores (fragmentación deficiente, falta de búsqueda híbrida, fusión ingenua, conjuntos de candidatos de tamaño inadecuado, omisión del reclasificado y uso de un modelo de embedding sin verificar) son problemas de recuperación que se pueden solucionar con ajustes en dicho proceso. El décimo error, la falta de evaluación, es la razón por la cual los otros nueve suelen pasar desapercibidos.
Ninguna de las soluciones requiere un equipo de investigación. Agregar BM25 junto a un almacén de vectores existente, reemplazar la combinación de puntuaciones por RRF o eliminar una llamada de reclasificación entre la fusión y la generación es más cercano a un trabajo de ingeniería que a un rediseño, y cada uno cuenta con soporte consistente en fuentes independientes, incluso cuando las cifras difieren. Un punto de partida práctico: obtenga dos semanas de consultas reales de usuarios, cuente cuántas contienen identificadores exactos que la búsqueda vectorial difuminaría, y cree un conjunto de referencia de 50 consultas a partir de los fallos ya disponibles. Es menos de lo que parece, y permite determinar cuál de los diez errores cuesta más.
Leer más
- Depuración de fallos silenciosos en RAG: recuperación, fragmentación, filtros y evaluaciones — Las respuestas de RAG pueden sonar correctas y aun así estar equivocadas. Un playbook orientado a Python para rastrear la recuperación de datos, la fragmentación, los filtros de metadatos, las evaluaciones, la búsqueda híbrida y otros aspectos relacionados.
- RAG híbrido para textos jurídicos: fragmentación, BM25, BGE y reclasificación — Un pipeline RAG para textos jurídicos basado en la Constitución de la India: fragmentación de tipo padre-hijo, recuperación con BM25 y BGE, fusión de rangos, reclasificación mediante codificador cruzado y expansión de consultas, probado en pruebas de referencia.