⌘J
En esta página 6

Engineering / Capa LLM (AxelCopilot)

Capa LLM (AxelCopilot)

La capa de intención sobre el motor determinista (redacción conversacional, consulta NL de cartera y análisis), con guardrails que hacen imposible que el LLM toque la DB.

Diseño aprobado, aún no implementado (sub-proyecto #4, spec preliminar). El PoC simula la IA con regex sobre frases demo; lo de abajo es cómo está diseñada la capa LLM real. El repo tiene 0 PRs mergeados. La librería detrás de la interface se decide en un spike (inclinación a la API nativa de Anthropic).

El principio que gobierna toda la capa:

Intención = LLM, verdad = motor determinista.

El LLM nunca afirma validez jurídica ni escribe el contrato: esa la da el motor. El LLM interpreta lo que el usuario quiere y lo explica; el motor valida y escribe.

El LLM no es el moat: es la capa de intención sobre el motor determinista (la verdad). El moat real es el corpus jurídico-laboral salvadoreño curado, el producto integrado y la distribución. Esto es lo que separa a Axel de “un wrapper de ChatGPT que redacta contratos”.

AxelCopilot: una UI, N extractores

Las tres capacidades de la capa LLM son colectivamente AxelCopilot: una experiencia conversacional, no un chat por vertical. La UI de chat es genérica y reutilizable; solo el IntentService se parametriza por dominio.

UI de chat (UNA sola, genérica, reutilizable)


IntentService (interface agnóstica de proveedor Y de dominio)

         ├── extractor laboral   → parámetros de contrato (hoy)
         ├── extractor permisos  → parámetros de trámite (futuro, #7)
         └── extractor marcas    → parámetros de registro (futuro, #8)

El error a evitar: un chat aislado y acoplado a lo laboral que obligaría a construir PermisosNewConversational, MarcasNewConversational… cada uno reinventando la mecánica conversacional. Lo que cambia por vertical son los extractores/diccionarios (datos y reglas), no un chat nuevo.

Las tres capacidades

1. Redacción conversacional

Texto libre (“contrato indefinido para Juan Pérez, motorista, $500, empieza el lunes”) → el LLM extrae intención a JSON params → el motor valida y añade cláusulas automáticas. El LLM no escribe el contrato.

2. Consulta NL de cartera

Pregunta en lenguaje natural (“¿cuántos contratos vencen este mes?”) → el LLM propone un query plan → un query builder seguro lo ejecuta con scope de tenant forzado. El LLM nunca toca la DB.

3. AxelPanel con LLM (análisis)

El motor determinista produce los findings (“salario por debajo del Art. 144”, “prueba excede Art. 28”). El LLM toma esos findings + el contrato y genera la explicación NL, las recomendaciones y las citas, con estado “thinking” real vía streaming. El LLM no inventa findings ni sentencias: solo explica los del motor. Si el motor no halla nada, el LLM no añade.

Guardrails

El punto más riesgoso es la consulta NL (LLM → DB). El diseño hace estructuralmente imposible que el LLM toque datos directamente.

LLM propone, query builder ejecuta

El LLM produce un query plan (campos, filtros, agregación), no SQL. Un Eloquent query builder lo ejecuta con whitelist de tablas/columnas y scope de tenant forzado. No hay path donde el LLM escriba SQL crudo.

Citas solo desde Citations

El LLM referencia IDs de Citations (source único: Código de Trabajo + corpus curado de sentencias), nunca texto libre. Anti-alucinación por construcción: no puede citar un artículo o sentencia que no exista.

Cada interacción se audita para trazabilidad:

ai_interactions    id, tenant_id, user_id, type (draft|query|analysis),
                   input, output, tokens, latency, timestamps
ai_guardrail_logs  id, interaction_id, action, blocked (bool), reason

Proveedor tras la interface

IntentService es el seguro anti-migración: la app le habla a la interface, y del otro lado puede haber Claude, GPT, Gemini o un orquestador de agentes sin que el resto sepa. Migrar de proveedor es escribir un GeminiIntentService, no re-escribir el producto.

La API key vive en los environment secrets de Laravel Cloud, nunca en cliente. La librería detrás de IntentService se decide en un spike, con inclinación a la API nativa de Anthropic: su structured output nativo es GA con garantía server-side, y su failover automático entre modelos es un anti-feature en ruta legal (un swap silencioso de modelo podría cambiar la interpretación de una extracción). En legal se degrada a formulario manual, no a otro modelo.

Corpus curado de jurisprudencia: P0

Hay que distinguir dos cosas fáciles de confundir:

AlcanceEstado
Corpus curado de sentencias claveUn set acotado de fallos clave de la CSJ (decenas), vinculados a cada cálculo del motor (finiquito, indemnización Art. 58, salario base).P0, dentro del MVP
RAG full sobre toda la jurisprudenciaBúsqueda conversacional amplia sobre el universo de fallos.Post-MVP
El corpus curado es trabajo legal, no ingeniería

El corpus curado es trabajo de curaduría legal (semanas de trabajo jurídico, no de ingeniería). Vive en Citations junto al Código de Trabajo y es lo que permite que el copilot razone y cite la sentencia de verdad, no solo el artículo. Es parte del moat.

Gate de “hecho”

Test de penetración de guardrails

El LLM no puede generar SQL crudo, ni modificar datos, ni acceder a otro tenant. Se prueban intentos de SQL injection y acceso cross-tenant: todos bloqueados.

Consistencia motor vs LLM

El LLM SIEMPRE ve los findings del motor antes de responder: no opina sin el motor. Latencia objetivo <5s, con streaming para el análisis largo.