RAG de política de recursos humanos adaptada a la producción con LangChain y LangGraph
Ingestión, MMR, reescritura con conocimiento del historial, respuestas fundamentadas, medidas de seguridad, evaluación, citas y orquestación de grafos para un asistente de políticas de recursos humanos.
Una guía que abarca la ingesta de datos, la recuperación de información mediante MMR, consultas conscientes del historial, verificaciones de seguridad, mecanismos de evaluación y la experiencia de usuario en chats multirrondas.
Introducción
Las respuestas generativas fluidas no son suficientes para los recursos humanos empresariales. Un asistente de políticas no debe inventar reglas de permisos a partir del entrenamiento previo; en su lugar, debe recuperar documentos aprobados y basar cada solicitud en dichas fuentes. Ese es el propósito de la Generación Aumentada por Recuperación de Información (RAG).
Una plataforma modular de preguntas y respuestas sobre políticas de recursos humanos, al estilo de producción, puede combinar Python, LangChain, LangGraph, un modelo de chat compatible con OpenAI, ChromaDB, Streamlit, embeddings, recuperación mediante MMR, reescritura de consultas teniendo en cuenta el historial, diseño de prompts, moderación de entradas, verificaciones contra inyecciones de prompts, evaluación de la recuperación de información, memoria conversacional, resumen y exportación a PDF. El objetivo no es un chatbot de demostración, sino un sistema RAG que toma en serio la calidad de la recuperación de información, el contexto de la conversación, la seguridad, la evaluación y la usabilidad.
1. El problema
Cuando alguien pregunta “¿Cuántos días de licencia por enfermedad se permiten?”, un modelo LLM simple podría inventar una respuesta. En cambio, un asistente de recursos humanos debería:
- Comprender la pregunta
- Buscar en los documentos de recursos humanos de la organización
- Recuperar las secciones más relevantes
- Passar esas secciones al modelo
- Generar una respuesta basada en ellas
Flujo general: documentos de recursos humanos → ingestión → fragmentación + metadatos → embeddings → ChromaDB → recuperador → consulta consciente del historial → documentos relevantes → prompt fundamentado → respuesta → citaciones.
2. Ingestión de documentos
Las políticas en formato bruto se convierten en fragmentos buscables. Los documentos completos son demasiado grandes para incluirse en cada prompt y pueden superar los límites de contexto. Los fragmentos contienen metadatos como el nombre del archivo, la ruta, la carpeta, el tipo de documento y las etiquetas de origen; estos son útiles posteriormente para citaciones, depuración e inspección de los resultados de recuperación.
3. Embeddings y almacenamiento vectorial
Cada fragmento se convierte en un vector de embedding:
"Employees receive annual leave..."
↓
Embedding Model
↓
[0.12, -0.43, 0.87, ...]
Los vectores y los metadatos se almacenan en ChromaDB. Las preguntas de los usuarios también se convierten en embeddings de la misma manera, de modo que las políticas semánticamente similares aparezcan incluso cuando su redacción difiere (“permiso por enfermedad” vs “derecho a licencia por enfermedad”).
4. Recuperación con MMR
La similitud naïve top-k puede devolver cuatro fragmentos de política de licencia casi idénticos:
Chunk 1 → Leave policy
Chunk 2 → Leave policy
Chunk 3 → Leave policy
Chunk 4 → Leave policy
La relevancia marginal máxima equilibra la relevancia con la diversidad. Un conjunto de candidatos más grande fetch_k, seguido de la selección final k mediante MMR, reduce la redundancia:
10,000 chunks
↓
Similarity search
↓
20 candidate chunks
↓
MMR
↓
4 diverse + relevant chunks
↓
LLM
5. Recuperación consciente del historial
Preguntas como “¿Y qué hay de los gerentes?” después de una respuesta sobre licencia anual son ambiguas por sí solas. Un paso consciente del historial reescribe la consulta utilizando el historial de conversación antes de realizar la recuperación:
Conversation History
+
Current Question
↓
LLM
↓
Standalone Search Query
Eso separa la contextualización de la consulta (¿qué quería decir el usuario?) de la generación de respuestas (¿qué debería decirse en función de los documentos?).
6. Generación de respuestas basadas en datos reales
Los fragmentos recuperados alimentan una instrucción que le dice al modelo que utilice únicamente documentos de recursos humanos, evite inventar políticas, señale las exclusiones, sea conciso y admita las lagunas. Arquitectura: pregunta → contextualización → recuperador → documentos → instrucción de verificación de calidad → LLM → respuesta fundamentada. El modelo escribe el texto en prosa; el corpus proporciona los hechos.
7. ¿Por qué LangGraph?
A medida que aumentan las etapas — validación, moderación, detección de inyecciones, procesamiento de consultas, recuperación, generación, memoria, resumen — una cadena lineal se vuelve frágil. LangGraph modela el flujo de trabajo como estados y nodos:
User Input
↓
Validation
↓
Guardrails
↙ ↘
Safe Unsafe
↓ ↓
RAG Workflow Reject
↓
Final Response
↓
Conversation
Management
El grafo es más fácil de extender que una sola función masiva.
8. Límites
La entrada para producción necesita verificaciones antes del RAG:
- Moderación — bloquear tempranamente el contenido que infringe las políticas
- Detección de inyecciones en instrucciones — rechazar ataques del tipo “ignorar instrucciones anteriores…”
El orden es importante: entrada del usuario → verificaciones de seguridad → RAG, no entrada del usuario → LLM en bruto.
9. Memoria de conversación y resumen
Los asistentes multietapa necesitan un historial, pero las transcripciones ilimitadas consumen muchos tokens. Resumir las conversaciones anteriores permite conservar la información relevante al mismo tiempo que se limita el contexto activo; es un equilibrio entre preservación y costo.
10. Evaluación de la recuperación
Una respuesta puede parecer fluida aunque la recuperación de información haya fallado. Hay que medir si llegaron los pasajes adecuados, no solo si el texto se recuperó. Se debe evaluar la calidad de la recuperación, la generación basada en datos reales y el comportamiento de la aplicación como capas separadas.
11. Citaciones de fuentes
Es mejor utilizar frases como “Los empleados reciben 20 días de vacaciones anuales (Política de Vacaciones §3)” en lugar de afirmaciones simples. Las citaciones aumentan la confianza, facilitan la depuración y mejoran la trazabilidad cuando los empleados pueden abrir el PDF original.
12. Exportación de conversaciones en PDF
Exportar una conversación a PDF permite a los empleados conservar un registro para futuro uso. Se trata de un detalle relacionado con la usabilidad que indica que el sistema está diseñado para trabajos reales, y no para ser un simple widget de chat temporal.
Cierre
Un asistente RAG de recursos humanos listo para su uso en producción consta de una secuencia que incluye la ingesta de datos, estrategias de recuperación, reescritura de las conversaciones, fundamentación en información fiable, orquestación de grafos, medidas de control, evaluación y citaciones. LangChain y LangGraph ayudan a integrar todas estas etapas; Chroma y MMR determinan qué información puede ver el modelo. La regla fundamental del producto sigue siendo la misma: las respuestas se obtienen de documentos aprobados, y no de la memoria del modelo sobre Internet.
Elegencias de diseño que son importantes en la práctica
El tamaño de los fragmentos y la superposición no son cuestiones estéticas. Los fragmentos demasiado grandes diluyen la señal de incrustación; los fragmentos demasiado pequeños pierden las restricciones normativas circundantes. La superposición es útil cuando una regla abarca un límite. Los metadatos no son una decoración opcional: sin indicaciones de nombre de archivo y sección, las citaciones se vuelven vagas y los conjuntos de evaluación son difíciles de juzgar.
Los parámetros MMR (fetch_k, k, lambda de diversidad) deben ajustarse con base en un conjunto de preguntas etiquetadas, y no por intuición. Un grupo de candidatos demasiado pequeño nunca muestra pasajes diversos; uno demasiado grande desperdicia tiempo de procesamiento.
La reescritura consciente de la historia no debe inventar hechos. El paso de reescritura solo debería expandir pronombres y continuaciones incompletas en consultas de búsqueda independientes. Si el modelo de reescritura tiende a responder, la recuperación nunca recibirá una consulta limpia.
Las medidas de control deben aplicarse antes de la recuperación de información. La moderación y la detección de inyecciones que se ejecutan después de que el modelo ya ha visto el texto de la política privada son demasiado tardías. Se debe rechazar cualquier sospecha de inyección; solo se puede permitir la respuesta si la política del producto autoriza explícitamente bloqueos suaves junto con registro de actividad.
La evaluación debe considerar tanto la recuperación (recall@k de los IDs de documentos esperados) como la generación (fidelidad al texto recuperado). Una respuesta aparentemente correcta basada en una cláusula incorrecta sigue siendo un fallo. Se deben almacenar los registros: la consulta reescrita, los IDs recuperados, la respuesta final y la lista de referencias.
Streamlit (o cualquier interfaz sencilla) debe mostrar claramente las referencias y los estados “desconocidos”. Los empleados confían más en los sistemas que admiten limitaciones que en aquellos que inventan políticas de licencia generosas.
La función de exportación a PDF es una herramienta de conservación: la gente pega las respuestas basadas en políticas en los tickets. El texto exportado debe considerarse potencialmente sensible y se deben aplicar los mismos controles de acceso que en las sesiones de chat.
Finalmente, asegúrese de que la ruta principal del gráfico sea evidente. Los nuevos ingenieros deberían poder seguir el proceso de validación → reescritura → recuperación → generación → respuesta sin tener que adentrarse en ramas opcionales. Las ramas opcionales (resumen, exportación) están conectadas a nodos claros en lugar de anidarse dentro del proceso de generación.
Esa disciplina convierte una demostración de RAG en un fin de semana en algo que el equipo de recursos humanos puede probar sin temor a alucinaciones silenciosas en las políticas.
Organizando los elementos en un cronograma
HR DOCUMENTS
│
▼
DOCUMENT INGESTION
│
Chunking + Metadata
│
▼
EMBEDDINGS
│
▼
CHROMADB
│
▼
RETRIEVER
(MMR Search)
│
│
USER ──→ GUARDRAILS ─────┤
│
▼
HISTORY-AWARE QUERY
CONTEXTUALIZATION
│
▼
RETRIEVAL
│
▼
RELEVANT DOCUMENTS
│
▼
QA PROMPT + LLM
│
▼
GROUNDED ANSWER
│
┌────┴────┐
↓ ↓
Citations Memory
│
▼
Summarization
│
▼
PDF Export
El primer día suele centrarse en “incorporar PDFs y chateo”. Son los días dos al diez cuando aparecen las características reales del sistema: esquemas de metadatos, ajuste de MMR, indicaciones para reescribir respuestas, mecanismos de moderación, clasificadores de inyecciones, hojas de cálculo para evaluaciones, formato de citas y resumen de conversaciones. Saltarse estos pasos deja un sistema que funciona bien con preguntas simples pero falla en la segunda respuesta, ante prompts adversariales o al recuperar contenido casi idéntico.
LangChain ayuda a conectar los objetos del modelo y del recuperador de información; LangGraph facilita que el flujo de control sea inspeccionable. Ninguno de los dos reemplaza la decisión final sobre qué carpetas de recursos humanos son fuentes autorizadas, quién puede consultar qué políticas y cómo se muestra lo “desconocido” en la interfaz de usuario. Esas decisiones deben incluirse en los documentos de diseño junto al diagrama del grafo.
Cuando algo falla en producción, el camino de depuración más rápido suele ser: inspeccionar la consulta reescrita, listar los IDs de los fragmentos recuperados, leer esos fragmentos y luego leer el prompt correspondiente. Si esa secuencia falta en los registros, corrija la capacidad de observabilidad antes de añadir otro modelo.