La wiki interna de la empresa funciona con cinco comandos de shell y un archivo de índice mantenido a mano. Sin embeddings, sin base de datos vectorial, sin tarea de re-indexación. Para una base de conocimiento de unos 200 documentos, esa configuración es más rápida de construir, más económica de operar y más precisa que un pipeline RAG típico. La ecuación solo empieza a cambiar en algún punto pasado los 1.000 documentos, no antes.
Una nota sobre Karpathy y Obsidian
Dos ideas hicieron que este enfoque resultara obvio. La primera es el argumento recurrente de Andrej Karpathy de que los agentes de IA deberían recibir herramientas en lugar de fragmentos recuperados. Su proyecto AutoResearch, publicado en marzo de 2026, lo ilustra de forma literal: el agente ejecuta código en lugar de consultar embeddings, y el progreso viene de la ejecución. AutoResearch se analizó en detalle en un artículo anterior.
La segunda es Obsidian. Un vault de Obsidian no es más que una carpeta de archivos markdown planos. No hay base de datos propietaria, no hay esquema que migrar ni SDK que aprender. Combinado con el plugin de API REST local de Obsidian, toda la base de conocimiento queda detrás de un endpoint HTTP normal que cualquier proceso puede leer o escribir. Esa combinación hace que el patrón de «dar herramientas al agente» sea trivial de implementar: unos pocos comandos de shell bastan para disponer de un LLM que lee, escribe y busca en una base de conocimiento estructurada directamente.
Lo que se usa en la práctica
La wiki interna cuenta hoy con 22 páginas de conocimiento estructurado: entidades (personas, empresas, proyectos), conceptos (marcos y principios), fuentes (notas de investigación en bruto) y páginas de síntesis que los conectan. Cada página enlaza a otras mediante wikilinks de Obsidian, y un `index.md` mantenido a mano en la raíz lista todo por categoría con descripciones de una línea.
El agente no busca en el vault con embeddings. Ejecuta cinco comandos:
- `wiki read <ruta>`. Recupera una página markdown.
- `wiki write <ruta> -`. Crea o sobreescribe una página desde stdin.
- `wiki append <ruta> <texto>`. Añade una línea a una página (usado para el registro de actividad continuo).
- `wiki search <consulta>`. Utiliza la búsqueda de texto completo integrada en Obsidian.
- `wiki list <dir>`. Lista los archivos de un directorio.
La implementación completa ocupa unas 80 líneas de bash y curl. No hay base de datos vectorial, ni modelo de embeddings, ni estrategia de chunking, ni reranker, ni tarea de indexación nocturna. Añadir una nota nueva es simplemente escribir el archivo. El agente la incorpora en la siguiente consulta sin ningún paso de pipeline intermedio.
El archivo de índice es el sistema de recuperación
El punto incómodo: el agente empieza por `wiki/index.md`. Esa tabla de contenidos curada lista cada página con una descripción de una frase agrupada por categoría. Con esa única lectura de unos 400 tokens, el agente ya sabe qué una o dos páginas son relevantes.
El paso siguiente son una o dos lecturas dirigidas para obtener las páginas relevantes en su totalidad. Cada página tiene entre 200 y 800 tokens. La mayoría de consultas se resuelven con dos o tres lecturas y aproximadamente un millar de tokens de contenido del vault en la ventana de contexto. Es menos de lo que inyecta una configuración RAG por defecto, y el contenido es coherente (páginas completas) en lugar de fragmentado (trozos arrancados de su contexto).
Un índice mantenido hace el trabajo que realiza una base de datos vectorial en un pipeline RAG: mapea una consulta a los documentos adecuados. La diferencia es que un humano curó ese mapeo una vez, en lugar de que un modelo de embeddings lo aproxime en cada consulta.
Comparativa de tokens y costes
Para una base de conocimiento empresarial pequeña de unos 200 documentos, aquí se compara lo que cuesta una configuración RAG por defecto frente al patrón de acceso a archivos guiado por índice. Las cifras de tokens son estimaciones orientativas basadas en patrones de recuperación típicos. Las cifras de infraestructura provienen de los precios públicos de los servicios gestionados más comunes.
| Elemento | Pipeline RAG | Índice + Herramientas |
|---|---|---|
| Tokens inyectados por consulta | ~3.000 (5 a 10 fragmentos) | ~1.000 (1 lectura de índice + 1 a 2 páginas) |
| Base de datos vectorial (mensual) | 25 a 80 dólares al mes (Pinecone, Weaviate, Qdrant Cloud) | 0 $ |
| API de embeddings (inicial + actualizaciones) | 10 a 40 dólares | 0 $ |
| Re-indexación al cambiar documentos | Necesaria, tarea por lotes | Ninguna, instantánea |
| Tiempo de configuración | Días (chunking, recuperación, evaluación) | Horas (escribir un pequeño wrapper CLI) |
| Precisión en corpus pequeños | Variable, sensible a los límites de fragmento | Alta, páginas completas preservadas |
El ahorro en tokens depende de la estructura del corpus y de los patrones de consulta. El punto más importante es todo lo que desaparece de la segunda columna: sin línea de base de datos vectorial en la factura mensual, sin modelo de embeddings que mantener y sin sesiones de depuración de estrategia de chunking cuando las respuestas cambian. Para una base de conocimiento que cabe cómodamente en la cabeza de una sola persona, cada una de esas piezas móviles es sobrecarga sin beneficio correspondiente.
Lo que deja de preocupar
La forma más clara de argumentar a favor de este patrón es listar las decisiones que desaparecen:
- Estrategia de chunking. Sin debates sobre «¿dividimos por párrafo, por frase o por número de tokens?». La página es la unidad.
- Selección del modelo de embeddings. Sin proyectos de investigación comparando text-embedding-3-small con alternativas ajustadas.
- Operaciones de base de datos vectorial. Sin servicio gestionado que monitorizar, actualizar o presupuestar.
- Pipelines de re-indexación. Sin tareas nocturnas por lotes, sin mensajes de «el índice está desactualizado».
- Harness de evaluación de recuperación. Sin suite de pruebas de precisión y recall ejecutándose junto a la base de conocimiento.
- Ajuste de búsqueda híbrida. Sin pipeline BM25-más-vector-más-rerank que mantener en equilibrio.
Eso es, aproximadamente, el manual completo de operaciones RAG, eliminado. Lo que lo reemplaza es un script de shell y la disciplina de mantener un archivo de índice preciso. La disciplina es real, pero es la misma disciplina que hace valiosa una wiki para las personas en primer lugar.
Cuándo RAG sigue siendo la elección correcta
Este patrón tiene límites claros. Un índice mantenido empieza a fallar en torno a los 1.000 documentos, cuando una persona ya no puede retener la estructura en su cabeza y el archivo de índice se vuelve demasiado largo para que el agente lo recorra eficientemente en cada consulta. A partir de esa escala, los embeddings y una capa de recuperación real justifican su coste.
Otros casos en que RAG sigue siendo la herramienta adecuada:
- Corpus multimodales. PDFs con tablas, documentos escaneados, transcripciones de audio, informes con muchas imágenes. Un vault de markdown asume que todo se reduce a texto.
- Actualizaciones de alta frecuencia a escala. Cuando se indexan miles de documentos públicos que cambian cada minuto y deben ser consultables de inmediato.
- Filtrado estricto por metadatos en la recuperación. Cuando las consultas requieren filtros estructurados (rangos de fechas, autor, tipo de documento) integrados en el paso de recuperación, una base de datos vectorial con metadatos encaja mejor.
- Contenido no confiable o adversarial. Cuando el corpus proviene de muchos autores con agendas contradictorias y ninguna persona puede ser responsable de mantener un índice curado.
Para la mayoría de bases de conocimiento empresariales internas (wikis corporativas, documentación de producto, playbooks de ventas, guías de incorporación, procedimientos operativos estándar internos) ninguna de esas condiciones se cumple. El corpus es pequeño, los autores son pocos, la estructura es estable y quienes mantienen la documentación son quienes más se preocupan por su exactitud. RAG suele ser el estándar equivocado para los casos de uso más habituales.
Adecuado para la mayoría de empresas
Si usted dirige una empresa pequeña o mediana, observa su documentación existente y se pregunta cómo hacerla consultable por IA, la respuesta honesta suele ser que no se necesita una base de datos vectorial. Lo que hace falta es un archivo de índice, un script breve que lea y escriba los documentos, y un LLM con acceso a herramientas. Los componentes son todos de uso general. El trabajo está en mantener el índice actualizado.
Los proveedores de RAG como servicio no están equivocados respecto a la tecnología; el desacuerdo es sobre cuándo debe ser la arquitectura por defecto. RAG es la herramienta adecuada para problemas a una escala que la mayoría de empresas no tiene, con tipos de contenido que la mayoría de empresas no almacena. Recurrir a RAG en primera instancia puede derivar en hojas de ruta largas y costes de infraestructura recurrentes antes de cumplir el objetivo original.
webvise construye herramientas de IA internas sobre esta clase de base pragmática: conocimiento estructurado, herramientas simples, agentes que leen y escriben directamente. Si usted está evaluando un proyecto RAG para la documentación de su equipo y quiere una segunda opinión sobre si la complejidad está justificada, póngase en contacto para analizar su corpus real antes de comprometerse con la infraestructura.
Las prácticas de webvise están alineadas con las normas ISO 27001 e ISO 42001.