Akzeptanztest-getriebene LLM-Entwicklung für zuverlässige benutzerzentrierte KI-Systeme

Die Fähigkeiten großer Sprachmodelle (Large Language Models, LLMs) haben in den letzten Jahren massiv zugenommen und damit viele neue Anwendungsbereiche ermöglicht. Zum Beispiel kann ein natürlichsprachlicher, autonomer Telefonassistent das telefonische Buchen eines Termins in einer Arztpraxis automatisieren.

Diese neuen Anwendungsbereiche bringen jedoch auch neue Herausforderungen in der Entwicklung von KI-Systemen mit LLMs (LLM-Systemen) mit:

• In der Entwicklung, Validierung und Verifikation von LLM-Systemen treffen unterschiedliche Fachbereiche aufeinander, die Prozesse und bewährte Praktiken zusammenführen müssen.
• Die LLM-Systeme und deren Features sind für ganz neue Anwendungsbereiche, in denen noch niemand Erfahrung sammeln konnte, zu validieren, um zu entscheiden, welche Fähigkeiten des LLMs und welche LLM-Systeme mit welchen Features entwickelt werden sollten.
• Wie lassen sich das LLM und das LLM-System verifizieren und evaluieren trotz ihres natürlichsprachlichen und nichtdeterministischen Verhaltens? Die Entscheidung hängt auch vom Einsatzgebiet des LLM-Systems ab, insbesondere von der Einstufung bezüglich des akzeptierten Risikos auf die Gesamtbevölkerung, und bezüglich des akzeptierten Einflusses und Risikos auf den einzelnen Benutzer.

Die Firma Mediform ist diese Herausforderungen angegangen, indem sie einen akzeptanztestgetriebenen Entwicklungsstil für LLMs eingeführt hat, getauft ATDLLMD (Acceptance Test Driven LLM Development): Die Trainings- und Testsätze des LLMs werden in jeder Iteration durch Daten erweitert, die aus der Validierung des LLM-Systems aus der vorherigen Iteration stammen. Somit liefert die Validierungsphase die neuen oder aktualisierten (anonymisierten) Daten, um in der neuen Iteration das LLM noch besser trainieren und verifizieren zu können.

Um ATDLLMD umzusetzen, kommen drei Werkzeuge zum Einsatz: der innovative CPMAI-Prozess (Cognitive Process Management AI, siehe Abb. 1) und ein von der Firma Mediform neu entwickeltes Verifikationswerkzeug, LM-Eval.

Abb. 1: Das CPMAI-Prozess-Framework

Damit wird die LLM-Entwicklung mit ATDLLMD zu einem Rot-Train-Grün-Zyklus, der ATDD (Acceptance Test Driven Development, ATDD) ähnelt, aber bewährte Data-Science-Praktiken integriert. Mithilfe des Guaranteed Safe AI Framework (GS AI) bewerten wir die Sicherheitskritikalität unserer Anwendung auf die Gesamtbevölkerung und auf einzelne Anwender sowie die Stärke der Sicherheitsaussagen von ATDLLMD.

Herausforderungen durch LLMs

Die Fähigkeiten von LLMs nehmen rasant zu, wodurch zunehmend bessere Verarbeitung in natürliche Sprache, Schlussfolgerungen, Generalisierung und damit individuelle (Downstream-)Aufgaben ermöglicht werden. Deswegen hinken jedoch bewährte Praktiken, Prozesse und Werkzeuge bei der Entwicklung und Feinabstimmung dieser LLMs hinterher, insbesondere Werkzeuge zur Verifikation und Evaluierung der LLMs. Sunil Sharma drückt es etwa so aus, dass LLMs eine Technologie sind, die uns von Außerirdischen ohne Handbuch geschenkt wurde.

Es läuft letztlich auf drei Herausforderungen in der LLM-Entwicklung und Feinabstimmung heraus:

• Zusammenführen bewährter Praktiken aus verschiedenen Bereichen: Lassen sich bewährte Praktiken sowohl aus Softwareentwicklung (z. B. agil und testgetrieben), Data Science (Datenanalyse, Statistik, ML, Visualisierungen) als auch Safety Engineering (Risikomanagement, Sicherheitseinstufungen und -garantien, Zertifizierungen) in einen kohärenten, effektiven und modernen Entwicklungsprozess für LLMs integrieren? Dieser soll iterativ und agil validieren und nach Safety-Engineering-Standards verifizieren können.
• Validieren von Produkt- und LLM-Eigenschaften: Wie weit lassen sich LLMs und ihre neuartigen Fähigkeiten in natürlicher Sprachverarbeitung, im Schlussfolgern und Generalisieren vorantreiben, um völlig neue Anwendungen zu schaffen? Wie kann das LLM-System das Beste aus dem LLM herausholen, zum Beispiel durch eine Agentenarchitektur, also durch die Nutzung sogenannter Agenten? Wie reagieren Benutzer auf diese völlig neuen Anwendungen? Natürlich ist es wegen des großen Suchraums unmöglich, bei der Entwicklung und Verifikation alle Situationen abzudecken, sodass die Validierung nicht nur Szenarien für die Anwendung und für die LLM-Eigenschaften liefern muss, sondern auch Prioritäten.
• Verifizieren des LLM/-Systems: Durch ihre neuen Fähigkeiten können LLMs besser als vorherige Lösungen auf natürliche Sprache und auch verschiedene Situationen und Randfälle reagieren. Doch wie können diese natürlichsprachlichen Situationen ausgewertet und die Randfälle provoziert werden? Zusätzlich erschwert die Technologie die Verifikation: Neuronale Netze geben wenig interne Information preis und sind deswegen Black- oder Grey-Boxes, die sich nur anhand ihrer Textausgabe verifizieren lassen: Closed-Source-Modelle bieten bestenfalls Top-k-Log-Wahrscheinlichkeiten an. Open-Source-Modelle bieten Einblicke in deren Gewichte und in die versteckten Aktivierungen. Da diese Information der Verifikation aber meist wenig nützt, sind auch dies Grey-Box-Modelle.

Hinzu kommen noch die Herausforderung besserer Modellarchitekturen, Trainingstechniken und Modellkompressionen, die aber stets in Wissenschaft und Industrie intensiv erforscht werden.

Zusätzlich ist die LLM-Ausgabe häufig nicht deterministisch mit nur nuancierten semantischen Unterschieden in der natürlichen Sprache. Die Verifikation muss also die Sprache auch wirklich verstehen (z. B. durch semantische Ähnlichkeitserkennung) und Variationen in der Ausgabe für ein und dieselbe Eingabe behandeln (bspw. durch statistisches Testen). Aufgabenorientierte LLM-Systeme sollten in Bezug auf den Geschäftswert verifiziert werden, der aus den natürlichsprachlichen Ausgaben abzuleiten ist.

Abhängig von der Sicherheitskritikalität der Anwendung kann ein sehr hohes Vertrauen in deren Korrektheit und in andere Eigenschaften erforderlich sein, was dann Garantien und Zertifizierungen erfordert.

Der Anwendungsfall MediVoice

Das Start-up Mediform entwickelt den Telefon-Bot MediVoice, der Patientendienste telefonisch und autonom verwaltet: Patienten buchen Termine, erhalten Rezepte oder Überweisungsscheine oder Antworten auf allgemeine Fragen, alles in einem natürlichen Dialog, genau wie bei einer menschlichen medizinischen Fachangestellten (siehe Abb. 2 links).

Abb. 2: Patientendialoge von Happy-Paths (links) und Unhappy-Paths (rechts)

MediVoice ersetzt also eine medizinische Fachangestellte in natürlichen aufgabenorientierten Telefongesprächen (Task-Oriented Dialogues, TODs. Damit löst MediVoice den Personalmangel in den Arztpraxen und verbessert den Zugang der Patienten zu medizinischen Leistungen, da Patienten somit wieder Arztpraxen telefonisch erreichen können.

Da MediVoice einen hohen Grad an Autonomie erreicht, gewinnen medizinische Fachangestellte Zeit für die Behandlung von Patienten in der Praxis. Die folgenden Abschnitte beschreiben, wie das Start-up Mediform die drei genannten Herausforderungen angeht.

Zusammenführen bewährter Praktiken

Mediform entwickelt zwar keine LLMs von Grund auf (Foundational Models), aber verwendet diverse Techniken, um Foundational Models auf den Anwendungsfall abzustimmen. Dafür muss Mediform bewährte Praktiken aus separaten Bereichen zusammenführen:

• Data Science und Data Engineering, um Tausende von Arztpraxis-Dialogen zu verarbeiten: anonymisierte Dialoge von Patienten sowie von KI generierte also auch regelbasiert generierte Dialoge.
• maschinelles Lernen, von Continual Pre-Training, Fine-Tuning und Knowledge Distillation über Modellkompressionen bis hin zu Prompt Engineering, Retrieval und agentischem Verhalten.
• Agilität, um passende, neue Anwendungen in unbekanntem Terrain entwickeln zu können.
• Safety Engineering, um den Bedarf an Sicherheitsgarantien für eine bestimmte Anwendung abzuschätzen und zu erfüllen.

Zur Sicherheitseinstufung hat Anthropic die AI Safety Levels (ASLs) eingeführt, die eine Form von Safety Integrity Level (SIL) sind, wie sie in anderen Bereichen wie programmierbarer Elektronik (ISO 61508) und Automotive (ISO 26262) üblich sind. Das ASL bestimmt das geeignete Maß an Vorsicht für ein gegebenes KI-System, abhängig von dessen Fähigkeiten.

Da MediVoice keine medizinischen Ratschläge gibt, sondern sich auf Patientenmanagement wie Terminbuchungen konzentriert, stellt sein Einsatz kein sicherheitsgefährdendes Risiko dar. Ein gefährliches autonomes Verhalten ist also nicht zu erwarten. Daher fällt MediVoice unter die niedrigste Stufe, ASL-1. Betriebsfehler, wie das Übersehen einer medizinischen Dringlichkeit, erhöhen MediVoice nicht auf ASL-2, da es keine autonomen Fähigkeiten mit höherem Potenzial für Missbrauch oder Schaden für die Bevölkerung demonstriert.

Weil MediVoice ASL-1 ist, erzwingt das GS AI Framework keinerlei Sicherheitsgarantien für MediVoice. Im Zuge des EU AI Act ist feiner zu differenzieren: Chatbots fallen im Allgemeinen in die zweitniedrigste Sicherheitsstufe (limited risk AI systems), für die nur garantiert werden muss, dass die Benutzer wissen, dass sie mit einer KI interagieren. Nach Annex III fallen KI-Systeme, die personenbezogene Daten, unter anderem im Gesundheitswesen, automatisiert verarbeiten, in die nächsthöhere Sicherheitsstufe (high-risk). Nach Recital 53 bleiben allerdings KI-Systeme in niedrigeren Sicherheitsstufen, wenn diese eine verfahrenstechnische, enge Aufgabe erfüllen, was bei Patientenmanagement ohne medizinische Auskunft der Fall ist.

Da allerdings eine nicht erkannte medizinische Dringlichkeit bei einer Terminbuchung zu ernsthaften Schäden für einzelne Patienten führen kann, versuchen wir dennoch, mithilfe von GS AI eine hohe Sicherheitsgarantie zu erreichen.

Safety Engineering, Agilität, Data Science und ML müssen zusammen in einen Prozess eingebettet werden. Die meisten Prozesse im Bereich Data Science und maschinelles Lernen sind eine Erweiterung von CRISP-DM, dem Cross-Industry Standard Process – Data Mining. Zum Beispiel ist [10/https://dl.gi.de/items/3ba69181-fd38-49b6-a14c-8484fb5177e0] eine Erweiterung, die sich nur auf Prompt Engineering konzentriert, während sich CRISP-ML auf Automotive- und Wasserfallprozesse fokussiert und Agilität ignoriert.

Agilität ist aber für kurze Iterationen mit Kundenfeedback für geschäftszentrierte Validierung und für moderne Softwareentwicklungspraktiken erforderlich. Nach unserem Kenntnisstand gibt es nur einen Standardprozess, um sowohl einen daten- als auch einen geschäftszentrierten und agilen Ansatz zu ermöglichen, der modern, KI-spezifisch und anbieterneutral ist: das Cognitive Process Management for AI (CPMAI) von Cognilytica (siehe Abb. 1). Im Kern des Prozesses befinden sich die Daten, die in jeder der sechs Phasen gelesen, modifiziert oder erweitert werden:

• Business Understanding, um Geschäfts- und Organisationsanforderungen zu sammeln, zu verstehen, und auf eine KI-Lösung abzubilden.
• Data Understanding, was die dazugehörigen Daten-(Qualitäts-)Anforderungen und Datenquellen identifiziert.
• Data Preparation, was die Trainings- und Testdatensätze durch Datenbereinigung, -aggregation, -augmentation und -transformation vorbereitet.
• Data Modeling, was eine KI-Lösung entwickelt, mit Fokus auf der Wahl der Modellarchitektur, Trainingstechnik und Hyperparameter, auf dem eigentlichen Modelltraining, und der Modelloptimierung.
• Model Evaluation, das die Fehler analysiert und Metriken wie Precision, Recall, Accuracy und mehr geschäftszentrierte KPIs in Bezug auf Qualität, Leistung und andere Ilities misst. Dies hilft zu entscheiden, ob die KI-Lösung die Ziele der Iteration erfüllt, die aus den Geschäfts- und Organisationsanforderungen abgeleitet wurden.
• Model Operationalization: führt Modellversionierung, Modellbereitstellung (Deployment und Staging) und Modellüberwachung (Monitoring) durch, um die KI-Lösung der Iteration für die Stakeholder bereitzustellen.

Im Gegensatz zu CRISP-DM, CRISP-ML und anderen Erweiterungen bietet CPMAI nicht nur einen Schritt von der Model-Evaluation- zur Business-Understanding-Phase zurück, sondern hat moderne agile Praktiken vollständig integriert: Es umfasst Model Operationalization mit modernen DevOps-Praktiken, einschließlich Staging, und ermöglicht so kontinuierliches Kundenfeedback. Mithilfe der Datenzentriertheit lässt sich beliebig zwischen den sechs Phasen wechseln. Das ermöglicht eine einfache Einbettung aktueller Entwicklungspraktiken, zum Beispiel Test-Driven Development (TDD) mit seinem Rot-Grün-Refaktorisierzyklus.

Validieren von Produkt- und LLM-Eigenschaften

Da Stakeholder (insbesondere Mediziner, medizinische Fachangestellte und Patienten) nicht im Voraus wissen, was möglich ist und was sie von der MediVoice-Anwendung wollen, entwickeln sich ihre Erwartungen schnell weiter. Mediform muss folglich in der Lage sein, sich schnell auf die geänderten Anforderungen und Ziele der Stakeholder anzupassen. Daher benötigt Mediform kurze Iterationszyklen mit häufigem Feedback der Stakeholder.

Zum Beispiel gewann Mediform durch kurze Feedback-Schleifen interessante Erkenntnisse darüber, wie sich Patienten am Telefon verhalten:

• Aufgrund früherer schlechter Erfahrungen mit schlecht funktionierenden Telefon-Bots mit schwacher UX sind Patienten oft sehr skeptisch gegenüber den Fähigkeiten von MediVoice oder werden schnell wütend oder ungeduldig (siehe Abb. 2, oben rechts).
• Ein Dialog, der von einem Arzt als erfolgreich angesehen wird, ist nicht unbedingt erfolgreich für den Patienten (siehe Abb. 2, unten rechts).
• das unerwartete Patientenverhalten, dass über 80-Jährige effektiver mit MediVoice interagieren als jüngere Patienten.

Mediform hat für MediVoice ein Backend mit Interaction Analytics auf anonymisierten Patientendialogen (siehe Abb. 3) entwickelt:

Abb. 3: Mediforms Interaction Analytics auf anonymisierten Patientendialogen

Es bewertet Dialoge nach ihrer Länge, ihrem Autonomiegrad und ihren Kosten. Alle Dialoge werden nach der Absicht des Patienten und dem Versicherungstyp klassifiziert und aufgelistet, zusammen mit einer Zusammenfassung. Diese Interaction Analytics helfen im Business Understanding, fehlerhafte oder nicht zufriedenstellende Dialoge zu finden. Fehleranalysen in der Data-Understanding-Phase sorgen dafür, Anwendungsfälle und Dialoge in Bezug auf Geschäftsanforderungen und Geschäftsprozesse zu verstehen und zu priorisieren.

Die Ergebnisse der Fehleranalyse dienen in der Data-Preparation-Phase dazu, relevante Trainings- und Testsätze zu aktualisieren und zu erweitern. Diese Datensätze enthalten (verallgemeinerte) Dialoge zwischen Patienten und Praxis, welche die Geschäftsanforderungen und Geschäftsprozesse widerspiegeln. Somit sind alle in unserem CPMAI-Zyklus verwendeten Daten zu einer Form von (anonymisiertem) Patientendialog mit Metadaten vereinheitlicht: Ein Dialog, möglicherweise generalisiert durch Template-Variablen, basiert auf einem gewünschten Gesprächsverhalten, das aus den anonymisierten Patientendialogen abgeleitet wurde. Die (templatisierten) Patiententexte sind der Testtreiber, die Antworten (mehrere Alternativen sind möglich) des Telefonassistenten die Testorakel. Die Trainings- und Testsätze decken eine breite Palette solcher Dialoge ab, wodurch die Aussagekraft der Evaluation des LLMs erhöht wird.

Wir erweitern CPMAI um einen ATDD-Stil der LLM-Entwicklung: Durch den oben beschriebenen Prozess sind die (templatisierten) Dialoge innerhalb der Trainings- und Testsätze geschäftszentriert. Sie lassen sich also als Akzeptanztests (ATs) betrachten, das heißt als Tests, die auf Anforderungen der Kunden basieren. Durch die Verwendung eines AT-getriebenen Prozesses innerhalb unserer CPMAI-Iterationen erweitern wir CPMAI, getauft ATDLLMD. Im Gegensatz zu klassischem ATDD erfordert ATDLLMD nicht, dass für die Akzeptanz alle ATs bestehen. Wie es bei ML-Evaluierungen üblich ist, ist ein Schwellenwert für eine Metrik (z. B. Accuracy) zu überschreiten. Wenn Kunden wissen, dass das LLM gegen kundenorientierte Testfälle mit einer geeigneten Metrik trainiert und getestet wurde, steigt ihr Vertrauen in das System.

Verifizieren des LLMs/-Systems

Zur Durchführung von ATDLLMD ist ein Verifikationswerkzeug nötig. Im Anwendungsfall MediVoice lassen sich die obigen Herausforderungen zum Verifizieren des LLMs/-Systems folgendermaßen konkretisieren:

• Das Einbetten unserer Verifikation in GS AI erfordert drei Komponenten: erstens ein sogenanntes Weltmodell, das beschreibt, wie das KI-System die Außenwelt beeinflusst. Daraus wird dann ein geeigneter Testtreiber abgeleitet; zum Beispiel müssen wir einzelne, individuelle Geschäftsprozesse für jede Arztpraxis abdecken. Zweitens eine Sicherheitsspezifikation, die angibt, welche Auswirkungen akzeptabel sind. Daraus wird dann ein geeignetes Testorakel abgeleitet; etwa solche, die vom individuellen Geschäftsprozess abhängen. Drittens einen Verifikator, der einen überprüfbaren Nachweis bereitstellt, dass die KI die Sicherheitsspezifikation relativ zum Weltmodell erfüllt.
• Zur Verifikation aufgabenorientierter LLM-Systeme ist die Verwendung von Standardverifikationswerkzeug und Standardmetriken [4/https://dl.acm.org/doi/full/10.1145/3641289] zu generisch, weil wir unsere LLMs auf geschäftsorientierte Weise verifizieren müssen.
• Die Verifikation muss viele natürlichsprachlichen Fähigkeiten des LLMs untersuchen: Kann das LLM mit gebrochener Sprache, verschiedenen Fremdsprachen und Fehlern in der Spracherkennung umgehen? Kann das LLM praxisspezifische Geschäftsprozesse verstehen, die in natürlicher Sprache spezifiziert wurden? Kann das LLM ausreichend generalisieren und domänenspezifische Randfälle bewältigen?

Um diese Herausforderungen beim Verifizieren des LLMs/-Systems zu bewältigen, hat Mediform ein eigenes Testwerkzeug namens LM-Eval entwickelt, das auf EleutherAIs Language Model Evaluation Harness (LMEH) aufbaut. LMEH wird auch von Hugging Face verwendet. Es enthält bereits viele Benchmarks, Prompts und Metriken, bietet aber auch die Möglichkeit, sie zu erweitern und benutzerdefinierte Modelle zu evaluieren.

Um unsere Testdatensätze mit templatisierten Dialogen als Benchmark in LM-Eval auszuführen und unsere MediVoice-Modelle zu evaluieren, haben wir Folgendes zu LMEH hinzugefügt (siehe Abb. 4):

Abb. 4: Mediforms LM-Eval Testing Framework

• unseren eigenen Testtreiber, um die Testausführung natürlicher Dialoge in unserem eigenen Format zu ermöglichen, mit Template-Variablen und Metadaten für individuelle Geschäftsprozesse.
• unsere eigenen geschäftszentrierten Testorakel und Metriken zur domänenspezifischen Evaluierung natürlicher Dialoge. Zum Beispiel aggregieren wir statistisch, indem wir individuelle Ergebnisse basierend auf ihrer semantischen und geschäftlichen Relevanz gewichten.
• Funktionen zum Testen nicht deterministischer Black-Boxes, unter anderem mittels semantischer Vergleiche (z.B. vergleichen wir pre-Aufrufe strenger als msg-Aufrufe, siehe Abb. 4) und der Angabe mehrerer erlaubter, alternativer Ausgaben.

Im Sinne des Guaranteed Safe AI Framework verwendet unser Testing mit LM-Eval:

• templatisierte Dialoge als Weltmodell, das zwischen Weltmodell-Level W0 und W1 liegt (auf einer Skala von W0 (am schwächsten) bis W5 (am stärksten).
• mehrere, alternative Assistenznachrichten in templatisierten Dialogen als Sicherheitsspezifikation, die auf Sicherheitsspezifikations-Level S3 liegt (vom schwächsten S0 bis zum stärksten S7).
• LM-Eval als Verifikator, der auf Verifikator-Level V2 für feste Template-Variablen-Substitutionen und auf V3 liegt, wenn die Substitution über vollständige Wertemengen randomisiert wird (vom schwächsten V0 bis stärksten V10).

Mediform verwendet ergänzende Testmethoden, die ATDLLMD in einem Ensemble begleiten: unter anderem Smoke-Tests und Monitoring. Dieses Vorgehen bietet weitere Einblicke in das Verhalten von MediVoice und erhöht somit das Vertrauen. Dies passt zum Vorschlag von GS AI, zusätzlich „Defence in Depth“ zu verwenden, indem mehrere Schutzschichten eingesetzt werden, um sich gegen komplexe Bedrohungen zu verteidigen.

Für die Smoke-Tests werden bestimmte Szenarien und Patientenverhalten spezifiziert, von einem LLM interpretiert und gegen MediVoice ausgeführt. Im Sinne von GS AI hat dies:

• ein LLM mit in-kontext erlerntem Patientenverhalten als Weltmodell auf Level W1,
• die spezifizierten Szenarien mit gewünschtem Kontrollfluss als Sicherheitsspezifikation auf Level S3,
• das LLM, das die spezifizierten Szenarien verifiziert, als Verifikator auf Level V2.

Mediform überwacht auch reale (anonymisierte) Patientendialoge mit einem Laufzeit-Monitor zum Erkennen von Fehlern, etwa Halluzinationen, um verbleibende Fehler und Erkenntnisse zu erfassen. Im Sinne von GS AI hat der Monitor:

• die reale Welt als Weltmodell, da in Produktion getestet wird. Als alleinige Testmethode wäre dieses Monitoring inakzeptabel, weswegen es wohl auch nicht in erwähnt wird. Für „Defence in Depth“ ist Testen in Produktion aber eine sehr aufschlussreiche Ergänzung, gerade weil es die Reaktionen der realen Welt observiert. Deswegen stufen wir es, analog einer physikalischen Weltsimulation, auf W4 ein.
• eine regelbasierte Spezifikation, die auf bestimmte Muster wie verfrühtes Auflegen prüft, sowie eine Spezifikation zu intrinsischer und extrinsischer Halluzination, die auf Widersprüche zwischen der Systemnachricht für das LLM und dem Dialog prüft, als Sicherheitsspezifikation, was auf Level S2 ist.
• eine regelbasierte Prüfung sowie ein Halluzinationserkennungs-LLM als Verifikator. Da sich beim Monitoring die Testabdeckung nicht kontrolliert erhöhen lässt, wird dieser Verifikator analog zu einem standardisierten Testsatz als V2 eingestuft.

CPMAI kann das Guaranteed Safe AI Framework einbetten:

• Die Data-Preparation-Phase aktualisiert die Sicherheitsspezifikation und das Weltmodell, basierend auf den Erkenntnissen aus den Phasen Business Understanding und Data Understanding.
• Die Model-Evaluation-Phase wendet das Verifikationswerkzeug an, um das neu entwickelte Modell zu evaluieren, idealerweise mit quantifizierbaren Sicherheitsgarantien.
• Die Model-Operationalization-Phase setzt Modellüberwachung (Laufzeit-Monitore) ein, falls erwünscht.

Kombinieren aller Lösungen

Ein Roundtrip durch CPMAI mit ATDLLMD sieht demnach folgendermaßen aus: In der Model-Operationalization-Phase sammeln wir iterativ Dialoge. Das heißt, die realen Interaktionen der Patienten mit unserem Telefon-Bot. Wir anonymisieren diese in DSGVO-konformen Weise und führen dann Business und Data Understanding darauf durch, mithilfe unseres Interaction Analytics Dashboard sowie manueller Exploration. Anhand der gesammelten Dialoge, insbesondere solcher mit unerwünschtem Verhalten und den Erkenntnissen aus deren Fehleranalysen, aktualisieren wir Dialoge und möglicherweise die Weltmodelle und Sicherheitsspezifikationen in der Data-Preparation-Phase.

Zusätzlich erstellen wir neue Dialoge mit dem entsprechenden gewünschten Verhalten. Die Dialoge werden als Trainingsdaten oder Akzeptanztests spezifiziert, welche die aktuelle CPMAI-Iteration von Rot (fehlschlagende Akzeptanztests) während der Data Preparation, über Data Modeling (Training), zu Grün (bestehende Akzeptanztests) während Model Evaluation und Operationalization leiten. Testausführung und Evaluierung werden von LM-Eval und ergänzenden Testmethoden durchgeführt. Im Gegensatz zu klassischem ATDD müssen nicht alle Akzeptanztests grün werden, sondern nur genug, um die geforderte Metrik zu erreichen, etwa 95 Prozent Accuracy. Dieser Rot-Train-Grün-Zyklus in ATDLLMD ähnelt ATDD, integriert aber bewährte Praktiken von Data Science. Er folgt CPMAI, nutzt aber weitere zeitgemäße Praktiken der Softwareentwicklung, des Testings und des Safety Engineering.

Fazit

Wir haben ATDLLMD mithilfe von Mediforms Testwerkzeug LM-Eval und den Sicherheitskonzepten von GS AI in CPMAI eingebettet. Das haben wir anhand einer Fallstudie vorgestellt: dem autonomen Telefon-Bot MediVoice. Obwohl unsere Anwendung ASL-1 ist, geben wir Sicherheitsgarantien mit einem Ensemble von Testmethoden, mit Weltmodellen bis Level W4, Sicherheitsspezifikation bis Level S3 und Verifikatoren bis Level V3.

Zusammenfassend stellt die Anwendung von ATDD auf die Entwicklung und Feinabstimmung von LLMs einen bedeutenden Schritt nach vorne bei der Entwicklung zuverlässigerer und benutzerzentrierter KI-Systeme dar. Der ATDLLMD-Ansatz verbessert nicht nur den Entwicklungsprozess und die Qualität der Ausgaben, sondern stärkt auch das Vertrauen der Benutzer in KI-Technologien.

Literaturangaben

[1] Anthropic’s Responsible Scaling Policy Report, 2023, siehe: assets.anthropic.com/m/24a47b00f10301cd/original/Anthropic-Responsible-Scaling-Policy-2024-10-15.pdf

[2] Anthropic’s Responsible Scaling, 2023, siehe: www.anthropic.com/news/anthropics-responsible-scaling-policy

[3] T. Brown et al., Language models are few-shot learners, in: NeurIPS 33, 2020, siehe: arxiv.org/abs/2005.14165

[4] Y. Chang et al., A survey on evaluation of large language models, in: ACM TIST, 2024, siehe: dl.acm.org/doi/full/10.1145/3641289

[5] W. Chen et al., Systems engineering issues for industry applications of large language model, in: Applied Soft Computing 151, 2024, siehe: dl.acm.org/doi/10.1016/j.asoc.2023.111165

[6] David „davidad“ Dalrymple et al., Towards Guaranteed Safe AI: A Framework for Ensuring Robust and Reliable AI Systems, 2024, siehe: arxiv.org/abs/2405.06624

[7] Cognilytica, The Seven Patterns of AI, siehe: www.cognilytica.com/glossary/seven-patterns-of-ai/

[8] Cognilytica, Cognitive Project Management For AI, siehe: www.cognilytica.com/what-is-the-cognitive-project-management-for-ai-cpmai-methodology

[9] Cross Industry Standard Process for Data Mining 1.0., siehe: www.semanticscholar.org/paper/CRISP-DM-1.0:-Step-by-step-data-mining-guide-Chapman/54bad20bbc7938991bf34f86dde0babfbd2d5a72

[10] EU Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending Regulations, siehe: eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

[11] D. Faragó, Engineering A Reliable Prompt for Generating Unit Tests – Prompt engineering for QA & QA for prompt engineering, in: STT 43(3), 2023, siehe: dl.gi.de/items/3ba69181-fd38-49b6-a14c-8484fb5177e0

[12] L. Gao et al., A framework for few-shot language model evaluation, 2023, siehe: zenodo.org/records/5371629

[13] Github, How to build an enterprise LLM application: Lessons from GitHub Copilot, siehe: github.blog/ai-and-ml/github-copilot/how-to-build-an-enterprise-llm-application-lessons-from-github-copilot

[14] Hugging Face, Open LLM Leaderboard, 2024, siehe: huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard#

[15] E. Hosseini-Asl et al., A simple language model for task-oriented dialogue, in: NeurIPS 33, 2020, siehe: proceedings.neurips.cc/paper/2020/file/e946209592563be0f01c844ab2170f0c-Paper.pdf

[16] Ji et al., Survey of hallucination in natural language generation, in: ACM Computing Surveys 55.12, 2023, siehe: dl.acm.org/doi/10.1145/3571730

[17] J. Kaplan et al., Scaling laws for neural language models, arXiv:2001.08361, 2020, siehe: arxiv.org/abs/2001.08361

[18] Mediform, Ältere Menschen buchen problemlos Termine via MediVoice, 2024, siehe: www.linkedin.com/posts/mediform-gmbh_mediform-medivoice-sprachassistent-activity-7161312720561004544-mFSp

[19] Mediform, Die Revolution für das Praxistelefon, siehe: mediform.io/medivoice

[20] S. Minaee et al., Large language models: A survey, 2024, siehe: arxiv.org/abs/2402.06196

[22] N. Röttger, G. Runze, V. Dietrich, Basiswissen KI-Testen: Qualität von und mit KI-basierten Systemen: Aus- und Weiterbildung zum Certified Tester AI Testing, dpunkt verlag 2024

[22] S. Sharma, Large Language Models (LLMs): A Technology Gifted by Aliens Without a Manual, 2023, siehe: blog.gramener.com/large-language-models-llms-technology

[23] S. Studer et al., Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology. ML and knowledge extraction 3.2., 2021, siehe: www.mdpi.com/2504-4990/3/2/20

[24] A. Vaswani et al., Attention is all you need, in: NeurIPS 30, 2017, siehe: arxiv.org/abs/1706.03762