Production checklist + appendix de comandos

Llegaste

Si llegaste hasta acá:

• Tenés un pipeline RAG end-to-end (Nivel 1).
• Lo medís con métricas reproducibles (Nivel 2).
• Le metiste técnicas de producción: hybrid + rerank + multi-query + rewrite + citations (Nivel 3).
• Es observable, mide costo, refresca incremental, y puede deployarse a edge (Nivel 4).

Eso es más de lo que sabe el 95% de la gente que pone “RAG” en su LinkedIn. En serio.

Antes de mandarlo a usuarios reales, esta lista. No es burocracia — es lo que separa “demo que rompe” de “producto defendible”.

Production checklist

Calidad

• Golden set ≥10 preguntas sobre el corpus real (no sobre el del curso).
• Faithfulness ≥0.7 promedio en el último eval.
• Retrieval@k ≥0.6 promedio.
• Out-of-corpus probe: al menos 1 pregunta cuya respuesta no está en el corpus, y el RAG dice “no sé” en lugar de inventar.
• Eval reproducible: cualquier persona del equipo puede correr pnpm --filter @rag-lab/06-evals run eval y obtener números.

Robustez

• Los 6 errores comunes del cap 06 de Nivel 1 verificados (modelo de embeddings consistente, chunk size razonable, distance Cosine, prompt anti-alucinación, overlap > 0, payload con filename).
• Manejo de “no sé”: el prompt instruye explícitamente “si no está en el contexto, decilo”.
• Rate limiting en el endpoint público (si abrís uno). En Cloudflare Workers viene gratis vía bindings; en Node lo agregás con express-rate-limit o equivalente.

Avanzado (opcional según caso)

• Hybrid search activado si tu corpus tiene términos técnicos exactos (siglas, nombres de funciones, IDs).
• Reranking si la latencia adicional (~200-400ms) es aceptable para tu UX.
• Citations inline si los usuarios necesitan defender o verificar las respuestas.
• Multi-query activado para preguntas largas o multi-tema (cuando aplique).
• Query rewriting activado en chat multi-turn.

Operación

• Tracing instrumentado con OTel; backend (Phoenix, Langfuse, Grafana Tempo, Datadog) corriendo y configurado.
• Costos calculados con cost.ts para tu corpus + tu QPS proyectado. Multiplicado por 2 para budget seguro.
• Cache de embeddings activado en ingest.ts (5 líneas; cap 02 del Nivel 4).
• Plan de refresh definido: cron, hook post-deploy, o trigger manual. Documentado.

Deploy

• Query path en edge si latencia global importa. Si tus usuarios están en una sola región, edge es premature optimization.
• Ingest separado del query (cron / scheduled worker / Lambda) — no en el handler de request.
• Secrets en env / wrangler secret, nunca commiteados.
• Healthcheck endpoint (ej. GET /health) para uptime monitoring.

Seguridad

• Rate limiting activo (mencionado arriba).
• Sanitización del prompt: el contenido del usuario no debería poder reemplazar tu instrucción “ONLY the context”. En la práctica esto se hace embebiendo la query del usuario dentro de tags claros y usando un modelo que respete el formato — no es 100% bulletproof pero reduce el riesgo.
• Multi-tenancy: si servís múltiples clientes contra el mismo Qdrant, cada chunk debe tener un campo tenantId y el query filtrar por él. Sin esto, el cliente A puede ver chunks del cliente B. Es el bug más caro que vas a evitar.
• Audit log: qué query hizo qué usuario y qué respuesta recibió. Útil para compliance y para detectar abuso.

El loop de mejora continua

Producción no termina con el deploy. El workflow recurrente:

1. Logs + traces te avisan que algo anda mal.
2. Reproducís la query en local con `pnpm vercel:query:adv`.
3. Inspeccionás retrieval con `pnpm vercel:query` (Nivel 1: lectura de sources).
4. Si retrieval falló → caps 02-03 de Nivel 1, posiblemente Nivel 3 (hybrid/rerank).
5. Si generate falló → ajuste de prompt, posiblemente Nivel 3 (citations + faithfulness).
6. Cambio aplicado → corrés `pnpm --filter @rag-lab/06-evals run eval` con golden set.
7. Si métrica mejoró sin regresión → deploy.
8. Tracing valida en producción que el cambio efectivamente ayudó.

Sin métricas (Nivel 2) y sin observabilidad (Nivel 4), este loop es imposible.

La regla del 80/20 para RAG

80% de los problemas de calidad son problemas de retrieval, no de generación. Cuando algo falla, primero asumí que el chunk correcto no llegó al prompt. Solo después de descartarlo, investigá el LLM.

Esa regla está en el cap 06 de Nivel 1. Vuelve más útil con el tiempo.

Appendix: todos los comandos del curso

Tabla de referencia con cada pnpm <command> introducido a lo largo de los 4 niveles. Para encontrar dónde se explica cada uno, mirá la columna Cap.

Setup e infra

Comando	Qué hace	Cap
pnpm install	Instala deps del workspace	Nivel 1 / 01
pnpm qdrant:up	Levanta Qdrant en Docker	Nivel 1 / 01
pnpm qdrant:down	Para Qdrant	Nivel 1 / 01
pnpm qdrant:logs	Logs de Qdrant en stream	Nivel 1 / 01
pnpm phoenix:up	Levanta Phoenix (OTel) en Docker	Nivel 4 / 01
pnpm phoenix:down	Para Phoenix	Nivel 4 / 01

Pipeline básico (Nivel 1)

Comando	Qué hace	Cap
pnpm vercel:ingest	Borra y recrea la collection con todos los chunks	Nivel 1 / 03
pnpm vercel:query "<pregunta>"	Embed + retrieve + generate (sin flags)	Nivel 1 / 04

Pipeline avanzado (Nivel 3)

Comando	Qué hace	Cap
pnpm vercel:query:adv "<pregunta>"	Versión componible del query	Nivel 3 / 01–05
... --hybrid	Agrega BM25 + RRF al retriever	Nivel 3 / 01
... --rerank	Retrieve K=20 + LLM-rerank a top-4	Nivel 3 / 02
... --multi-query N	Descompone en N sub-queries	Nivel 3 / 03
... --rewrite	Reformula la query antes de embed	Nivel 3 / 04
... --cite	Citations inline + validación	Nivel 3 / 05
OTEL_ENABLED=1 ...	Activa tracing a Phoenix	Nivel 4 / 01

Eval harness (Nivel 2)

Comando	Qué hace	Cap
pnpm --filter @rag-lab/06-evals run eval -- --only vercel-ai-sdk --limit 3	Eval rápido (3 preguntas, 1 framework)	Nivel 2 / 01
pnpm --filter @rag-lab/06-evals run eval	Eval completo (12 preguntas × 4 frameworks)	Nivel 2 / 01
pnpm --filter @rag-lab/06-evals run eval -- --top-k N	Override TOP_K	Nivel 2 / 05
pnpm --filter @rag-lab/06-evals run eval -- --dataset <path>	Override golden set	Nivel 2 / 04
pnpm --filter @rag-lab/06-evals run synth -- --n 20	Genera dataset sintético	Nivel 2 / 04

Operaciones (Nivel 4)

Comando	Qué hace	Cap
pnpm vercel:refresh	Refresh incremental del índice (delta)	Nivel 4 / 03
pnpm wrangler login	Authenticación con Cloudflare (one-time)	Nivel 4 / 04
pnpm wrangler deploy	Deploy del query handler a CF Workers	Nivel 4 / 04
pnpm wrangler secret put <NAME>	Setea un secret en el worker	Nivel 4 / 04

Frontend del curso

Comando	Qué hace	—
pnpm course:dev	Levanta el sitio Astro Starlight en local	—
pnpm course:build	Build estático del curso	—
pnpm course:preview	Preview del build	—
pnpm typecheck	Typecheck recursivo del workspace	—

Cerraste el curso

Si llegaste hasta acá, el curso técnico terminó.

La parte 5 (Comparativa de frameworks) es complementaria: te muestra los mismos conceptos en LangChain.js, LlamaIndex.TS y Mastra. La idea es que veas cuál se siente mejor para vos — no que aprendas más RAG, sino que aprendas a elegir tooling con criterio.

Pero la parte importante ya la tenés:

• Sabés qué es RAG y cuándo aplicarlo.
• Sabés construirlo con tipos y código real.
• Sabés medirlo.
• Sabés mejorarlo con técnicas de producción.
• Sabés operarlo.

Eso es lo que separa a alguien que dice “trabajé con RAG” de alguien que efectivamente sabe poner uno en producción.

Ahora poné el repo en tu portfolio, escribí un blog post sobre lo que aprendiste, y empezá a aplicar todo esto en algo real. Que el corpus sea lo que sea — tu propio knowledge base, los docs de tu empresa, una colección de papers que te interesan. Lo importante es usar lo aprendido.

Listo. Suerte con todo.

Siguiente nivel Comparativa de frameworks Análisis side-by-side de Vercel AI SDK, LangChain.js, LlamaIndex.TS y Mastra con outputs reales y métricas.