Integrar un modelo local en una aplicación de backend no exige incorporar un SDK adicional. En Orbi, una plataforma de comercio y entregas construida con .NET, ASP.NET Core y PostgreSQL, el backend establece una comunicación HTTP directa con Ollama y conserva el control de todo el intercambio.
La integración tiene dos usos: un asistente contextual que responde con datos autorizados de la aplicación y un servicio preparado para generar sugerencias breves. El reto no consiste únicamente en obtener texto del modelo, sino en controlar el contexto que recibe, transmitir la respuesta progresivamente y reducir el riesgo de que genere información no respaldada por el negocio.
1. Arquitectura de la integración
Cuando una persona envía una consulta desde el navegador, el controlador de ASP.NET Core identifica su sesión, rol y pantalla actual. Con esa identidad, el backend consulta en PostgreSQL únicamente los registros autorizados y los agrupa como contexto de solo lectura. Un servicio especializado envía la pregunta y ese contexto a Ollama, que devuelve fragmentos de respuesta para retransmitirlos progresivamente al navegador. Antes de entregar el resultado final, una segunda etapa revisa el borrador y busca contradicciones con la información autorizada.
Este diseño mantiene a PostgreSQL fuera del alcance del modelo. ASP.NET Core conserva la autorización y transforma los datos permitidos en contexto, de modo que la IA no decide qué información existe ni quién puede acceder a ella.
La integración puede resumirse así:
| No. | Etapa | Responsabilidad | Control aplicado |
|---|---|---|---|
| 1 | Identidad | Reconocer usuario, rol y pantalla activa. | Claims y autorización. |
| 2 | Contexto | Consultar solo información permitida. | Consultas filtradas. |
| 3 | Generación | Enviar contexto autorizado al modelo local. | Prompt acotado. |
| 4 | Revisión | Comprobar el borrador antes de responder. | Validación de contradicciones. |
| 5 | Entrega | Transmitir la respuesta al cliente. | Cancelación y envío inmediato. |
2. Preparación del entorno
Modelo local y comunicación
Orbi utiliza un modelo pequeño de la familia Qwen porque ofrece un equilibrio práctico entre capacidad y consumo de recursos para ejecución local. Ollama funciona como servicio independiente y expone una interfaz HTTP local para recibir instrucciones, contexto y opciones de generación.
La comunicación acepta respuestas completas o respuestas progresivas. En el segundo caso, el servicio devuelve una secuencia de eventos en formato de líneas JSON, lo que permite procesar cada fragmento sin esperar a que termine toda la generación. La aplicación no necesita instalar un paquete específico de Ollama porque la integración utiliza HTTP estándar.
Configuración externa
La dirección del servicio y el nombre del modelo se mantienen fuera del código de negocio mediante la configuración de la aplicación. Esta separación permite cambiar el entorno local, el servidor de desarrollo o la infraestructura de producción sin recompilar el servicio.
En Orbi, la aplicación se ejecuta dentro de Docker Swarm mientras Ollama permanece en el host. Por eso, la dirección de conexión debe apuntar al host del contenedor y no a la propia instancia aislada. Esta diferencia entre red local y red de contenedores fue una de las consideraciones importantes del despliegue.
Cliente HTTP administrado
El backend utiliza un cliente HTTP tipado administrado por la fábrica de clientes de ASP.NET Core. Esta decisión centraliza la dirección base, el tiempo de espera y la reutilización de conexiones, además de facilitar la inyección del servicio en los controladores.
Un tiempo de espera acotado evita que una generación lenta mantenga recursos ocupados indefinidamente. La cancelación también se propaga desde la solicitud web hasta la comunicación con Ollama para detener operaciones que la persona ya no necesita.
3. Implementación
Generación contextual
El servicio recibe el cliente HTTP, la configuración y el registrador de eventos. Para una respuesta breve, prepara una solicitud con el modelo seleccionado, instrucciones en español, la pregunta y el contexto autorizado. La generación se configura con baja variabilidad y con un límite de longitud para mantener respuestas concisas y previsibles.
La respuesta se transforma en un objeto de transporte mínimo que expone el texto generado. Los metadatos de duración y consumo de tokens se reservan para observabilidad, sin registrar el prompt completo ni información sensible.
Respuestas progresivas
El chat de Orbi no espera a que termine toda la generación. El backend solicita el modo progresivo, lee cada evento conforme llega y entrega sus fragmentos al cliente. La interfaz puede mostrar el texto mientras se produce, lo que reduce la sensación de espera en operaciones que dependen de un modelo local.
La respuesta progresiva también incorpora cancelación. Si la persona abandona la consulta, el navegador cancela la solicitud y esa señal se transmite al backend y al modelo. Así se evita continuar una generación cuyo resultado ya no será utilizado.
Comunicación con la interfaz
El controlador construye el contexto antes de invocar el modelo y responde con una secuencia de eventos que la interfaz puede consumir progresivamente. Cada evento contiene un fragmento de texto o una señal de finalización, mientras el servidor conserva un borrador para la etapa de revisión.
La respuesta se entrega sin caché y se fuerza el envío inmediato de los fragmentos para evitar que un proxy acumule todo el contenido. Esta decisión es esencial para que el usuario perciba una respuesta viva y no un bloque que aparece únicamente al final.
4. Seguridad y contexto
Limitar el contexto y reducir alucinaciones
Las reglas que rodean la integración son más importantes que la llamada HTTP. El modelo recibe únicamente datos consultados y filtrados por el servidor; nunca obtiene acceso directo a PostgreSQL. Un administrador puede recibir contexto global, mientras que otros roles solo reciben el catálogo y los registros asociados a su cuenta.
Las instrucciones restringen la generación a la información proporcionada y prohíben inventar productos, precios, tiendas, pedidos, pagos o permisos. Las preguntas exactas, como conteos o identidad de la persona autenticada, se resuelven de forma autoritativa en el backend y no se delegan al modelo.
Una segunda generación revisa el borrador y busca contradicciones con el contexto. Los errores de conexión se convierten en mensajes controlados que no exponen detalles internos del servicio local. La IA redacta; el backend sigue decidiendo qué datos existen y quién puede leerlos.
5. Despliegue
Consideraciones para Docker
Cuando ASP.NET Core y Ollama se ejecutan en la misma máquina sin contenedores, la conexión local es directa. Desde un contenedor, en cambio, la dirección local apunta al propio contenedor y no al host. El despliegue debe declarar explícitamente la ruta de red hacia la máquina que ejecuta Ollama.
También es importante no publicar el servicio de Ollama hacia Internet sin una capa de autenticación y control de acceso. Los timeouts, la cancelación y una respuesta degradada cuando Ollama está apagado completan el comportamiento esperado en producción.
Para observabilidad conviene registrar el modelo, la duración y el número de tokens, pero nunca secretos, prompts completos ni datos personales innecesarios. La configuración debe administrarse mediante variables del entorno de despliegue y mantenerse separada del repositorio de la aplicación.
6. Resultados
La conexión entre Ollama y ASP.NET Core permite incorporar asistencia basada en un modelo local dentro de Orbi sin trasladar la lógica del negocio a la IA. La aplicación puede enviar consultas, recibir respuestas breves o transmitirlas progresivamente mientras mantiene una experiencia adecuada para la persona usuaria.
Las decisiones principales fueron arquitectónicas: un cliente HTTP administrado para centralizar comunicación y timeouts; eventos progresivos para procesar cada fragmento mientras llega; cancelación para liberar recursos; y configuración externa para separar infraestructura y aplicación.
El límite permanece claro: Ollama redacta a partir de la información recibida, pero ASP.NET Core conserva la autenticación, la autorización, el acceso filtrado a PostgreSQL y las reglas de negocio. La IA puede asistir a la persona usuaria; las decisiones sobre los datos y los permisos deben seguir bajo control del servidor. La implementación completa permanece disponible en GitHub.