Antecedentes:
Con el lanzamiento de ChatGPT, la tecnología alcanzó un punto de inflexión para quienes desarrollan aplicaciones. Un sistema capaz de organizar grandes cantidades de texto, con mecanismos para detectar lo importante y poder simular una respuesta humana en lenguaje natural es sin duda un hito tecnológico del siglo XXI.
Es evidente que este avance es el resultado de años de investigación y del esfuerzo conjunto de grandes empresas y miles de contribuidores independientes que comparten un objetivo común: lograr que los dispositivos entiendan el lenguaje natural humano. Mientras seguía estas noticias trabajaba en la programación de este sitio web y me preguntaba si existía una forma de aplicar estas tendencias a una plataforma tradicional construida de forma individual. Busqué un problema específico en Plaudere que un modelo de lenguaje pudiera resolver. Tras un periodo de reflexión y tras explorar de nuevo versiones anteriores de la web me di cuenta de que al haber perdido el contacto con la lógica y el uso de aquellas iteraciones me resultaba difícil entender y seguir el flujo de la aplicación. A pesar de haber evolucionado el sitio para que fuera más intuitivo siempre existirá una barrera de uso si el usuario no está familiarizado con la interfaz o no encuentra rápidamente las opciones que le permitan cumplir sus objetivos de uso con la web. Así identifiqué que tanto la curva de aprendizaje en la navegación como la falta de claridad sobre el valor y la utilidad real de la web eran fricciones típicas que podrían minimizarse mediante la implementación de modelos de lenguaje.
Navegando entre restricciones: Cloud vs. Local:
Para abordar la aplicación de modelos de lenguaje en el sitio web investigué los fundamentos de la inteligencia artificial generativa. Aunque existen muchos modelos disponibles, estos suelen implicar costes por llamada a sus APIs o límites estrictos de uso que no encajaban con un proyecto en fase inicial como Plaudere. Al no contar con información sobre el volumen de demanda real, depender de terceros suponía un riesgo de sobredimensionar la infraestructura. Mi objetivo principal era construir capacidades propias sin dependencias externas siempre que una solución local fuera viable. Reflexioné que, para el caso de uso específico de Plaudere, donde la precisión no era extremadamente exigente, carecía de sentido recurrir a grandes modelos de lenguaje si uno pequeño podía cumplir con los requisitos. Así comencé a buscar en Hugging Face modelos open source compatibles con Node.js, ya que mi prioridad era integrar la IA dentro de la arquitectura del sitio y evitar, en esta fase, la complejidad de gestionar componentes externos adicionales más allá de los servicios básicos de autenticación. Sin embargo, una vez que la solución demostró ser estable, evolucioné la infraestructura hacia un modelo desacoplado e independiente.
Exploré varios modelos intentando mantener el servicio en un servidor con recursos de RAM y CPU limitados. Probé varios modelos con distintos tamaños de parámetros y grados de cuantización, incluyendo TinyLlama y GPT-2, pero terminaban excediendo los límites de memoria una vez cargados o provocaban errores en Node.js al competir con los procesos propios de la web.
Tras varios intentos, uno de los modelos que funcionó bien fue Qwen, desarrollado por Alibaba Cloud). Es extremadamente eficiente: la versión 2.5 requiere 2vCPUs y 4GB de RAM en la versión cuantizada, y 6GB de RAM utilizando una versión sin cuantizar. Usando modelos Qwen de aproximadamente 500 millones de parámetros, se clasifica como un Small Language Model (SLM) y, a pesar de su tamaño, maneja una ventana de contexto de 128 mil tokens en la versión Qwen 2.5 y 32 mil tokens en la versión Qwen 1.5. Utiliza una arquitectura de transformer decoder only y soporta más de 12 idiomas en la versión Qwen 1.5 y más de 29 idiomas en la versión 2.5 con un rendimiento destacado en inglés y una solvencia sorprendente en otras lenguas pese a sus dimensiones reducidas.
Documentación oficial del modelo Qwen 1.5 (en inglés).
Documentación oficial del modelo Qwen 2.5 (en inglés).
Antes de decidirme por Qwen, investigué arquitecturas de procesamiento de lenguaje natural (NLP) más antiguas. Aunque eran eficientes para tareas de clasificación, carecían de la fluidez del lenguaje natural y de la capacidad de entender el contexto o la conjugación. Los modelos tradicionales podían identificar el sentido general de un texto, pero a menudo se limitaban a respuestas binarias de "Sí" o "No", sin una verdadera estructura gramatical. Para crear un agente de acompañamiento en Plaudere, la rigidez de estos modelos los hacía inviables. Esta es la razón por la que opté por los SLMs basados en Transformers, los cuales han dejado obsoletas las arquitecturas de preguntas y respuestas (Q&A) convencionales, permitiendo una interacción mucho más humana y adaptativa.
La solución: Arquitectura desacoplada con FastAPI y Qwen:
El siguiente paso fue migrar el modelo Qwen a un servicio independiente tipo API. Al separar el SLM del servidor web, se evitaban conflictos de memoria. Esta API dedicada se activa cuando el usuario realiza una consulta; el sitio web espera la respuesta remota y, si no hay más actividad, el servicio entra en modo de suspensión para ahorrar recursos del servidor.
Arquitectura backend SLM de Plaudere.
Implementación del Contexto (RAG):
Para integrar el modelo, se añadió un chat emergente que envía el prompt del usuario al servidor. Se definen tres casos de uso para el soporte:
- Ayuda general del sitio web.
- Consultas sobre artículos creados en la plataforma.
- Información sobre usuarios (solo si estos la han compartido).
Aunque Qwen admite una ventana de contexto amplia, intentar usar ese volumen de texto con un servidor limitado no es una estrategia viable. En cuanto el modelo está cargado, la memoria que queda para procesar texto es limitada, así que la aplicación necesita seleccionar qué información le entrega al SLM. Por eso, la arquitectura está planteada como un modelo de generación aumentada por recuperación: no para alimentar al modelo con todo el contexto original, sino para recuperar solo los fragmentos realmente relevantes para conseguir una respuesta fundamentada.
Inicialmente la solución se basó en un enfoque de fuzzy search más simple con fuse.js, pero no fue suficiente para el nivel de entendimiento del contexto que se necesitaba. En la solución final se propone una mejora del enfoque fuzzy search llamado semantic fuse creada en Plaudere, que es una capa de recuperación mucho más avanzada. Convierte el texto en representaciones deterministas de 64 dimensiones y ordena los fragmentos mediante un sistema híbrido de puntuación que combina similitud vectorial, solapamiento Jaccard, coincidencia de frases y tolerancia a erratas. Además, usa distancia de Levenshtein y similitud n-gram, lo que le permite recuperar fragmentos relevantes del contexto, incluso cuando la redacción no coincide de forma exacta. Eso hace que la recuperación se acerque mucho más a una selección semántica que a una simple búsqueda por palabras clave.
La fase de recuperación no consiste solo en encontrar texto relacionado, sino en elegir las mejores frases para el modelo con suficiente precisión como para mantener el prompt enfocado. El worker construye fragmentos optimizados, protege la estructura de las frases, limita el número de fragmentos relevantes y aplica umbrales de confianza para decidir qué se conserva y qué se descarta. En la práctica, eso significa que el SLM no recibe el contexto entero, sino que recibe un conjunto pequeño de fragmentos priorizados que ya han pasado por una capa de selección semántica diseñada para comportarse como una versión reducida de una RAG completa.
Antes de que el SLM genere la respuesta, el sistema también detecta la intención. Distingue entre saludo, despedida, agradecimiento, prompt no relevante, resumen, sintetización del texto y otras preguntas, de forma que cada petición siga el recorrido correcto. Algunas intenciones se responden directamente, otras pasan por la lógica de resumen y otras entran en el flujo completo de RAG. Esa capa de enrutado es importante porque evita tratar todos los inputs igual y permite que la estrategia de respuesta se adapte a la intención real del usuario.
Una vez identificada la intención, el modelo extrae el contexto, construye el prompt e inyecta en la entrada del modelo las frases relevantes y el historial acotado de la conversación. El prompt está diseñado para mantener la respuesta anclada al contexto proporcionado y para evitar generación sin soporte. El resultado es una fase de generación controlada, no una respuesta abierta basada en la memoria base del modelo.
En conjunto, la arquitectura es compacta, pero conceptualmente muy parecida a una RAG estándar: primero recuperación local, después enrutado por intención, luego construcción del prompt, generación en el SLM y, por último, evaluación de la respuesta. Conserva la estructura de una pipeline de lenguaje más grande, pero sigue siendo lo bastante ligera como para funcionar dentro de los límites de memoria del servidor.
Flujo de solicitudes SLM de Plaudere.
Conclusiones y hoja de ruta:
El objetivo inicial era el de proporcionar mejores herramientas para el soporte del usuario y para ayudarle a entender los textos de los artículos y los perfiles de los usuarios. La clave de los buenos resultados reside en la calidad del contexto. Aunque el modelo ocasionalmente presenta "alucinaciones" o errores factuales básicos (propios de un SLM frente a un LLM), responde con éxito basándose en la información de soporte.
Nuestros objetivos futuros incluyen, entre otros:
- Reducir alucinaciones migrando a versiones más recientes de Qwen o a otros modelos.
- Enriquecer las respuestas de la IA incluyendo imágenes y videos.
- Refinar las reglas de contexto para el contenido generado por usuarios.
- Garantizar la consistencia multilingüe para que la IA responda en el mismo idioma del usuario.
- Uso de base de datos vectorial embebida para aumentar la coherencia y el contexto de las respuestas a los prompts.
Este proyecto ha sido fundamental para experimentar con la IA generativa bajo restricciones reales de hardware, aplicando la metodología RAG para que un modelo responda sobre un contexto que nunca vio en su entrenamiento original. El desarrollo demuestra que, con ingenio, es posible implementar soluciones inteligentes basadas en IA optimizando al máximo los recursos disponibles.
