El problema que resuelve
Los clasificadores de árboles de decisión siguen siendo útiles en Zeropithos porque son interpretables, baratos en inferencia y fáciles de auditar. Su cuello de botella no es la inferencia, sino el entrenamiento: en cada nodo, el algoritmo clásico evalúa candidatos de split por feature, comparando umbrales para minimizar la impureza. En datasets grandes y de alta dimensión, esa búsqueda exhaustiva se vuelve prohibitiva, sobre todo si el árbol se reentrena con frecuencia para routing, clasificación de consultas o detección de riesgos. DICS propone reducir ese espacio de búsqueda mediante Data-Informed Centroid Splitting: en lugar de probar todos los umbrales, genera un conjunto limitado de candidatos a partir de la geometría de los datos, especialmente centroides condicionales a la clase. El resultado es un árbol más rápido de entrenar, con una pérdida de calidad controlada y una trazabilidad clara: cada split puede explicarse como una separación local entre grupos de datos.
Arquitectura y mecanismo (con detalle técnico)
El mecanismo central de DICS es una aproximación geométrica a la búsqueda de splits. En un nodo binario, el objetivo es encontrar una partición que separe mejor las clases. Un árbol clásico, para cada feature j, ordena los valores y evalúa umbrales o particiones candidatas. DICS sustituye esa enumeración por una generación de candidatos informada por los datos.
En una implementación práctica, para cada nodo S con etiquetas y_i, se calculan centroides por clase, μ_+ y μ_-, ponderados por la frecuencia de las muestras. La diferencia v = μ_+ - μ_- define una dirección discriminativa local. Para mantener árboles axis-aligned e interpretables, se proyecta esa dirección sobre las coordenadas y se seleccionan las features con mayor separación, usando una razón de Fisher local:
r_j = (μ_{+,j} - μ_{-,j})^2 / (σ_{+,j}^2 + σ_{-,j}^2 + ε).
Los candidatos de split se construyen alrededor del punto medio t_j = (μ_{+,j} + μ_{-,j}) / 2, añadiendo cuantiles locales o offsets para capturar distribuciones no gaussianas. Si el nodo es heterogéneo, pueden usarse centroides de clusters intraclase, para que el split no dependa solo de una media global dominada por outliers.
El presupuesto de cómputo se controla con B: número máximo de candidatos evaluados por nodo. Por ejemplo, se evalúan 16, 32 o 64 candidatos en vez de miles de umbrales. Para cada candidato se calcula la ganancia de impureza y se elige el mejor. Si la ganancia máxima es baja o la separación entre centroides es insuficiente, el nodo se convierte en hoja o se detiene por profundidad. Esta estrategia conserva la inferencia por traversal, pero reduce el entrenamiento de una búsqueda exhaustiva por nodo a una evaluación acotada por B, más el coste de estimar centroides y varianzas.
Qué lo hace genuinamente nuevo
La novedad de DICS no está en usar un árbol de decisión, sino en reformular la búsqueda del split como selección de candidatos guiada por la geometría local de las clases. Los métodos rápidos clásicos suelen basarse en muestreo aleatorio de umbrales, cuantiles fijos o heurísticas que no aprovechan la estructura semántica de las etiquetas. DICS usa información condicional: los centroides de las clases dentro del nodo definen dónde es más probable que exista una frontera útil. Eso lo diferencia de una proyección aleatoria o de una reducción de dimensionalidad genérica, porque el candidato se genera para maximizar la separación de las clases presentes en ese subconjunto.
Además, mantiene una propiedad valiosa en sistemas de producción: interpretabilidad. El split sigue siendo una comparación simple sobre una feature, por lo que puede auditar un ingeniero. Permite explicar por qué una consulta fue clasificada de cierta manera: el nodo seleccionó una feature con alta separación entre centroides y un umbral cercano al punto medio de esas distribuciones. En un corpus como AMASE, donde los metadatos de papers, repositorios y datasets tienen clases discretas, eso es especialmente útil para depurar decisiones del RAG.
Cómo integrarlo en Zeropithos o Dibroclaw (componente concreto: RAG, BDI, knowledge graph, inferencia, seguridad + pasos de implementación)
El componente más natural es el RAG de Dibro: un clasificador DICS como router y filtro de riesgo antes y después de la recuperación. En lugar de enviar toda consulta directamente a llama-server, el pipeline usa un árbol DICS para clasificar la intención, el tipo de fuente requerida y el nivel de riesgo. Clases útiles: spqr, vector_search, code_repo, paper_summary, security_review, human_escalation. El árbol consume features baratas: embeddings de la consulta, longitud, entidades, URLs, tokens de riesgo, idioma y metadatos del usuario.
Pasos de implementación:
1. Extraer ejemplos etiquetados desde Fuseki/SPARQL o logs de RAG. Etiquetar por intención final: si se resolvió con SPARQL, búsqueda vectorial, código, seguridad o escalado.
2. Construir dataset Parquet con features numéricas. Usar embeddings cacheados o un modelo pequeño; no es necesario usar el LLM grande para entrenar el árbol.
3. Entrenar DICS con B=32, profundidad máxima 8-12 y min samples por hoja 20-50. Prototipar en Python y portar la inferencia a Rust.
4. Exportar el árbol a JSON o binario y servirlo con Axum dentro del RAG. La inferencia debe ser de pocos milisegundos, suficiente para routing.
5. Integrarlo en el BDI: la salida actualiza la belief sobre la estrategia de recuperación; la intención ejecuta SPARQL, busca en HuggingFace/GitHub o llama al LLM.
6. Añadir seguridad: si detecta prompt injection, exfiltración o contenido malicioso, se bloquea la acción o se fuerza revisión humana. Registrar nodo, feature y umbral para auditoría.
Retos prácticos (VRAM, datos, dependencias)
El principal reto no es VRAM: DICS es CPU-friendly y no requiere GPU para el árbol. La GPU de 32GB puede usarse para embeddings o para el LLM posterior, pero el clasificador corre en CPU con memoria modesta. El reto real es la calidad de las etiquetas: si las intenciones del RAG están mal etiquetadas, el árbol aprenderá rutas equivocadas. Se necesita reetiquetado periódico, con reglas SPARQL y revisión humana para casos de seguridad. También hay que controlar la dimensionalidad: si se usan embeddings de 384 o 768 dimensiones, conviene aplicar PCA, SVD o selección de features para evitar sobreajuste. Dependencias mínimas: Rust con ndarray, polars, serde, axum y parquet; opcionalmente Python para prototipado. En producción, el modelo debe versionarse con métricas de precisión por clase, latencia p95 y tasa de escalado humano.
Conclusión
DICS es una mejora práctica para árboles de decisión en entornos donde el entrenamiento debe ser rápido pero la decisión debe ser auditable. Para Zeropithos, su mayor valor no es sustituir al LLM, sino reducir el coste de decisiones operativas: routing de consultas, selección de fuentes, clasificación de riesgo y actualización de beliefs en el BDI. Integrado con Fuseki, RAG y la infraestructura de seguridad de Dibro, puede convertirse en una capa ligera y explicable que protege el pipeline antes de que llegue a componentes más costosos.