Arquitectura de referencia: Enrutador de ingesta de documentos¶
Los pipelines de RAG generalmente tratan cada documento de la misma manera: lo fragmentan, lo vectorizan, lo indexan. Eso funciona bien hasta que razonas sobre un corpus donde una especificación de ingeniería controlada, un hilo de Slack y un registro de telemetría en bruto terminan con el mismo peso en la recuperación — aunque tienen un valor de verdad muy distinto y una vida útil muy distinta.
El Enrutador de ingesta de documentos (licencia MIT, código abierto) es una arquitectura de referencia que vale la pena estudiar precisamente por este problema. Varias de sus ideas informan directamente cómo ctxEco piensa la ingesta.
Clasificación por valor de verdad¶
Los documentos se clasifican antes de la extracción, no después:
| Clase | Valor de verdad | Decaimiento | Ejemplos |
|---|---|---|---|
| A | Verdad inmutable | Muy lento | Especificaciones, normas, manuales |
| B | Flujo efímero | Moderado | Correos, presentaciones, páginas wiki |
| C | Pulso operativo | Rápido | Registros, CSV, telemetría |
La idea clave no es la taxonomía de tres categorías en sí — es que la tasa de decaimiento es una señal de recuperación de primera clase, no una ocurrencia tardía. Una norma de ingeniería de cinco años y una línea de registro de cinco minutos no deberían competir en igualdad de condiciones solo porque ambas coincidieron con la incrustación de la consulta. Una recuperación consciente de qué tan rápido decae el valor de verdad de un documento clasifica de forma notablemente mejor que una que trata cada fragmento como igualmente duradero.
Recuperación híbrida, fusionada¶
La capa de búsqueda del proyecto (TriSearch™) combina búsqueda por palabras clave, búsqueda vectorial y una capa de conocimiento de grafo construida a partir de la co-ocurrencia de entidades nombradas, fusionando las tres mediante Fusión de Rango Recíproco. La búsqueda por palabras clave por sí sola pierde coincidencias semánticas; la búsqueda vectorial por sí sola pierde identificadores exactos (números de parte, códigos de error, IDs de caso) que la búsqueda por palabras clave encuentra trivialmente. Fusionar múltiples modalidades de recuperación — en lugar de elegir una y vivir con sus puntos ciegos — es un patrón que vale la pena adoptar sin importar qué base vectorial o motor SQL haya debajo.
Control de acceso como restricción de diseño de primera clase¶
El proyecto implementa un alcance de acceso a nivel de recurso (privado / equipo / proyecto / inquilino) aplicado en la capa de consulta, y mapea sus controles explícitamente a marcos reconocidos (NIST AI RMF, FedRAMP). Documentar ese mapeo como parte de la arquitectura — no como un documento de cumplimiento agregado después — es en sí un hábito útil: obliga a que el modelo de acceso sea lo suficientemente preciso como para declarar qué control satisface, no solo ser vagamente "seguro".
Dónde termina la referencia y comienza la plataforma¶
ctxEco no ejecuta el código de este proyecto directamente — las decisiones propias de la plataforma sobre aislamiento de inquilinos, aplicación de políticas y sustrato de recuperación siguen una arquitectura distinta. Lo que sí tomamos: el concepto de clasificación más decaimiento, el patrón de extracción enrutada por tipo de documento, y la recuperación híbrida con fusión de rango, todo reimplementado sobre la propia pila de ctxEco. Esa es la forma correcta de usar una arquitectura de referencia sólida — estudiar las ideas, verificarlas contra tus propias restricciones, y construir la versión que realmente encaja en tu sistema.
Si estás estudiando arquitectura de recuperación, vale la pena leer directamente el repositorio de DIR y su artículo publicado: github.com/derekbmoore/documentIngestionRouter.