Generative KI bietet im Rahmen von Betrieb und Entwicklung zahlreiche Chancen, bringt aber auch viele Herausforderungen für diejenigen mit sich, die versuchen, generative KI in eine Sicherheitslösung zu integrieren.
Eine dieser Herausforderungen besteht darin, über LLMs (Large Language Models) Erkenntnisse über vertrauliche Inhalte zu gewinnen, die nicht an KI-Dienste von Drittanbietern weitergegeben werden dürfen, wie etwa Sicherheitsrichtlinien zum Schutz von Anwendungen und APIs vor Betrug und Missbrauch.
Eine zweite Herausforderung bei LLMs besteht in ihrer Tendenz zu Halluzinationen, insbesondere wenn sie aufgefordert werden, Inhalte zu einem Thema zu analysieren oder zu erstellen, über das der LLM nur wenig Wissen besitzt. Dies ist häufig bei domänenspezifischen Sprachen wie DEX der Fall. Es handelt sich dabei um eine rein funktionale, statisch typisierte und nicht Turing-vollständige Sprache, die zwar gut definiert ist, aber nicht weit verbreitet ist.
Die erste Herausforderung, der Datenschutz, klingt zunächst unüberwindbar. Sicherheitsunternehmen müssen den Datenschutz und die Sicherheit aller Kundendaten – einschließlich der Richtlinien – sehr ernst nehmen. Obwohl die Verwendung eines LLM zur Aufdeckung von Erkenntnissen über Richtlinien sowohl für betriebliche Abläufe als auch für Kunden von Vorteil wäre, bedarf es einer Lösung, mit der Erkenntnisse aus den vertraulichen Daten gewonnen werden können, ohne diese Daten an ein LLM eines Drittanbieters weiterzugeben, wodurch es für das LLM unmöglich würde, sie zu verarbeiten. Die zweite Herausforderung (Halluzinationen) ist eine, mit der die gesamte Branche derzeit zu kämpfen hat, insbesondere im Hinblick auf Antworten zu Richtlinien, Konfigurationen und Code.
Während Menschen ein Programm als eine Folge von Zeichenfolgen betrachten, sieht der Compiler die Dinge anders. Für den Compiler ist ein DEX-Programm eine Art Datenstruktur, die als AST (Abstract Syntax Tree) bezeichnet wird. Bei diesem Baum handelt es sich um einen gerichteten azyklischen Graphen, was bedeutet, dass sich die betreffenden Richtlinien gut für die Darstellung als Graph eignen. Daher nutzt die von uns gefundene Lösung eine Graphdatenbank (Neo4j) und verwendet einen GPT-Agenten, um GraphQL-Abfragen dafür zu generieren. Dieser Ansatz bewältigt die erste Herausforderung elegant, da wir GraphQL verwenden können, um eine Graphdatenbank abzufragen, die die Daten enthält, und gleichzeitig ihre Privatsphäre vor dem LLM von Drittanbietern zu schützen.
Die zweite Herausforderung – Halluzinationen – ist schwieriger zu überwinden, aber unser Ansatz funktioniert auch hier, indem wir mehrere KI-Techniken einsetzen, um das Risiko zu mindern. Darüber hinaus ist GraphQL eine weit verbreitete, gut dokumentierte Abfragesprache, mit der die meisten GPT-Modelle vertraut sind und deren syntaktische Überprüfung mit zahlreichen Tools problemlos möglich ist. Dadurch wird die Wahrscheinlichkeit einer Halluzination verringert und die Richtigkeit kann vor der Verwendung sichergestellt werden.
Unter KI-Halluzinationen versteht man Fälle, in denen eine generative KI Ergebnisse produziert, die nicht auf tatsächlichen Daten oder Mustern basieren, sondern erfunden oder verzerrt sind. Diese Halluzinationen treten häufig aufgrund von Einschränkungen oder Verzerrungen in den Trainingsdaten der KI auf oder wenn die KI versucht, Ergebnisse für Situationen zu generieren, mit denen sie noch nie zuvor konfrontiert war. Halluzinationen können sich als erfundene oder unsinnige Inhalte oder Schlussfolgerungen äußern, die keinen logischen Sinn ergeben oder nicht mit den Eingabedaten übereinstimmen. Beispielsweise könnte eine textgenerierende KI Sätze produzieren, die zwar plausibel erscheinen, letztlich jedoch unsinnig sind oder keinen Bezug zum gegebenen Kontext haben.
GraphQL ist eine Open-Source-Abfragesprache für APIs (Application Programming Interfaces) und eine serverseitige Laufzeitumgebung zum Ausführen dieser Abfragen unter Verwendung eines für Daten definierten Typsystems. Es wurde von Meta (Facebook) entwickelt und soll eine effizientere, leistungsfähigere und flexiblere Alternative zu herkömmlichen RESTful-APIs bieten. GraphQL-APIs werden durch ein Schema definiert, das die Datentypen angibt, die abgefragt oder verändert werden können. Diese starke Typisierung ermöglicht bessere Werkzeuge, Introspektion und Validierung.
Unser Ansatz zur sicheren Einbindung generativer KI in die Sicherheit erfolgt in Form eines GPT-Agenten. Während die Verwendung einer gut dokumentierten Sprache hilft, das Risiko einer Halluzination zu verringern, mussten wir einen Weg finden, den Ausgabebereich unseres Agenten auf ein Format zu beschränken, das programmgesteuert auf Fehler überprüft werden kann, ohne dass vertrauliche Daten an OpenAI gesendet werden. Die Verwendung von GraphQL als Ausgabebereich funktioniert hier gut, da es ausdrucksstark genug ist, um die meisten Fragen zu beantworten, und gleichzeitig eine Abstraktion darstellt, die programmgesteuert anhand eines bekannten Schemas überprüft werden kann.
Obwohl wir diesen Ansatz auf DEX angewendet haben, funktioniert er für jeden ausreichend vernetzten und relationalen Datensatz, wie z. B.: soziale Netzwerke, Netzwerk- und Infrastrukturtopologien, Lieferketten und georäumliche (Kartierungs-)Daten.
Die PC-Graph-Architektur besteht aus Komponenten zur Umwandlung von DEX in eine Graphdarstellung. Die resultierenden Grafikdaten werden dann in einer Neo4j-Datenbank gespeichert. Die Ausgabe eines GPT-Agenten kann per API an einen GraphQL Apollo-Server übermittelt werden, der die Abfrage für die Graphdatenbank ausführt.
Unser Agent verwendet GPT4, um auf Anfragen in natürlicher Sprache nach Informationen zu in DEX geschriebenen Richtlinien zu antworten. Der Agent erreicht dies, indem er die PC-Graph-API versteht und mit einer entsprechenden Abfrage oder Mutation antwortet, die dann vom Benutzer überprüft und ausgeführt werden kann.
Zusätzlich zur PC-Graph-API versteht unser Agent auch die verwendeten Bibliotheken und einige Konzepte der DEX-Sprache. Diese Informationen werden sorgfältig ausgewählt und zur Laufzeit in den Kontext einbezogen, um optimale Ergebnisse zu erzielen.
Eine Herausforderung besteht darin, dass der Agent einen großen Kontext benötigt, um die relevanten Teile des Schemas sowie das ergänzende Material aufzunehmen, wie etwa die neo4j-graphQL-Dokumentation, die zusätzliche von der Bibliothek generierte Typen, Abfragen und Mutationen enthält. Bei der Verwendung von GPT4-8k fehlt uns einfach der Platz für angemessenes kontextbezogenes Lernen. Ein 32-K-Kontext führt zu akzeptablen Ergebnissen, verursacht jedoch auch zusätzliche Kosten. Beispielsweise müssen wir bei jeder Anfrage an OpenAI die GraphQL SDL (Schema Definition Language) senden. Dies wäre kein Problem, wenn wir GPT4-Konversationsmodelle mit unserem Schema optimieren könnten, sodass es nicht mehr in den Kontext aufgenommen werden müsste. Dies wird von OpenAI derzeit jedoch nicht unterstützt.
Wir haben drei KI-Ansätze gefunden, die die Ergebnisse von GPT4 verbessern:
Als letzten Schritt nutzen wir Tools, die eine statische Syntaxfehlerprüfung für GraphQL-Abfragen ermöglichen, um mögliche Trugschlüsse zu erkennen, die den anfänglichen Abwehrmaßnahmen entgangen sind.
Dieses Design wird noch weiter verbessert, indem zunächst drei mögliche Antworten in derselben Eingabeaufforderung generiert werden. Dadurch werden nicht nur der Zeit- und Kostenaufwand für eine bestimmte Eingabeaufforderung verringert, sondern auch die Konsistenz verbessert, da korrekte Aspekte einer Antwort mit größerer Wahrscheinlichkeit auftreten. Auf diese Weise haben wir auch Spielraum für zufällige Variationen, um unwahrscheinliche, aber genaue Optionen zu erkunden.
Durch unseren Ansatz konnten wir Erkenntnisse aus Richtlinien gewinnen, ohne private Daten weiterzugeben. Auch die Qualität und Konsistenz unserer Abfrageergebnisse haben sich deutlich verbessert. Die Zahl der Halluzinationen ist deutlich zurückgegangen, insbesondere bei Aufgaben, bei denen große oder komplexe Abfragen mit mehreren Filtern und/oder Aggregatfunktionen erstellt werden müssen.
In gewisser Weise können wir das Beste aus beidem machen: Wenn wir uns zwischen einem kreativen und einem deterministischen Akteur entscheiden müssen, tun wir einfach beides.