De hilos de Slack a conocimiento estructurado: implementar RAG en Snyk
Escrito por
0 minutos de lectura
La misión de Snyk es ayudar a las organizaciones a desarrollar con rapidez y mantener la seguridad. Internamente, esto significa garantizar que nuestros equipos puedan acceder rápidamente al amplio conocimiento institucional que se genera cada día. ¿Una fuente clave? Slack.
Slack es nuestro centro principal para novedades, debates técnicos y valiosas preguntas y respuestas. Sin embargo, como saben quienes lo usan con frecuencia, su naturaleza conversacional hace que la información crítica quede rápidamente enterrada entre hilos, canales e innumerables mensajes.
Aquí entra en juego la generación aumentada por recuperación (RAG). RAG mejora los modelos de lenguaje grandes (LLM) al darles acceso a información específica y actual que no forma parte de sus datos de entrenamiento originales. Nuestro objetivo: aprovechar la gran cantidad de información valiosa de Slack para impulsar una herramienta interna de preguntas y respuestas más inteligente.
Comprender el desafío de los datos
El proceso comenzó no con algoritmos complejos, sino con un análisis de los datos desordenados del mundo real en Slack. Los mensajes de Slack no están organizados de forma prolija: incluyen conversaciones informales, emojis e identificadores crípticos como <@U123ABC> para los usuarios y <#C456DEF> para los canales. Durante todo el proceso, mantuvimos claro el principio fundamental: «Si ingresas basura en un modelo, obtienes basura». Antes de desarrollar nuestra solución, surgieron varios desafíos clave:
Encontrar información valiosa: Identificar datos relevantes entre el ruido de las conversaciones requería una selección cuidadosa.
Estrategia de segmentación: Determinar cómo dividir los datos fue complicado. Los hilos variaban mucho. Algunos canales tenían actividad intensa y rápida, mientras que otros eran esporádicos. Los enfoques convencionales, como segmentar por día o con ventanas móviles, planteaban problemas por su falta de consistencia y enfoque.
Descifrar los ID de Slack: Tuvimos que traducir los ID de usuarios y canales a nombres comprensibles para garantizar que fueran fáciles de leer.
Conversión a Markdown: Al principio, convertir los hilos a Markdown parecía sencillo. Sin embargo, el Markdown sin procesar estaba lleno de emojis, reacciones y respuestas anidadas, lo que podía confundir al LLM.
El momento «¡ajá!»: las preguntas y respuestas como estructura central
El avance llegó cuando dimos un paso atrás y volvimos a enfocarnos en el propósito esencial del sistema RAG: responder las preguntas de los empleados. En lugar de forzar los datos en segmentos predefinidos, optamos por estructurar la información en torno a interacciones claras de preguntas y respuestas. Cada hilo de Slack en el que se hacía una pregunta y se recibía una respuesta se convirtió en un único segmento de documento estructurado.
Este cambio intuitivo simplificó nuestro proceso:
Identificación de preguntas: Nos enfocamos en los canales de Slack diseñados específicamente para hacer preguntas, como #ask-product.
LLM para resumir: Usamos Gemini API de Google para procesar los hilos de Slack con instrucciones como «Extrae una pregunta clara y una respuesta completa». Así generamos datos estructurados de alta calidad, listos para nuestro sistema RAG.
Estrategia de recuperación: Generamos embeddings solo de las preguntas para recuperar información de forma eficiente, comparando la consulta del usuario con las preguntas almacenadas. Es importante destacar que el LLM recibía la respuesta (almacenada como metadatos) correspondiente a la pregunta almacenada más similar, no la pregunta en sí. Así nos asegurábamos de proporcionar al modelo el contexto más relevante.
Enfoque alternativo: No todos los hilos valiosos tenían una estructura clara de preguntas y respuestas. En esos casos, convertimos los hilos en resúmenes claros en Markdown para conservar un contexto más amplio.
Actualizaciones continuas: El sistema vuelve a generar los resúmenes de forma dinámica cada vez que se agregan mensajes, para que nuestra base de conocimiento esté siempre actualizada.
Implementar la solución
Al enfocarnos mejor en las estructuras de preguntas y respuestas, nuestro flujo de trabajo técnico se volvió claro y eficaz:
Slack SDK: Obtener mensajes directamente de Slack.
Gemini API: Transformar hilos en preguntas y respuestas estructuradas o resúmenes en Markdown.
Snowflake Cortex Search Service: Almacenar resultados estructurados y crear embeddings a partir de las preguntas.
Aplicación RAG: Los empleados hacen consultas, que se convierten en embeddings y se comparan semánticamente con las preguntas almacenadas. Se recuperan las respuestas pertinentes (de los metadatos) para ofrecer respuestas precisas y contextualizadas.
Más allá de las API: perspectivas reales de ingeniería
Nuestra solución final no dependió de algoritmos revolucionarios, sino de comprender a fondo nuestros datos, resolver problemas de forma creativa y perfeccionar nuestro enfoque de manera iterativa. El verdadero logro de ingeniería no fue solo integrar API o implementar embeddings, sino estructurar los datos meticulosamente para resolver nuestro desafío principal.
Nuestra estrategia centrada en las preguntas y respuestas se alinea de manera natural con el funcionamiento de RAG y convierte el caos conversacional de Slack en conocimiento claro y accesible. Esto demuestra que las soluciones innovadoras de IA suelen surgir de perspectivas centradas en las personas, y no solo de complejos logros tecnológicos.
La mayoría de los incidentes de seguridad se deben a errores evitables.
Descubre cómo mitigar los riesgos con capacitación continua, contextual y práctica.