Preguntas de entrevista de IA, Serie 11: ¿Cómo optimizar RAG?

La optimización de RAG no es un ajuste de un solo eslabón, sino un proceso de optimización de toda la cadena. A continuación, desde las cuatro dimensiones de lado de indexación de datos, lado de recuperación, lado de generación y lado de evaluación, proporciono estrategias de ajuste sistemáticas, junto con experiencia práctica que se puede mencionar en entrevistas.

1. Ajuste del lado de indexación de datos (mejorar la calidad de la "base de conocimiento")

Esta es la parte más fácil de pasar por alto pero que produce resultados más rápido.

Punto de ajuste	Síntoma	Método específico	Indicador de efecto
Análisis de documentos	Las tablas y diagramas de flujo en PDF se ignoran, o el texto aparece distorsionado o en orden incorrecto.	Cambiar a una biblioteca de análisis mejor (como el modo de conservación de diseño de `unstructured`, `pypdf`); para tablas, extraer con `pandas` y convertir a Markdown.	Tasa de recuperación +5~15%
Tamaño de fragmento de texto	Chunk demasiado pequeño pierde contexto (por ejemplo, "su crecimiento de ingresos este año" pierde la referencia de "su"); chunk demasiado grande introduce ruido en la recuperación.	Experimentar con diferentes tamaños de chunk (256/512/768 tokens), superposición de 10~20%; para documentos largos, dividir por límites semánticos (párrafos/títulos) en lugar de longitud fija.	Tasa de acierto / Fidelidad
Adjuntar metadatos	Se recuperan párrafos relevantes pero no se puede rastrear la fuente o la fecha, o es necesario filtrar por dominio.	Agregar metadatos a cada chunk: `source` (nombre de archivo/URL), `timestamp`, `page_num`, `doc_type`. Usar filtros durante la recuperación (por ejemplo, `doc_type == 'legal'`).	Precisión del filtro
Selección del modelo de incrustación	El embedding genérico funciona mal en dominios verticales (medicina, código, derecho).	Usar modelos ajustados por dominio (BGE-large-zh, GTE-Qwen2-7B-instruct); o ajustar su propio modelo de embedding (con triplet loss).	MRR@10 de recuperación +10~20%

2. Ajuste del lado de recuperación (hacer que "hojear" sea más preciso)

La recuperación determina la calidad de los "materiales de referencia" que se alimentan al LLM.

Punto de ajuste	Síntoma	Método específico	Efecto
Búsqueda híbrida	La búsqueda vectorial no puede coincidir con términos exactos (como el modelo de producto `ABC-123`), la búsqueda por palabras clave no entiende sinónimos.	Usar simultáneamente búsqueda vectorial (semántica) y BM25 (palabras clave), fusionar mediante ponderación (por ejemplo, 0.7vector + 0.3BM25) o rerank.	Tasa de recuperación +10~25%
Reordenación (Rerank)	Los primeros resultados devueltos por la búsqueda vectorial no son necesariamente los más relevantes; el décimo es el mejor.	Usar un modelo cross-encoder (como `BGE-reranker-v2`, Cohere Rerank) para re-puntuar el conjunto de candidatos (por ejemplo, los primeros 20) y tomar top-K.	Mejora significativa en la tasa de acierto (especialmente top-1)
Reescritura de consultas	La pregunta del usuario es vaga o las referencias en conversaciones múltiples no son claras ("¿su precio?").	Usar un LLM para reescribir la pregunta original en una forma más adecuada para la recuperación (por ejemplo, "¿Cuál es el precio del iPhone 15?"); o completar usando el historial de la conversación.	Tasa de recuperación +5~15%
HyDE	La pregunta del usuario es demasiado corta o abstracta (por ejemplo, "explica la fotosíntesis"), la recuperación directa es deficiente.	Primero dejar que el LLM genere una respuesta hipotética, luego usar esa respuesta para recuperar documentos.	Adecuado para dominios abiertos, pero no para preguntas fácticas precisas
Ajuste del número Top-K de recuperación	K demasiado pequeño puede perder información clave; K demasiado grande aumenta el consumo de tokens y el ruido.	Experimentar con K=3/5/10, observar el equilibrio entre tasa de recuperación y precisión de la respuesta.	Compensación entre eficiencia y efecto

3. Ajuste del lado de generación (hacer que el LLM utilice bien los materiales de referencia)

Por muy precisa que sea la recuperación, si el prompt no es bueno o el modelo no es adecuado, no sirve.

Punto de ajuste	Síntoma	Método específico	Efecto
Ingeniería de prompts	El LLM ignora el contenido recuperado o inventa hechos.	Instrucción clara: "Responda únicamente basándose en los materiales de referencia proporcionados a continuación. Si la información es insuficiente o no relevante, responda 'No hay suficiente información'." Agregar few-shot examples que muestren cómo citar fuentes.	Fidelidad +20~40%
Compresión de contexto	El contenido recuperado es demasiado largo (excede la ventana de contexto del modelo) o contiene mucho ruido.	Usar `LLMLingua` o `contexto selectivo` para comprimir, conservando solo las oraciones más relevantes antes de enviarlo al LLM.	Reduce el riesgo de pérdida de información
Actualización del modelo LLM	Un modelo pequeño (7B) no puede realizar razonamientos complejos o no recuerda contextos largos.	Cambiar a un modelo más potente (GPT-4o, Claude 3.5 Sonnet, Qwen2.5-72B).	Gran mejora en la precisión del razonamiento
Transmisión y citas	El usuario no puede verificar la credibilidad de la respuesta.	Al generar, hacer que el LLM produzca `[citation:1]`, correspondiente al número del documento recuperado. En el backend, adjuntar el enlace al texto original.	Confianza del usuario + depuración
Calibración de rechazo de respuesta	El modelo inventa cuando no debería responder, o dice no saber cuando debería responder.	Establecer un umbral de similitud: si la similitud de coseno entre el chunk top-1 recuperado y la pregunta es inferior a 0.7, indicar al LLM "los materiales no son relevantes".	Reduce la tasa de alucinaciones

4. Evaluación e iteración (saber hacia dónde ajustar)

Sin medición no se puede optimizar.

Punto de ajuste	Método	Indicador
Construir un conjunto de evaluación	Preparar de 100 a 300 preguntas reales de usuario + respuestas estándar + ID de documentos de recuperación correctos.	Cubrir diferentes niveles de dificultad e intenciones.
Evaluación automatizada	Usar RAGAS (Faithfulness, Answer Relevance, Context Recall) o TruLens.	Tres indicadores centrales: fidelidad, relevancia de la respuesta, tasa de recuperación del contexto.
Evaluación manual	Cada semana, probar 20 casos malos, analizar el tipo de error (fallo de recuperación / error de generación / falta de base de conocimiento).	Priorizar las mejoras.
Pruebas A/B	En el entorno de producción, probar diferentes estrategias de recuperación en cubos (por ejemplo, BM25 vs búsqueda híbrida).	Indicadores en línea: satisfacción del usuario, tasa de sin respuesta.

5. "Experiencia práctica" que se puede mencionar en entrevistas (puntos extra)

"En el proyecto RAG que dirigí, la tasa de acierto inicial era solo del 67%. Hice tres cosas:
1. Cambiar la segmentación de fija 1024 a segmentación semántica dinámica (por títulos y párrafos), la tasa de acierto subió al 74%;
2. Agregar búsqueda híbrida (vectorial + BM25) y un pequeño modelo de rerank, la tasa de acierto subió al 83%;
3. Optimizar el prompt y exigir '[Información relevante no encontrada]', la tasa de alucinaciones bajó del 22% a menos del 5%.

Además, establecimos un pipeline de evaluación continua, ejecutando la puntuación RAGAS en 200 preguntas antes de cada cambio para asegurar que no hubiera degradación."

Resumen final: una hoja de ruta completa de optimización de RAG

Capa de datos ─→ Limpieza de documentos, optimización de fragmentación, aumento de metadatos, embedding de dominio
Capa de recuperación ─→ Búsqueda híbrida, rerank, reescritura de consultas, HyDE, ajuste de Top-K
Capa de generación ─→ Refuerzo de prompts, instrucciones, compresión, citas, umbral de rechazo
Capa de evaluación ─→ Conjunto de evaluación, RAGAS, análisis manual, experimentos A/B