No reinventar la rueda: proyectos y estándares antes de construir tu propio RAG
El instinto de todo equipo técnico frente a "necesitamos que un agente entienda nuestro codebase/documentación" es construir: vectorizar todo, levantar una base vectorial propia, mantenerla. Antes de arrancar ese camino, vale la pena mirar qué ya está resuelto — construir cuando ya existe algo mejor no es ambición, es deuda técnica que tu equipo va a pagar en dos años.
Grandes codebases — ahorro de tokens
Understand Anything
Comprime y mapea codebases grandes para reducir el consumo de tokens de forma masiva cuando un agente necesita razonar sobre un repo completo. github.com/Egonex-AI/Understand-Anything
Graphify
Convierte el codebase en un grafo de dependencias navegable por el agente, en vez de que este tenga que leer archivo por archivo para entender cómo se conecta todo. github.com/Graphify-Labs/graphify
Vectorless RAG — hacia dónde vamos
Vectorless RAG
RAG sin embeddings: en vez de vectorizar todo el contenido, el agente navega por páginas e índices como lo haría una persona. Más simple de mantener y sorprendentemente efectivo para documentación estructurada. Understanding Vectorless RAG (Medium)
OpenWiki (LangChain)
Todavía en desarrollo — la dirección hacia la que apunta el ecosistema: documentación como grafo de conocimiento vivo, consultable por agentes en vez de un conjunto de páginas sueltas. github.com/langchain-ai/openwiki
Estándares abiertos — la doc como conocimiento
Open Knowledge Format (OKF)
Estándar abierto propuesto por Google: la documentación se representa como markdown + YAML, formando un grafo de conocimiento que cualquier agente puede consultar sin integraciones custom ni vendor lock-in. cloud.google.com — Open Knowledge Format
Antes de construir, preguntate
- ¿Ya hay un estándar abierto resolviendo esto?
- ¿El problema es técnico, o es que en tu equipo nadie definió el mismo formato de documentación?
- ¿Construir esto te da una ventaja real, o solo te ata a mantenerlo vos?
Si la respuesta a la primera pregunta es sí, adoptar y adaptar te sale más barato — en tiempo de desarrollo y en mantenimiento — que construir desde cero.