Cuando un candidato recibe docenas de ofertas y mensajes cada semana, filtrar, priorizar y responder con criterio se vuelve casi imposible. Para resolver esto desarrollé un prototipo local de asistente de IA orientado a preselección: no para sustituir entrevistas ni negociaciones, sino para automatizar preguntas repetitivas, destacar lo relevante y mantener los datos del candidato bajo control.
Objetivos principales: dar al candidato una voz consistente y respetuosa de la privacidad en la preselección, automatizar tareas repetitivas para acelerar las entrevistas reales, mantener los datos sensibles en local por defecto y construir un POC práctico en una semana. Esa restricción local y rápida condicionó todas las decisiones técnicas.
Arquitectura resumida: interfaz de candidato (web, chat, CLI) que se comunica por REST o SSE con un backend en Spring Boot y Spring AI. El ChatClient orquesta una cadena de advisors que expande la consulta, incorpora memoria, recupera hechos via RAG y finalmente genera la respuesta con un modelo alojado en Ollama en local. La capa de datos usa PostgreSQL con pgvector para almacenar embeddings y PostgresChatMemory para contexto de chat. La infraestructura es contenedorizada y preparada para Kubernetes.
Patrón clave: advisors con estilo Chain of Responsibility. Cada advisor recibe el contexto, puede leer o escribir en él, invocar servicios externos como el almacén vectorial o rerankers, y pasar el resultado al siguiente advisor. Esto permite añadir verificaciones de cumplimiento, análisis de sentimiento o integraciones sin tocar la lógica central del cliente de chat.
Flujo end to end ejemplar: reclutador pregunta salario. El frontend abre un canal SSE al endpoint chat. El servicio carga el contexto reciente desde PostgresChatMemory, la cadena de advisors ejecuta expansion de la query para mejorar recall, aplica memoria conversacional, registra la consulta, ejecuta RAG con búsqueda de similitud en pgvector, rerank por BM25 y opcionalmente por cross-encoder, y finalmente el ChatClient pide a Ollama la generación de texto y lo retransmite por SSE al frontend.
RAG en detalle: se precomputan embeddings para cada artefacto del candidato como CV, cartas y notas. La búsqueda de vecinos más cercanos en pgvector devuelve fragmentos relevantes. BM25 repondera por precisión en textos cortos y un reranker neuronal puede mejorar mucho la calidad a costa de coste computacional. Caching con TTL en memoria reduce latencia en consultas repetidas.
La capa de embeddings es el cerebro de la búsqueda. Un embedding transforma textos a vectores de alta dimensión para que frases equivalentes semánticamente queden próximas en el espacio vectorial. pgvector permite guardar y buscar esos vectores en Postgres con índices como IVFFlat para escalar. La estrategia de chunking y las dimensiones del embedding afectan costes y fidelidad.
Ollama y parámetros del modelo: al ejecutar modelos locales conviene ajustar temperatura para factualidad, topK y topP para diversidad controlada y repeatPenalty para evitar repeticiones. Modelos de 4B a 13B suelen ofrecer el mejor equilibrio local entre latencia y calidad. Para producción en mayor escala se recomiendan instancias GPU y modelos cuantizados si el hardware es limitado.
Memoria y trazabilidad: PostgresChatMemory almacena cada turno con referencias a los documentos recuperados. La integración futura con MCP permitiría versionado de contexto, referencias de procedencia y auditoría completa: cada respuesta podría trazarse hasta los fragmentos exactos que la sustentan.
Consideraciones operativas: embeddings consumen disco y RAM; la inferencia de modelos mayores requiere GPU. Contenerizar el sistema facilita moverlo a Kubernetes, escalar pods y crear pools de GPU. Ajustar TTL de cache y umbrales de similitud es clave para mantener respuestas precisas sin costes desbordados.
Guardrails éticos y límites de uso: el sistema está pensado para preselección automatizada y nunca para sustituir decisiones humanas finales. Mantiene privacidad local por defecto y debe advertir y pedir consentimiento si se usan modelos externos. No debe inventar habilidades ni datos; el system prompt actúa como constitución de la voz del candidato para evitar exageraciones.
En Q2BSTUDIO aplicamos este tipo de soluciones a la medida de las necesidades empresariales. Somos una empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud aws y azure y servicios de inteligencia de negocio. Podemos adaptar este enfoque de agentes IA y RAG para integrar tus procesos con soluciones robustas y seguras, incluyendo auditoría y cumplimiento.
Si buscas transformar procesos con IA para empresas o construir agentes IA que representen candidatos o productos, consulta nuestros servicios de inteligencia artificial y descubre cómo desarrollamos aplicaciones a medida escalables y seguras. También ofrecemos auditorías de ciberseguridad, pentesting, automatización y soluciones con Power BI para inteligencia de negocio.
Consejos prácticos para ingenieros: afina primero la recuperación RAG antes de tocar la temperatura del modelo, empieza con modelos pequeños cuantizados y sube según necesidades, haz la memoria explícita y versionable y monitoriza métricas de hit/miss de RAG, latencia de rerank y tokens por respuesta.
Resumen final: un agente local-first que expande consultas, recupera hechos con RAG, reordena por BM25 y opcionalmente por redes neuronales, y genera respuestas con Ollama puede acelerar significativamente la preselección de candidatos manteniendo la privacidad. En Q2BSTUDIO estamos listos para ayudarte a diseñar e implementar soluciones de software a medida, inteligencia artificial, ciberseguridad y servicios cloud para que tu empresa aproveche estas capacidades con responsabilidad y eficacia.