Von Slack-Threads zu strukturiertem Wissen: RAG bei Snyk implementieren

Unsere Mission bei Snyk ist es, Unternehmen dabei zu helfen, schnell zu entwickeln und sicher zu bleiben. Intern bedeutet das, sicherzustellen, dass unsere Teams schnell auf das umfangreiche institutionelle Wissen zugreifen können, das täglich entsteht. Eine wichtige Quelle dafür? Slack.

Slack ist unsere zentrale Anlaufstelle für Updates, technische Diskussionen und wertvolle Q&A. Doch wie häufige Nutzerinnen und Nutzer wissen, führt der dialogorientierte Charakter dazu, dass wichtige Informationen schnell in Threads, Channels und unzähligen Nachrichten untergehen.

Hier kommt Retrieval Augmented Generation (RAG) ins Spiel. RAG erweitert Large Language Models (LLMs), indem es ihnen Zugriff auf spezifische, aktuelle Informationen ermöglicht, die nicht in ihren ursprünglichen Trainingsdaten enthalten sind. Unser Ziel: die Fülle an Erkenntnissen in Slack nutzen, um ein intelligenteres internes Q&A-Tool bereitzustellen.

Die Herausforderung mit den Daten verstehen

Die Reise begann nicht mit komplexen Algorithmen, sondern damit, tief in die unübersichtlichen Slack-Daten aus der Praxis einzutauchen. Slack-Nachrichten sind nicht sauber organisiert: Sie enthalten lockere Chats, Emojis und kryptische Kennungen wie <@U123ABC> für Nutzer und <#C456DEF> für Channels. Das grundlegende Prinzip blieb während des gesamten Prozesses klar: „Wenn Sie Müll in ein Modell hineingeben, kommt Müll heraus.“ Bevor wir unsere Lösung entwickelten, traten einige zentrale Herausforderungen zutage:

• Wertvolle Informationen finden: Relevante Daten im Gesprächsrauschen zu erkennen, erforderte eine sorgfältige Auswahl.

• Chunking-Strategie: Die Daten sinnvoll aufzuteilen, war knifflig. Die Threads unterschieden sich erheblich. In manchen Channels herrschte rege Aktivität, in anderen nur sporadische. Herkömmliche Ansätze wie die Aufteilung nach Tagen oder in gleitenden Zeitfenstern waren problematisch, da ihnen Konsistenz und Fokus fehlten.

• Slack-IDs entschlüsseln: Wir mussten Nutzer- und Channel-IDs in aussagekräftige Namen umwandeln, damit die Inhalte verständlich waren.

• Markdown-Konvertierung: Threads in Markdown umzuwandeln, schien zunächst einfach. Doch das rohe Markdown war voller Emojis, Reaktionen und verschachtelter Antworten, die das LLM möglicherweise verwirrt hätten.

Der „Aha!“-Moment: Q&A als zentrale Struktur

Der Durchbruch kam, als wir einen Schritt zurücktraten und uns wieder auf den eigentlichen Zweck des RAG-Systems besannen: Fragen von Mitarbeitenden zu beantworten. Statt die Daten in vorgegebene Chunks zu pressen, strukturierten wir die Informationen anhand klarer Q&A-Interaktionen. Jeder Slack-Thread, in dem eine Frage gestellt und beantwortet wurde, bildete einen einzelnen, strukturierten Dokumenten-Chunk.

Dieser naheliegende Kurswechsel vereinfachte unseren Prozess:

• Fragen identifizieren: Wir konzentrierten uns auf Slack-Channels, die ausdrücklich für Fragen vorgesehen waren, etwa #ask-product.

• LLM für Zusammenfassungen: Mit der Gemini API von Google verarbeiteten wir Slack-Threads mithilfe von Prompts wie „Formuliere eine klare Frage und eine umfassende Antwort.“ So entstanden hochwertige, strukturierte Daten, die für unser RAG-System bereit waren.

• Retrieval-Strategie: Wir erstellten Embeddings ausschließlich für die extrahierten Fragen. So ließ sich die Anfrage der nutzenden Person effizient mit den gespeicherten Fragen vergleichen. Entscheidend war, dass das LLM die Antwort (als Metadaten gespeichert) zur ähnlichsten gespeicherten Frage erhielt – nicht die Frage selbst. Dadurch wurde dem Modell der relevanteste Kontext bereitgestellt.

• Fallback-Ansatz: Nicht alle wertvollen Threads waren einfache Frage-Antwort-Verläufe. In diesen Fällen formatierten wir die Threads als übersichtliche Markdown-Zusammenfassungen, um den breiteren Kontext zu bewahren.

• Kontinuierliche Aktualisierungen: Sobald neue Nachrichten hinzukommen, erstellt das System dynamisch neue Zusammenfassungen. So bleibt unsere Wissensdatenbank aktuell.

Die Lösung implementieren

Mit dem geschärften Fokus auf Q&A-Strukturen wurde unser technischer Workflow klar und effizient:

• Slack SDK: Nachrichten direkt aus Slack abrufen.

• Gemini API: Threads in strukturierte Q&A oder zusammengefasstes Markdown umwandeln.

• Snowflake Cortex Search Service: Strukturierte Ergebnisse speichern und aus Fragen Embeddings erstellen.

• RAG-Anwendung: Mitarbeitende stellen Anfragen, die als Embeddings dargestellt und semantisch mit gespeicherten Fragen verglichen werden. Relevante Antworten werden aus den Metadaten abgerufen und ermöglichen kontextgenaue Reaktionen.

Bildbeschreibung anzeigen

Mehr als APIs: Einblicke aus der Engineering-Praxis

Unsere endgültige Lösung beruhte nicht auf bahnbrechenden Algorithmen, sondern auf einem tiefen Verständnis unserer Daten, kreativer Problemlösung und der schrittweisen Verfeinerung unseres Ansatzes. Die eigentliche Engineering-Leistung bestand nicht nur darin, APIs zu integrieren oder Embeddings zu implementieren, sondern die Daten sorgfältig so zu strukturieren, dass sie unsere zentrale Herausforderung lösten.

Unsere Q&A-zentrierte Strategie passt perfekt zur Funktionsweise von RAG und verwandelt das dialogorientierte Chaos in Slack in klares, zugängliches Wissen. Das zeigt: Innovative KI-Lösungen entstehen oft aus menschenzentrierten Erkenntnissen und nicht allein aus komplexen technologischen Errungenschaften.