Documentación: Arquitectura de IA Local

1. Arquitectura de referencia

Toda solución de Belco se organiza en capas que viven enteramente dentro de la infraestructura del cliente. No hay llamadas a APIs externas para procesar datos del cliente: una consulta entra, se procesa adentro y la respuesta vuelve de forma segura.

Capas del Perímetro

• — Interfaz / aplicación: el punto de contacto del usuario (web interna, integración en una herramienta existente, API privada).
• — Orquestación: la lógica que coordina recuperación, llamadas al modelo, uso de herramientas y validaciones. Es donde vive la inteligencia del sistema.
• — Modelos de lenguaje: servicio local del modelo de lenguaje y del modelo de embeddings.
• — Base vectorial: el conocimiento corporativo indexado para búsqueda semántica.
• — Conectores: integraciones con los sistemas internos de la empresa.

2. Capa de modelos: serving, selección y cuantización

2.1 Serving

El serving es el servicio que carga el modelo en memoria y responde a las consultas. Belco utiliza motores de inferencia optimizados según los requisitos de concurrencia y la escala de la organización:

• — Inferencia optimizada: motor local eficiente para baja latencia, ideal para un nodo único y cargas corporativas medias.
• — Motor vLLM: orientado a alto rendimiento y concurrencia (batching continuo, API compatible con estándares). Se reserva para despliegues con muchos usuarios simultáneos o altos requisitos de throughput.

2.2 Selección de modelo

El modelo se elige según el caso, el idioma y el hardware disponible, no por moda. Familias de referencia:

• — Modelos de propósito general: optimizados para análisis de textos extensos, resúmenes de reportes y balances corporativos.
• — Modelos para tareas estructuradas: especializados en procesamiento multilingüe y extracción de datos en formatos estructurados (como JSON y llamadas a API).
• — Modelos de alta eficiencia: diseñados para ofrecer un óptimo equilibrio entre consumo de memoria (VRAM) y calidad de respuesta.
• — Modelos de razonamiento avanzado: orientados a tareas complejas de lógica, matemáticas y depuración de código.
• — Modelos de embeddings vectoriales locales: optimizados para la indexación y búsqueda semántica en múltiples idiomas.

2.3 Cuantización

La cuantización reduce la precisión de los pesos del modelo para que ocupe menos memoria y corra más rápido, con una pérdida de calidad pequeña y controlable. Es lo que hace posible correr modelos potentes en hardware accesible de servidor local.

2.4 Ventana de contexto

La ventana de contexto define cuánto texto puede "ver" el modelo de una vez (entrada + respuesta). Modelos actuales van de 8k a 128k tokens. Más contexto permite procesar documentos largos pero aumenta el consumo de memoria (la caché KV crece con la longitud). En RAG, una ventana moderada bien usada suele rendir mejor que forzar contextos enormes.

3. Pipeline de RAG

RAG (Retrieval-Augmented Generation) combina búsqueda sobre los documentos privados del cliente con la generación del modelo: en vez de "saber" la respuesta, el modelo la fundamenta en fragmentos recuperados de la base de conocimiento interna. Esto reduce alucinaciones, permite citar fuentes y mantiene el conocimiento actualizado sin reentrenar.

3.1 Ingesta y normalización

Lectura de las fuentes (PDF, Word, correo, HTML, bases de datos), extracción de texto y limpieza. En documentos escaneados (historias clínicas, cédulas, facturas) se aplica OCR local. Se conserva metadata útil (origen, fecha, autor, sección) para filtrar y citar.

3.2 Chunking

Los documentos se parten en fragmentos manejables. Tamaño típico: 256–1024 tokens, con solapamiento del 10–20% para no cortar ideas. La estrategia de corte (por estructura, por semántica o recursiva) se elige según el tipo de documento.

3.3 Embeddings e indexado

Cada fragmento se convierte en un vector numérico con un modelo de embeddings local y se guarda en la base vectorial. La búsqueda posterior compara la consulta con esos vectores por similitud semántica.

3.4 Recuperación y reranking

Ante una consulta se recuperan los k fragmentos más relevantes (top-k, típicamente 4–10). Se puede usar búsqueda híbrida (combinando similitud semántica con coincidencia léxica tipo BM25) y un reranker (modelo cross-encoder, p. ej. bge-reranker) que reordena los candidatos por relevancia fina antes de pasarlos al modelo.

3.5 Generación con fundamento

Los fragmentos recuperados se inyectan en el prompt junto con la consulta, y el modelo genera la respuesta apoyándose en ellos, con citas a la fuente. Un buen diseño de prompt y de instrucciones de "responder solo con lo recuperado" es clave para la fidelidad.

4. Agentes y orquestación

Un agente es un sistema donde el modelo no solo responde, sino que decide y actúa: elige qué herramienta usar, la invoca, observa el resultado y continúa hasta cumplir el objetivo.

4.1 Tool calling

El modelo expone un conjunto de herramientas (funciones) con su descripción y parámetros. Ante una tarea, decide cuál llamar y con qué argumentos; el sistema la ejecuta y devuelve el resultado al modelo. Ejemplos de herramientas: consultar una base de datos, buscar en RAG, enviar un correo corporativo, crear un registro en el CRM, generar un documento.

4.2 Patrón de razonamiento y acción

El ciclo típico alterna razonamiento y acción (estilo ReAct): el agente piensa el próximo paso, ejecuta una herramienta, observa, y repite. Se fija un límite de pasos para evitar bucles.

4.3 Memoria

• — Memoria de trabajo: el contexto de la tarea en curso (lo que cabe en la ventana de contexto).
• — Memoria de largo plazo: hechos y preferencias persistidos en la base vectorial para recuperarlos en futuras interacciones.

4.4 Guardrails

Controles que mantienen al agente dentro de límites seguros: validación de entradas y salidas, listas de herramientas y acciones permitidas, confirmación humana para operaciones sensibles (escribir, borrar, enviar correos), y límites de alcance. En un sistema que toca datos y sistemas reales, los guardrails no son opcionales.

4.5 Orquestación

La capa de orquestación coordina todo lo anterior. Puede construirse con frameworks (LangChain, LlamaIndex) o a medida cuando se busca máximo control y mínima dependencia. Belco elige según el caso, priorizando soluciones mantenibles y sin ataduras innecesarias.

5. Integraciones y conectores

El valor de la IA aparece cuando se conecta con los datos y sistemas reales de la empresa. Belco integra con las herramientas que el cliente ya usa, siempre dentro de su red.

6. Hardware e infraestructura

El consumo de memoria de GPU (VRAM) es el factor principal que determina qué modelos se pueden ejecutar y con qué rendimiento.

6.1 Dimensionamiento (regla práctica)

El consumo de memoria depende del tamaño del modelo (en miles de millones de parámetros), de la cuantización y de la longitud de contexto. Como guía orientativa, con cuantización Q4:

A esto se suma un margen para la caché de contexto y el sistema. Modelos pequeños pueden incluso correr en CPU, aunque con latencia mayor; para uso productivo se recomienda GPU.

6.2 Opciones de despliegue

• — Servidor on-premise con GPU: máximo control y privacidad; el cliente invierte en el equipamiento físico corporativo.
• — Workstation dedicada: opción de bajo costo para empezar con un caso de uso acotado o pilotos de departamento.
• — Nube privada (VPC): instancia con GPU en un entorno virtual aislado del cliente (AWS, Azure, Google Cloud VPC), cuando no se quiere hardware propio pero se exige aislamiento absoluto de datos.

7. Seguridad y privacidad

La seguridad es el cimiento de la arquitectura de Belco. El sistema se diseña para que la información corporativa permanezca contenida y controlada.

7.1 Aislamiento de red

Los componentes corren en la red del cliente sin necesidad de salida a internet para procesar datos. Según el caso, se puede operar en un entorno totalmente aislado (air-gapped) o en una VLAN sin egreso hacia servicios externos.

7.2 Control de acceso

Autenticación integrada con los sistemas del cliente (directorio corporativo / Active Directory / Single Sign-On) y control de acceso por roles (RBAC), de modo que cada usuario vea y haga solo lo que le corresponde por área.

7.3 Cifrado

Cifrado de las comunicaciones internas (TLS) y de los datos en reposo (disco y base de datos vectorial), más una gestión adecuada de secretos y credenciales de conectores.

7.4 Auditoría y trazabilidad

Registro de accesos y acciones, con cuidado de no filtrar datos sensibles en los propios logs. La trazabilidad permite demostrar cumplimiento y reconstruir qué pasó.

7.5 Hardening

Endurecimiento del servidor y de los servicios: mínimo de software expuesto, actualizaciones de seguridad, principio de mínimo privilegio y revisión periódica.

8. Evaluación y monitoreo (calidad)

La calidad de una solución de IA se mide y se vigila, sobre todo porque los modelos y los datos corporativos cambian con el tiempo.

8.1 Conjunto de evaluación

Se arma un set de casos representativos (preguntas y respuestas esperadas, documentos de prueba) que sirve de referencia para medir y para detectar regresiones cuando se actualiza un modelo o se cambia la configuración.

8.2 Métricas de recuperación (RAG)

• — Recall@k: qué proporción de la información relevante aparece entre los k fragmentos recuperados.
• — Precisión / MRR: qué tan arriba en la lista de resultados aparece lo verdaderamente relevante.

8.3 Métricas de generación

• — Fidelidad (groundedness): la respuesta se sostiene únicamente en lo recuperado, sin inventar información de contexto.
• — Relevancia: la respuesta contesta de forma precisa lo que se preguntó.
• — Evaluación por modelo (LLM-as-judge) y revisión humana para criterios de calidad cualitativos.

8.4 Monitoreo en producción

Se vigilan latencia, throughput, uso de GPU, tasa de errores y volumen de uso. Se captura feedback de los usuarios para mejorar de forma continua. El monitoreo respeta la privacidad: métricas de sistema sí, contenido sensible de prompts solo lo imprescindible.

9. Operación y mantenimiento

El mantenimiento de entornos de IA privados sigue directrices de estabilidad estricta.

• — Versionado de modelos: se fija (pin) la versión del modelo en producción y las actualizaciones se prueban antes de aplicarse con evaluaciones de regresión.
• — Backups: respaldo de la base vectorial, de las bases de datos relacionales, las configuraciones y los datos del sistema.
• — Actualizaciones: de modelos locales, dependencias de código y parches de seguridad de sistema operativo, en ventanas de mantenimiento acordadas.
• — Niveles de Soporte (SLA): niveles de servicio definidos según la criticidad de la solución para la operación de la empresa.

10. Stack tecnológico

Componentes tecnológicos de referencia elegidos por estabilidad, escalabilidad local y ausencia de dependencias externas.

A. Glosario técnico

B. Preguntas frecuentes