Inteligencia artificial

Estado actual en una líneaCopy Anchor Link

Hoy el chat de la Academia funciona así: block_ai_chat (interfaz) → local_ai_manager (proveedor, cuotas, registro) → Groq por su API compatible con OpenAI, sin servicio intermedio. La plataforma RAG con Dify de la Fase 5 no está desplegada.

Navegador (botón ✦ y panel flotante)
   │
   ▼
block_ai_chat v1.0 ──► local_ai_manager v1.1 (submit_query.php)
                          │  parche 1: ai_role_injector → agrega el perfil del usuario al prompt de sistema
                          │  parche 2: ai_agent → si el mensaje es una acción de gestión, la resuelve
                          │            con function-calling (modelo openai/gpt-oss-120b);
                          │            cédulas, RUC y correos viajan como marcadores
                          ▼
                 Conector "chatgpt" (formato OpenAI)
                          │  https://api.groq.com/openai/v1/chat/completions
                          ▼
                 Groq · modelo openai/gpt-oss-20b · temperatura 0.2

ComponentesCopy Anchor Link

Proveedor y modelosCopy Anchor Link

La clave se toma de la variable de entorno GROQ_API_KEY. moodle-config.sh ejecuta configure-ai-groq.php en cada despliegue cuando la variable está definida (paso crítico, antes de las cuotas de IA): crea o actualiza la instancia con esa clave. Para cambiar la clave basta con actualizar GROQ_API_KEY en Coolify y hacer Redeploy. Si la variable no está definida, el paso no corre y se conservan la instancia y la clave guardadas en la base de datos (por ejemplo, una clave cambiada en Configuración IA → Ajustes técnicos). Groq reemplazó a Gemini, que daba errores intermitentes por alta demanda en el nivel gratuito; configure-ai-manager.php y GEMINI_API_KEY quedan de esa configuración anterior.

Si Groq retira un modelo (respuesta 404), se consulta la lista de modelos disponibles de su API y se ajusta el nombre en la instancia y en las constantes del código.

Niveles y cuotas por perfilCopy Anchor Link

local_ai_manager v1.1 tiene tres niveles. ai_tiers asigna el nivel según el rol de sistema de cada persona (el mayor si tiene varios), al crear la cuenta o cambiar el cargo y en cada despliegue (configure-ai-quotas-and-persona.php).

El periodo de la cuota es de 24 horas y lo reinicia el cron (si el cron no corre, la cuota no se reinicia). Se respetan los cambios hechos a mano en Configuración IA y nunca se desbloquea a quien fue bloqueado a mano. El chat global está disponible en todas las páginas para cualquier usuario con sesión (parche patch-ai-chat-everywhere.php), dentro de su cuota.

Quién no tiene chat:

• Visitantes sin sesión e invitados.
• Postulantes (rol delta_postulante y el agente lo excluye).
• Cualquier persona mientras rinde un examen (intento y resumen).

Persona del asistenteCopy Anchor Link

La persona "Deltamontero — Asistente Academia" es una plantilla visible para todos los bloques, con un prompt de sistema que establece:

• Transparencia: es un asistente automatizado, no una persona.
• Alcance: solo la Academia (módulos, contenidos, uso de la plataforma, rutas, avance y evaluaciones).
• Límites de autoridad: no toma decisiones vinculantes ni promete accesos, notas, certificados o plazos; explica procesos pero no los ejecuta.
• Escalamiento a Talento Humano en problemas de cuenta, quejas o pedido de hablar con una persona (salvo que quien pregunta sea de Talento Humano o administración).
• Orientación por perfil y un mapa de ubicaciones de la plataforma, para no inventar menús ni direcciones. El mapa indica que se entra con el usuario o el correo y explica las dos formas de recuperar la contraseña desde ¿Olvidó su contraseña?: por correo (enlace de un solo uso que vence en 1 hora) o, sin correo, con el usuario y la cédula (contraseña temporal). Las cuentas que administran la Academia no se recuperan desde ahí.

ai_role_injector agrega en cada petición una línea con el perfil real del usuario, calculada en el servidor; así el modelo adapta su orientación sin poder conceder accesos. El historial de contexto se amplía a 50 mensajes en cada despliegue; las conversaciones se guardan y cada persona puede borrar una conversación desde el panel.

Agente de accionesCopy Anchor Link

Para quien tiene moodle/user:create (en la práctica, Talento Humano y administradores), el chat también ejecuta acciones. Regla de diseño: la IA propone, Moodle dispone.

• Cada herramienta se ejecuta como el usuario con sesión, sin escalar privilegios, y vuelve a validar sus permisos en el servidor.
• Las acciones de escritura muestran primero un resumen y exigen confirmación; la confirmación ("sí") la resuelve el código, no el modelo.
• Herramientas de lectura: buscar_usuario, avance_de_usuario, pendientes_de_curso, generar_reporte, reporte_formacion, menu_reportes (las de reportes requieren local/deltamodules:viewreports).
• Herramientas de escritura: guia_crear_usuario, crear_colaborador, asignar_cargo, asignar_cedula, matricular_en_cohorte, resetear_contrasena.

Condiciones de usoCopy Anchor Link

Antes de usar el chat, cada persona acepta las Condiciones de uso del Asistente de IA (versión, resumen de puntos y acuerdo completo). Se editan en Configuración IA; publicar una versión nueva obliga a aceptarlas otra vez, y la aceptación se puede dejar de pedir. El texto inicial informa que los mensajes se envían a un proveedor externo que puede procesarlos fuera del Ecuador y que no se deben incluir datos personales de terceros ni información confidencial. Debe validarlo Talento Humano con asesoría legal (LOPDP).

Frontera de datos con el proveedorCopy Anchor Link

En el agente de acciones, las cédulas (10 dígitos), los RUC (13 dígitos) y los correos no viajan a Groq. Antes de enviar el mensaje, el historial y el resultado de cada herramienta, el código los reemplaza por marcadores (CEDULA_1, RUC_1, correo1@dato.oculto). La tabla que relaciona cada marcador con el dato real vive solo en la sesión de la plataforma; el modelo trabaja con los marcadores y Moodle vuelve a poner el dato real al ejecutar la herramienta y en la respuesta que ve la persona.

El proveedor externo y lo que se le envía están declarados en el proveedor de privacidad de local_deltamodules (ubicación externa groq). La brecha G-2 de docs/roadmap_v4_gaps.md exige además la aprobación legal por escrito de esta frontera (Groq procesa fuera del Ecuador): estado de la revisión legal Por confirmar. Por eso las condiciones de uso siguen pidiendo no escribir datos personales de terceros ni información confidencial.

Configuración IACopy Anchor Link

Página de Administración del sitio para quien tiene local/ai_manager:manage (Socios, Jefe de Talento Humano, Administrador Técnico y super administrador):

• Resumen: activar o desactivar el Asistente, estado de las condiciones y de las aceptaciones, proveedor y modelo en uso.
• Condiciones de uso: edición y versiones.
• Aceptaciones: quién aceptó y quién falta, con descarga.
• Ajustes técnicos: las páginas de local_ai_manager (proveedor y modelo, propósitos, límites, estadísticas).

Servicio MCP para administraciónCopy Anchor Link

Además del chat de usuarios, existe un acceso técnico por MCP (Model Context Protocol) para que un cliente MCP externo consulte y gestione la plataforma en lenguaje natural. No es el chat de los usuarios.

Lo crea y mantiene setup-mcp-service.php en cada despliegue (paso crítico); el token no se imprime completo. La superficie del agente es exactamente la lista de funciones del servicio.

Plan de la Fase 5: RAG con DifyCopy Anchor Link

El objetivo es que el asistente responda con el contenido de los cursos y enlace al segundo exacto del video. El plan vigente (docs/roadmap.md) reemplazó al servicio propio con FastAPI y ChromaDB por Dify, una plataforma LLMOps de código abierto autoalojada.

lms-course-scrap (scraper) ──► chunks.jsonl en almacenamiento de objetos
                                      │
          local_dify_sync (tarea programada + observadores de eventos en el cron de Moodle)
                                      │  API de la base de conocimiento de Dify
                                      ▼
block_ai_chat → local_ai_manager → Dify (RAG, historial, prompt) → proveedor LLM
                                     ├─ LLM: Groq u otro, cambiable por interfaz
                                     ├─ Embedding: bge-m3 (fijo; cambiarlo obliga a re-indexar)
                                     └─ Reranker: opcional

Principio de portabilidad de proveedor (docs/roadmap.md §2):

1. Moodle habla siempre con un solo endpoint compatible con OpenAI (Dify); el cambio de proveedor ocurre dentro de Dify, sin tocar Moodle.
2. La fuente de verdad del RAG es texto más metadatos sin vectores (chunks.jsonl); los vectores son derivados y se regeneran con cualquier proveedor de embeddings.
3. El contrato hacia los proveedores es la API compatible con OpenAI.

Pendientes y riesgos documentados:

Alternativa preparada en el repositorioCopy Anchor Link

Existe una base para un RAG dentro de la misma MariaDB: la tabla local_deltamodules_chunks y el script import-rag-chunks.php, que genera embeddings con la API de Gemini. El propio script indica que no debe ejecutarse todavía, y ningún componente del chat consulta esa tabla. Su relación con el plan de Dify: Por confirmar.

Repositorio hermano lms-course-scrapCopy Anchor Link

Pipeline independiente en Python y Jupyter que extrae el contenido de los videos de la Academia y produce tres artefactos:

Estado según la documentación: extracción completa del piloto (Módulo 1); falta el catálogo completo (Google Drive, TikTok y temas sin enlace) y publicar los artefactos en almacenamiento de objetos. Este repositorio consume los artefactos; no los genera. El contenido generado por IA debe pasar revisión humana antes de publicarse.