Notas prácticas: ¿Qué es la generación reforzada por recuperación de información (RAG)? Una guía práctica
Guía paso a paso práctica: ¿Qué es la generación mejorada por recuperación de información (RAG)? Una guía práctica con contratos, verificaciones y espacios para código listo para usar destinados a los equipos que implementan este patrón.
Las notas siguientes reconstruyen un camino práctico basado en “¿Qué es la generación mejorada por recuperación de información (RAG)? Una guía práctica con ejemplos en Python — Geeky Codes”. Se da énfasis a los contratos, las verificaciones y los marcadores de posición para código listo para usar, en lugar de un enfoque motivacional.
Aprende cómo funciona RAG, por qué los LLM generan información errónea, y crea tu primer pipeline de generación mejorada por recuperación de información en Python.
Al trabajar en la etapa de aprendizaje sobre cómo funciona RAG, anota primero el contrato: entradas requeridas, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Mantén la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema. Registra el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen ser defectos de la aplicación.
Recuperación
Al trabajar en la fase de recuperación, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Documente junto con ello el camino óptimo y el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no de mejoras posteriores. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
Mejorado
Al trabajar en la etapa de Augmented, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestas las futuras modificaciones del código. Prefiera unidades pequeñas y probables sobre scripts extensos. Cuando un paso falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
Generación
Al trabajar en la etapa de generación, primero escribe el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Considera esta etapa como un contrato entre los datos de entrada y los resultados validados. Nombra los artefactos, define las verificaciones de éxito y rechaza las completaciones parciales silenciosas. Registra el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación.
Documents
│
▼
Data Ingestion
│
▼
Text Extraction
│
▼
Chunking
│
▼
Embedding Model
│
▼
Vector Database
──────────────────────────────────────────
User Question
│
▼
Query Embedding
│
▼
Similarity Search
│
▼
Top-K Relevant Chunks
│
▼
Prompt Builder
│
▼
Large Language Model
│
▼
Final Answer
from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
documents = [
"Employees receive 20 days of paid leave every year.",
"Annual bonuses are paid in December.",
"Health insurance covers hospitalization expenses."
]
model = SentenceTransformer("all-MiniLM-L6-v2")
embeddings = model.encode(documents)
index = faiss.IndexFlatL2(embeddings.shape[1])
index.add(np.array(embeddings).astype("float32"))
query = "How many leave days do employees receive?"
query_embedding = model.encode([query])
D, I = index.search(
np.array(query_embedding).astype("float32"),
k=1
)
print(documents[I[0][0]])
Desafíos comunes en producción
Al trabajar en la etapa de Desafíos Comunes de Producción, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la fase de demostración a entornos compartidos. Registre el ID de la solicitud, el ID del modelo y la latencia en cada llamada. Sin ese registro, los errores intermitentes del proveedor parecen bugs de la aplicación. Al trabajar en la etapa de Desafíos Comunes de Producción, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras adicionales realizadas posteriormente.
Puntos Clave
La etapa de conclusiones clave funciona mejor cuando se trata como una superficie medible. Capture un registro ejemplar, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una sola responsabilidad y no a un proceso complicado. Fije el intérprete y el archivo de bloqueo de dependencias antes de explicar los bucles. La diferencia entre usar una computadora portátil y un entorno de integración continua es la causa más común de fallos silenciosos en las demostraciones de API.
Referencias
La etapa de Referencias funciona mejor cuando se trata como una superficie medible. Capture un transcripte ejemplar, un caso de fallo y la nota de reversión antes de ampliar el alcance. Considere esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace completaciones parciales silenciosas. Fije el intérprete y el archivo de bloqueo de dependencias antes de enseñar el bucle; la diferencia entre usar una computadora portátil y un entorno CI es la causa más común de fallos silenciosos en las demostraciones de API.
Lista de verificación operativa
En la etapa de la lista de verificación operativa, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto.
Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un único lugar que los operadores puedan auditar sin tener que leer todo el sistema.
Separe la construcción del cliente del bucle de mensajes para que sea posible cambiar los proveedores sin tener que reescribir la máquina de estados de las conversaciones.
Mida el rendimiento en un conjunto fijo de preguntas antes de ajustar los prompts. El cambio constante de prompts rara vez soluciona problemas en la capacidad de recuperación de información.
Congele un conjunto estándar antes de modificar los prompts o modelos. Cambiar tanto el sistema como las métricas utilizadas para evaluarlo oculta posibles regresiones.
Añada una prueba de funcionamiento básica que ejecute la ruta crítica en los procesos de integración continua utilizando datos de prueba, y no APIs pagadas en tiempo real, siempre que lo permitan los presupuestos.
Antes de promocionar el stack, congele las versiones, capture una transcripción de referencia para la ruta crítica y confirme los pasos de reversión. Los entornos compartidos requieren límites de velocidad, verificaciones de tenencia y un responsable claro para la rotación de secretos. Prefiera una fiabilidad sencilla a demostraciones ingeniosas pero puntuales.
Nota para el lote ce641ce6bc02: mantenga las claves del proveedor fuera del repositorio, establezca un límite para tokens por sesión y almacene las transcripciones junto a los fixtures de evaluación para que los cambios posteriores en el modelo sigan siendo comparables.
Lecturas relacionadas
- Notas prácticas: RAG vs Fine-Tuning vs AI Agents: Cuándo usar qué en sistemas AI reales — Guía detallada de las Notas prácticas: RAG vs Fine-Tuning vs AI Agents: Cuándo usar qué en sistemas AI reales, con contratos, verificaciones y espacios para código listo para usar por parte de los equipos.