¡Hola Devs! Vamos a ver el problema real
Toda empresa grande tiene el mismo cuello de botella: el conocimiento más valioso vive en la cabeza de la gente. Las revisiones de compliance toman días, las mismas preguntas aparecen en cientos de evaluaciones de producto, y la inconsistencia entre expertos genera riesgo de verdad.
La solución instintiva — hacer fine-tuning del modelo con datos de los expertos — es caro, opaco y lento. Un mejor enfoque trata la base de conocimiento como código fuente y el modelo como compilador: mantén la complejidad en archivos de texto legibles por humanos y agentes, no en los pesos del modelo.
La arquitectura de abajo viene de un sistema en producción en un dominio de compliance, pero el patrón se generaliza a finanzas, seguridad y revisión de estándares de ingeniería.
Cuatro capas, cada una resolviendo un problema
| Capa | Responsabilidad |
|---|---|
| Sistema de conocimiento | El 'segundo cerebro' organizacional — posiciones curadas, taxonomía, índices de ruteo |
| Capa de razonamiento | 'Recetas' componibles que prescriben cómo analizar, no qué saber |
| Framework de evaluación | Bloquea todo cambio propuesto con replay dirigido + pruebas de regresión |
| Loop de mejora | Compila feedback de expertos en ediciones verificadas y versionadas |
Quita cualquier capa y las demás se degradan. Este es el insight que la mayoría de los sistemas RAG se pierden: retrieval solo no captura razonamiento.
La capa de conocimiento: archivos por encima de embeddings
En lugar de meter documentos en un vector store y esperar que la búsqueda semántica encuentre el chunk correcto, pre-extrae el conocimiento en una taxonomía estricta de 200+ archivos:
- Archivos de posición — posturas organizacionales autoritativas con restricciones e implicaciones de ruteo accionables por máquina
- Archivos de taxonomía / vocabulario — fuente única de verdad para tipos de entidad y niveles de clasificación
- Índices de ruteo — mapeo determinístico de características de entrada a posiciones aplicables
- Archivos de gateway — pruebas de umbral que el agente debe pasar antes de entrar a un dominio
Cada archivo declara sus dependencias en frontmatter YAML:
# position_file.yaml
id: pos-2024-compliance-marketing-claims
version: 3.2
depends_on:
- taxonomy/entity-types.yaml
- vocabulary/claim-categories.yaml
referenced_by:
- recipes/assess-marketing-claim.yaml
- routing/index-marketing.yaml
constraints:
- "Aplica solo a claims orientados al consumidor"
- "Reemplaza pos-2023-marketing-claims"
Esto forma un grafo de dependencias bidireccional. Cuando un archivo cambia, rastreas exactamente qué se rompe — y eso es lo que hace viable la edición automatizada.
Particionamiento por densidad
No todo pertenece a la wiki. Divide por densidad de información × frecuencia de uso:
- Alta densidad + alta frecuencia → wiki (consultado casi en cada turno)
- Esparso + situacional → retrieval RAG (profundo pero raramente necesario)
El razonamiento central del agente queda anclado en conocimiento refinado y actual, pero aún alcanza evidencia de apoyo cuando el escenario lo exige.
Recetas: separando el 'qué' del 'cómo'
Los archivos de conocimiento son declarativos. Las recetas son imperativas. Una receta prescribe un workflow analítico multi-paso — qué examinar primero, qué conocimiento cargar en cada paso, qué procedimientos de decisión seguir.
La decisión crítica de diseño: las recetas referencian archivos de conocimiento pero no contienen hechos de dominio; los archivos de conocimiento declaran posiciones pero no prescriben procedimientos.
Esto te da atribución limpia de fallas:
- Conclusión incorrecta a pesar de materiales fuente correctos → problema de receta
- Procedimiento correcto pero faltan hechos → laguna de conocimiento
- Expertos no coinciden en la respuesta → ambigüedad, escala a humano
Divulgación progresiva corta tokens en ~80%
Versiones iniciales cargaban un archivo plano de instrucciones con todo vía búsqueda semántica. Después de reestructurar en etapas guiadas por receta, cada query toca solo un subconjunto pequeño y dirigido. Las context windows son finitas y la atención se degrada con el volumen — entregar las instrucciones correctas en el momento correcto mejora directo la calidad del razonamiento.
El flywheel de auto-mejora
Esta es la parte que la mayoría de los equipos se salta. El loop tiene cuatro fases:
- Diagnosticar — extrae señales de los traces de conversación con expertos, luego aplica una única prueba de atribución: ¿El agente podría haber llegado a la conclusión correcta desde sus materiales fuente?
- Compilar — sub-agentes analizan impacto en paralelo (referencias cruzadas, conflictos, presupuesto de tokens, cobertura de tests). Un revisor adversarial independiente corre en contexto fresco, sin saber la justificación — solo ve los diffs propuestos.
- Evaluar — replay dirigido en el escenario original (con juez ciego) + pruebas de regresión en el benchmark del dominio.
- Aterrizar — un humano revisa una corrección probada, no una falla cruda. El escenario que fallaba se agrega a la suite de regresión permanentemente.
Cada corrección sube la barra para cambios futuros. El esfuerzo del experto compone.
Limitaciones y cuidados
- El costo inicial es real. Construir 200+ archivos estructurados con grafo de dependencias toma semanas. Solo compensa si el dominio tiene preguntas recurrentes y de alto riesgo.
- No es para creatividad abierta. Este patrón sirve dominios gobernados por texto recuperable y posiciones estables. Va a pelear contigo en trabajo creativo que cambia rápido.
- Los checkpoints humanos son innegociables. El sistema acelera expertos; no reemplaza su autoridad. Calibra los checkpoints a la tolerancia a riesgo del dominio.
- La revisión adversarial se puede burlar. Si el agente revisor comparte cualquier contexto con el proponente, los puntos ciegos se propagan. Mantén contextos estrictamente aislados.
¿Para dónde ir ahora?
Si estás evaluando esto para tu empresa, empieza por la prueba de atribución — es la unidad útil más pequeña. Toma una corrección recurrente de experto y pregunta: ¿fue laguna de conocimiento, falla de receta o ambigüedad genuina? Esa única pregunta te dirá si tu sistema necesita capa de conocimiento, capa de razonamiento o camino de escalación humana.
Para una perspectiva complementaria sobre los límites de los LLMs en contextos de evaluación, checa nuestro análisis de la suposición de surrogacy en pruebas A/B con LLM. Y si estás siguiendo dónde las features nativas de plataforma reemplazan capas de tooling, CSS @function está silenciosamente haciendo con Sass lo que esta arquitectura hace con fine-tuning.
La conclusión
El principio profundo es simple: mantén la complejidad en archivos de texto legibles por humanos y agentes, no en pesos de modelo fine-tuneado. Cada mejora es un diff que un experto de dominio revisa en 30 segundos. Cada cambio es versionado, diffeable, reversible.
El pipeline de compilación es sofisticado, pero sus salidas siempre son transparentes. Ese es el trade: complejidad de ingeniería en el pipeline, simplicidad radical en los artefactos.
Si tu empresa tiene conocimiento tribal que se va por la puerta, esta arquitectura merece una mirada seria.