¿Cuál elegir?
La respuesta no es “X gana”
Sección titulada «La respuesta no es “X gana”»Llegaste a la pregunta que empezó el nivel: ¿cuál de los 4 elegir para tu proyecto?.
La respuesta no es “X es mejor”. Es depende de A, B, C — y acá están los criterios. Lo que sigue es un árbol de decisión, tres escenarios concretos, y una advertencia importante sobre por qué la “decisión definitiva” no existe.
El árbol de decisión
Sección titulada «El árbol de decisión»flowchart TD
Start[¿Cuál framework?] --> Q1{¿RAG es uno de varios<br/>tools en un agente?}
Q1 -->|Sí| M[Mastra]
Q1 -->|No| Q2{¿Necesitás integraciones<br/>con servicios específicos?<br/>SharePoint, Confluence, etc.}
Q2 -->|Sí| L[LangChain.js]
Q2 -->|No| Q3{¿TS strict + edge runtime<br/>+ querés implementar técnicas<br/>avanzadas vos?}
Q3 -->|Sí| V[Vercel AI SDK]
Q3 -->|No| Q4{¿Querés moverte rápido<br/>con índices RAG-first<br/>de alto nivel?}
Q4 -->|Sí| LI[LlamaIndex.TS]
Q4 -->|No| V
style M fill:#1d1a27,stroke:#a78bfa,stroke-width:2px,color:#e7e3f4
style L fill:#1d1a27,stroke:#a78bfa,stroke-width:2px,color:#e7e3f4
style V fill:#1d1a27,stroke:#a78bfa,stroke-width:2px,color:#e7e3f4
style LI fill:#1d1a27,stroke:#a78bfa,stroke-width:2px,color:#e7e3f4
Lectura honesta del árbol: la última rama te lleva a Vercel AI SDK como default razonable si ningún criterio específico empuja hacia otro. No porque sea “mejor” — porque cuando no hay restricciones específicas, el control granular y los tipos limpios son ventaja.
Tres escenarios concretos
Sección titulada «Tres escenarios concretos»Escenario A — Startup con docs internos
Sección titulada «Escenario A — Startup con docs internos»Caso: empresa de 30 personas. Querés un chatbot que conteste preguntas sobre los docs internos (Notion + algunos PDFs). 1-3 devs. Plazo: prototype en 1 sprint, deploy en 2-3.
Recomendación: Vercel AI SDK o LlamaIndex.TS.
Argumento: corpus chiquito-mediano, sin integraciones exóticas, sin necesidad de agentes. Cualquiera de los dos resuelve.
- Vercel si tu equipo es TS-strict y prefiere control.
- LlamaIndex si querés moverte más rápido al inicio (las abstracciones de RAG-first te ahorran boilerplate).
Cualquiera de los dos en 1 sprint llega a un POC funcional.
Escenario B — Empresa con stack heterogéneo
Sección titulada «Escenario B — Empresa con stack heterogéneo»Caso: empresa de 500 personas. Docs en SharePoint (8 sitios), Confluence (3 spaces), repositorio interno de tickets, base de datos Postgres con productos. El RAG tiene que conectar a todo eso.
Recomendación: LangChain.js.
Argumento: las integraciones que necesitás existen pre-armadas en @langchain/community. El costo de setup de LangChain (curva de aprendizaje, conceptos) es menor que escribir esos document loaders, retrievers y connectors a mano.
Trade-off aceptado: tipos más laxos, más capas para debuggear, breaking changes ocasionales. A cambio: cobertura del ecosistema sin precio comparable.
Escenario C — Producto agéntico
Sección titulada «Escenario C — Producto agéntico»Caso: estás construyendo un asistente que combina RAG + búsqueda web + acceso a APIs internas + memoria persistente. La conversación es multi-turn y el agent decide cuándo invocar qué.
Recomendación: Mastra.
Argumento: Mastra está construido para este modelo mental — agents con tools, workflows con state, memory primitives integrados. Hacer lo mismo en Vercel/LangChain/LlamaIndex requiere armar la orquestación a mano.
Importante: si después decidís que el RAG necesita más afinamiento (hybrid + rerank + multi-query del Nivel 3), Mastra es el path más doloroso para implementar esas técnicas. Compensás simplicidad agéntica con complejidad de tuning fino.
La trampa de “la decisión definitiva”
Sección titulada «La trampa de “la decisión definitiva”»Ningún framework es para siempre. Cuatro razones:
-
Los frameworks evolucionan. LangChain de 2024 no es LangChain de 2026. Mastra puede subir de calidad en 6 meses. Vercel puede agregar features que hoy le faltan. La decisión correcta hoy puede no ser la correcta en 1 año.
-
Tu caso evoluciona. Empezás con un caso A (chat docs), terminás con un caso B (agent multi-tool). Si el framework no acompaña, migrás.
-
Migrar es factible. Los 4 packages del repo producen el mismo
RAGQueryFninterface enquery.fn.ts. Pasar de uno a otro es: re-ingestar el corpus en la collection del nuevo, ajustar el query path. Una semana de trabajo, no un re-write. -
Lo que de verdad transfiere son los conceptos. Los caps de Nivel 1-4 — chunking, retrieval, eval, rerank, citations, tracing, costs, refresh, edge — aplican igual con los 4 frameworks. Lo que aprendiste del curso no se pierde cuando migrás.
El verdadero ROI del nivel
Sección titulada «El verdadero ROI del nivel»Si te llevás solo una idea, que sea esta:
El framework no es la decisión más importante de tu RAG. Las decisiones importantes son:
- ¿Qué corpus usás? (Niveles 0, 1)
- ¿Cómo lo chunkás? (Nivel 1, 2)
- ¿Cómo medís calidad? (Nivel 2)
- ¿Cuándo aplicás hybrid + rerank? (Nivel 3)
- ¿Cómo lo operás en producción? (Nivel 4)
Esas decisiones transfieren entre frameworks. La decisión de framework solo te da el punto de partida — los problemas reales aparecen después.
Cerraste el curso
Sección titulada «Cerraste el curso»Si llegaste hasta acá, terminaste los 6 niveles:
- Nivel 0 — Conceptos: qué es RAG, cómo funciona, vocabulario, por qué local-first, por qué TypeScript.
- Nivel 1 — Manos a la obra: pipeline RAG end-to-end con Vercel AI SDK + Qdrant + Ollama.
- Nivel 2 — Calidad y evaluación: eval harness, faithfulness, golden sets, datasets sintéticos, comparativa de configs.
- Nivel 3 — Avanzado: hybrid search, reranking, multi-query, query rewriting, citations.
- Nivel 4 — Operación: tracing, costos, refresh incremental, edge deploys, production checklist.
- Nivel 5 — Comparativa: análisis side-by-side de 4 frameworks con métricas reales y árbol de decisión.
Eso es más de lo que sabe el 95% de la gente que pone “RAG” en su LinkedIn. En serio.
¿Qué hacer ahora?
Sección titulada «¿Qué hacer ahora?»Tres cosas, en orden:
1. Aplicalo en algo real
Sección titulada «1. Aplicalo en algo real»El curso usó un corpus juguete: 4 markdowns sobre arquitecturas de software. Tu próximo paso es hacer lo mismo con un corpus que te importe:
- Tu propio knowledge base (notas en Notion, docs personales, papers).
- Los docs internos de tu empresa (con el OK del equipo de seguridad).
- Una colección temática (libros que leíste, posts que guardaste, transcripciones de podcasts).
Lo que sea — lo importante es que el corpus tenga valor para vos, no que sea grande. Un RAG sobre 50 docs propios es más útil que sobre 50,000 docs random.
2. Escribí sobre lo que aprendiste
Sección titulada «2. Escribí sobre lo que aprendiste»Un blog post. Un thread. Una charla en tu comunidad. No lo aprendiste hasta que lo explicaste.
Pequeñas formas que funcionan:
- “Cómo armé un RAG sobre [tu corpus] en TypeScript” — paso a paso, con números.
- “Qué métricas miré para decidir entre LangChain y Vercel AI SDK” — defendé tu elección con evidencia.
- “5 errores que cometí en mi primer RAG” — los del cap 06 del Nivel 1, con tu vivencia.
Bonus: el repo del curso es público y tiene MIT license. Linkealo en tu post. Sirve como prueba de que sabés de lo que hablás.
3. Contribuí si encontrás algo
Sección titulada «3. Contribuí si encontrás algo»Si en tu uso del repo encontrás:
- Un bug en cualquier package.
- Un caso del curso que se rompió por una versión nueva.
- Una técnica del Nivel 3 que querés ver implementada con un cross-encoder real.
- Un capítulo nuevo que crees que falta.
Abrí un issue o un PR. El repo está en github.com/tincke10/RAG-Labs-TS. Si la comunidad colabora, el curso se mantiene vivo.
Listo. Suerte con todo.