Dann haben Sie diese Scenario bereits erlebt, in der es so aussieht, als ob Ihr RAG-System intestine funktioniert, es aber immer noch falsch ist. Der Abruf ruft einige Blöcke ab, übergibt sie an das generative Modell und schreibt eine flüssige Antwort. Nichts wirft einen Fehler aus, und dennoch basiert die Antwort möglicherweise auf dem falschen Dokument, es fehlen die Hälfte der benötigten Informationen oder sie basiert auf etwas, das technisch wahr ist, aber drei Versionen veraltet ist. Die einzige Möglichkeit, dies tatsächlich zu erkennen und zu mildern, besteht darin, es regelmäßig richtig zu bewerten.

In diesem Artikel erfahren Sie, wie Sie diese Evaluierungspipeline selbst aufbauen können, beginnend mit den Teilen, die zu einfach erscheinen, um darüber zu schreiben, über die automatisierte Evaluierung mit RAGAS bis hin zu dem Punkt, an dem RAGAS nicht mehr ausreicht, und was es braucht, um dies als tatsächlichen Prozess und nicht als Notizbuch, das Sie vor einem Stakeholder-Assembly öffnen, auszuführen. Die Schritte sind so geschrieben, dass Sie sie für Ihre eigene RAG-Anwendung befolgen und sie nicht nur als Theorie lesen können.

Dies ist Teil 4 von Die RAG for Enterprise-Reiheund wenn Sie die früheren Teile verpasst haben, würde ich Ihnen dringend empfehlen, sich Teil 3 hier anzusehen: Hybride Suche und Neubewertung im Produktions-RAG

Was steht in diesem Artikel?

1. Aufbau des Goldenen Datensatzes
2. Führen Sie vor der Automatisierung eine einfache manuelle Bestandsprüfung durch
3. Automatisieren Sie das Scoring mit RAGAS
4. Hinzufügen eines benutzerdefinierten LLM-Richters für das, was RAGAS nicht prüfen kann
5. Mit einem Menschen auf dem Laufenden bleiben
6. Achten Sie nach dem Versand des Techniques auf Abweichungen
7. Führen Sie es als Pipeline aus
8. Abschluss

---

Aufbau des Goldenen Datensatzes

Bevor Sie eine Bewertungsbibliothek anfassen, benötigen Sie eine Reihe von Fragen mit bekanntermaßen richtigen Antworten. Dies nennt man a Goldener Datensatzund das Überspringen ist der häufigste Fehler, den Groups bei der Arbeit an einem RAG-System machen. Wenn Sie RAGAS direkt auf zufälligen Abfragen ausführen, ohne dass es einen Vergleich gibt, erfahren Sie quick nichts darüber, ob das System tatsächlich richtig oder falsch ist.

Ein guter goldener Datensatzeintrag besteht aus drei Teilen: der Frage, einer korrekten Antwort, die von jemandem geschrieben wurde, der sich mit dem Fachgebiet auskennt, und dem Dokument, das die Antwort enthält. Mit dem dritten Feld können Sie einen Abruffehler (falscher Block abgerufen) von einem Generierungsfehler (richtiger Block, falsche daraus geschriebene Antwort) unterscheiden. Dabei handelt es sich um unterschiedliche Fehler mit unterschiedlichen Korrekturen, und ein Datensatz ohne dieses Feld lässt Sie beim Debuggen blind zurück.

golden_set = (
    {
        "query": "What's the most file dimension for uploads?",
        "ground_truth": "25 MB per file on the free plan, 200 MB on paid plans.",
        "source_doc": "upload_limits.md",
        "class": "single_fact",
    },
    {
        "query": "Can I cancel my subscription mid-cycle and get a refund?",
        "ground_truth": "No, cancellations take impact on the finish of the billing cycle. No partial refunds.",
        "source_doc": "billing_policy.md",
        "class": "single_fact",
    },
)

Zwanzig bis dreißig Fragen reichen aus, um zu Beginn ein echtes Sign zu erhalten. Das Kategoriefeld ist wichtiger als die Anzahl der Einträge, und hier investieren die Groups normalerweise am meisten. Ein Datensatz, der nur aus einfachen sachlichen Nachschlagevorgängen besteht, wird alles passieren und Ihnen nichts sagen, da einfache sachliche Nachschlagevorgänge der einzige Fehlermodus sind, den RAG-Systeme selten haben. Die Kategorien, die es wert sind, hinzugefügt zu werden, in der Reihenfolge, in der sie in der Produktion tatsächlich Anklang finden:

• Multi-Hop – Für die Antwort müssen zwei oder mehr Blöcke kombiniert werden, was beim Abrufen zu einem stillschweigenden Unterabruf führt
• Keine Antwort erwartet – Das richtige Verhalten besteht darin, die Antwort zu verweigern und nicht aus dem nächsten semantisch ähnlichen Block zu raten
• Widersprüchliche oder veraltete Dokumente – Im Korpus gibt es eine alte und eine aktuelle Model derselben Richtlinie, von denen nur eine richtig ist
• Widersprüchliche Formulierung – Dieselbe Frage wurde mit einer anderen Terminologie gestellt als im Quelldokument

Die dritte Kategorie „Widersprüchliche oder veraltete Dokumente“ ist die am häufigsten übersprungene Kategorie in den goldenen Sätzen und auch diejenige, die tendenziell mehr Produktionsvorfälle im Zusammenhang mit einer Antwort hervorruft, die fließend und intestine zitiert struggle, aber vollständig auf einem Dokument aufbaute, zu dessen Archivierung niemand gekommen struggle. Wenn sich in Ihrem Korpus alte Versionen von Dingen ansammeln (was bei den meisten Dokumentenspeichern in Unternehmen der Fall ist), muss Ihr Evaluierungssatz darauf testen, sonst ist Ihre Pipeline genauso blind dafür wie Ihre Prüfer.

---

Führen Sie vor der Automatisierung eine einfache manuelle Bestandsprüfung durch

Führen Sie das goldene Set durch Ihre Pipeline und lesen Sie die Antworten neben der Grundwahrheit, bevor Sie ein Bewertungstool einrichten. Dieser Schritt wird ständig übersprungen, weil er sich zu einfach anfühlt, um echte Ingenieursarbeit zu sein. Er zeigt Ihnen jedoch, ob Ihr Datensatz selbst solide ist, und gibt Ihnen ein Gefühl dafür, wie „falsch“ in Ihrem spezifischen System aussieht, bevor Sie einer Metrik vertrauen, die es für Sie erkennt.

outcomes = ()
for merchandise in golden_set:
    reply = rag_pipeline.question(merchandise("query"))
    outcomes.append({
        "query": merchandise("query"),
        "generated_answer": reply,
        "ground_truth": merchandise("ground_truth"),
        "appropriate": None,  # fill in manually
    })

Dadurch werden peinliche Fehler frühzeitig erkannt, z. B. eine defekte Eingabeaufforderungsvorlage, ein Retriever, der nichts zurückgibt, ein Modell, das den Kontext vollständig ignoriert usw. Durch die Automatisierung der Bewertung einer defekten Pipeline erhalten Sie lediglich eine genaue Zahl für etwas, das niemals nützlich sein würde.

---

Automatisieren Sie das Scoring mit RAGAS

Sobald die Grundlagen stimmen, bietet Ihnen RAGAS eine schnelle und wiederholbare Möglichkeit, die Pipeline in vier Dimensionen zu bewerten, ohne jede Antwort von Hand lesen zu müssen.

from ragas import consider
from ragas.metrics import (
    context_precision,
    context_recall,
    faithfulness,
    answer_relevancy,
)
from datasets import Dataset

eval_dataset = Dataset.from_list((
    {
        "query": merchandise("query"),
        "reply": rag_pipeline.question(merchandise("query")),
        "contexts": rag_pipeline.retrieve(merchandise("query")),
        "ground_truth": merchandise("ground_truth"),
    }
    for merchandise in golden_set
))

consequence = consider(
    eval_dataset,
    metrics=(context_precision, context_recall, faithfulness, answer_relevancy),
)
print(consequence)

• Kontextpräzision – Wie viele der abgerufenen Brocken waren tatsächlich related, was das Rauschen benachteiligt?
• Kontexterinnerung – schätzt, ob beim Abruf die Informationen erfasst wurden, die zur Erstellung der Referenzantwort erforderlich sind
• Treue – ist die Antwort, die auf dem Abgerufenen basiert und eine Halluzination hervorruft
• Antwortrelevanz – Bezieht sich die Antwort auf die eigentliche Frage und nicht auf eine nahegelegene Frage?

Ein typischer Lauf sieht in etwa so aus (die Zahlen dienen zur Erläuterung der einzelnen Metriken):

Metrisch	Punktzahl
Kontextpräzision	0,81
Kontextrückruf	0,74
Treue	0,88
Antwortrelevanz	0,85

Ein hoher Treuewert wird als „die Antwort ist richtig“ interpretiert, und das ist genau die Fehlinterpretation, die schlechte Antworten durchlässt. Faithfulness prüft nur, ob die Antwort durch den abgerufenen Kontext unterstützt wird oder nicht, es sagt nicht aus, ob dieser Kontext der richtige Abruf struggle. Ein veraltetes oder veraltetes Dokument liefert, getreu zusammengefasst, eine Antwort, die völlig fundiert und gleichzeitig völlig falsch ist. Dies ist die strukturelle Grenze von RAGAS: Es ist sehr intestine darin, Halluzinationen zu erkennen, und sehr schlecht darin, eine sicher falsche Quelle zu erkennen.

---

Hinzufügen eines benutzerdefinierten LLM-Richters für das, was RAGAS nicht prüfen kann

Die meisten RAGAS-Metriken basieren auf einer LLM-basierten Auswertung mit vordefinierten Eingabeaufforderungen, die nichts über Ihre Area wissen. Wenn die Korrektheit für Sie von etwas Bestimmtem abhängt, wie z. B. genauen Zahlen, der Aktualität der Quelle, einem erforderlichen Haftungsausschluss, dem Ton usw., wird sie von den Standardaufforderungen nicht erfasst, da sie nie dazu aufgefordert wurde.

Um dieses Downside zu lösen, können Sie einen LLM als Richter einsetzen und ihm eine benutzerdefinierte Eingabeaufforderung übergeben, die ihn anweist, die Antworten auf der Grundlage Ihrer spezifischen Bedürfnisse zu beurteilen.

import json
from google import genai
from google.genai.varieties import GenerateContentConfig

shopper = genai.Shopper(
    vertexai=True,
    mission="YOUR_GCP_PROJECT_ID",
    location="us-central1",
)

JUDGE_PROMPT = """
Evaluate the generated reply to the bottom fact. Rating 1-5 on every dimension.

Query: {query}
Floor Fact: {ground_truth}
Generated Reply: {reply}
Supply Doc Date: {doc_date}

1. numeric_accuracy - are all numbers and information appropriate, not simply believable?
2. recency_awareness - if the supply is outdated, does the reply flag
   uncertainty as a substitute of stating it as present reality?

Return JSON solely:
{{
    "numeric_accuracy": int,
    "recency_awareness": int,
    "reasoning": str
}}
"""

def custom_judge(query, ground_truth, reply, doc_date, shopper):
    immediate = JUDGE_PROMPT.format(
        query=query,
        ground_truth=ground_truth,
        reply=reply,
        doc_date=doc_date,
    )

    response = shopper.fashions.generate_content(
        mannequin="gemini-2.5-flash",
        contents=immediate,
        config=GenerateContentConfig(
            temperature=0,
            max_output_tokens=250,
            response_mime_type="software/json",
        ),
    )

    return json.masses(response.textual content)

Führen Sie dies nicht jedes Mal für den gesamten Datensatz aus, da es langsamer ist und mehr professional Aufruf kostet als RAGAS. Beschränken Sie es auf die Kategorien, in denen die RAGAS-Bewertung tatsächlich begrenzt ist, was in der Praxis bedeutet conflicting_docs Und no_answer_expected. Wenn Sie es überall sonst einsetzen, zahlen Sie für Präzision, die Sie bei Fragen nicht benötigen. RAGAS punktet bereits zuverlässig.

---

Mit einem Menschen auf dem Laufenden bleiben

Sowohl RAGAS als auch ein benutzerdefinierter Juror sind immer noch LLMs, die die Leistung eines anderen LLM bewerten, und sie werden nicht immer mit einem Menschen übereinstimmen. Die hier zu wissende ehrliche Zahl, die die meisten Groups nie messen, ist, wie oft Ihr Richter einer Individual tatsächlich zustimmt. In der Praxis ist eine LLM-Richter-zu-Mensch-Übereinstimmung im unteren bis mittleren Bereich von 80 % üblich, kein Zeichen dafür, dass etwas kaputt ist, aber eine tatsächliche Obergrenze ist eher wissenswert als anzunehmen.

def needs_human_review(ragas_score, judge_score, threshold=1.0):
    return abs(ragas_score - judge_score) > threshold

Dadurch bleibt die menschliche Bewertungswarteschlange klein und zielgerichtet, sodass nur die Fälle berücksichtigt werden, in denen zwei Bewertungsmethoden nicht übereinstimmen, nicht jede Antwort. Es lohnt sich auch, gelegentlich zwei Personen unabhängig voneinander die gleiche Handvoll grenzwertiger Antworten bewerten zu lassen. Wenn Domänenexperten bei einem bestimmten Fragetyp in quick einem Drittel der Fälle unterschiedlicher Meinung sind, handelt es sich nicht um ein Downside der Scoring-Pipeline. Die Grundwahrheit selbst ist nicht eindeutig, und keine Instruments können das beheben. Dies bedeutet normalerweise, dass der Golden-Set-Eintrag neu geschrieben werden muss, nicht der Richter.

---

Achten Sie nach dem Versand des Techniques auf Abweichungen

Eine Pipeline, die nur gegen einen festen Golden Set läuft, weist einen blinden Fleck auf, da sich der Dwell-Korpus darunter ändert. Neue Dokumente werden hinzugefügt, alte archiviert und echte Benutzeranfragen weichen von dem ab, was Sie ursprünglich getestet haben. Nichts davon taucht in einem Datensatz auf, der an dem Tag, an dem Sie ihn geschrieben haben, eingefroren wurde.

import random
from datetime import datetime, timedelta

def sample_production_queries(logs, n=50, days=7):
    latest = (q for q in logs if q("timestamp") > datetime.now() - timedelta(days=days))
    return random.pattern(latest, min(n, len(latest)))

Wenn Sie wöchentlich einen kleinen Teil des Dwell-Verkehrs abtasten und ihn mit der Kontextpräzision und -treue von RAGAS durchlaufen lassen – beide Metriken funktionieren ohne eine Floor-Fact-Antwort –, erhalten Sie ein zweites Sign. Ein plötzlicher Ausfall ohne entsprechende Codeänderung bedeutet normalerweise, dass sich etwas im Korpus und nicht in der Pipeline geändert hat, und es handelt sich um einen anderen Fehlermodus als alles, was eine Zusammenführungszeitprüfung jemals erkennen wird.

---

Führen Sie es als Pipeline aus

Zwei Dinge machen es zu einer echten Pipeline und nicht zu einer einmaligen Übung: Kostenbewusste Planungund a CI-Tor.

Das Ausführen des gesamten Stacks: RAGAS, der benutzerdefinierte Richter und die menschliche Überprüfung jedes einzelnen Commits ist so teuer, dass die meisten Groups innerhalb eines Monats stillschweigend damit aufhören. In der Praxis funktioniert die Abstufung besser:

• RAGAS auf dem kompletten goldenen Set: Jede Pull-Anfrage berührt den Abruf oder die Eingabeaufforderungen
• Benutzerdefinierte Beurteilung nur für gekennzeichnete Kategorien: jede Pull-Anfrage, beschränkt auf eine Handvoll Beispiele
• Menschliche Überprüfung: wöchentlich, nur in der Meinungsverschiedenheitswarteschlange
• Produktionsstichprobe: wöchentlich, auf einem rotierenden Teil des Dwell-Verkehrs

def check_regression(current_scores, baseline_scores, threshold=0.03):
    regressions = (
        (metric, baseline_scores(metric), rating)
        for metric, rating in current_scores.objects()
        if baseline_scores(metric) - rating > threshold
    )
    if regressions:
        elevate SystemExit(f"Blocking merge — regressions discovered: {regressions}")
    print("No regressions. Secure to merge.")

Verknüpfen Sie dies mit CI, sodass es bei jeder Pull-Anfrage ausgeführt wird, die Abruf, Chunking oder Eingabeaufforderungen berührt, und lassen Sie den Construct fehlschlagen, wenn eine Metrik Ihren Schwellenwert überschreitet. Dies ist der wichtigste Teil der gesamten Einrichtung und auch derjenige, der tatsächlich Vorfälle verhindert. Hier wird beispielsweise eine Chunking-Änderung abgefangen, die stillschweigend eine Klasse von Abfragen unterbricht, bevor sie drei Wochen später zu einem Assist-Ticket wird und nicht heute zu einer fehlgeschlagenen Prüfung.

---

Abschluss

Keiner der oben genannten sechs Schritte ist für sich genommen beeindruckend, wenn er unabhängig voneinander angewendet wird. Was jedoch den Unterschied macht, ist die gemeinsame Ausführung nach einem Zeitplan, als etwas, dem das Staff vertraut, und nicht als etwas, an das sich jemand hin und wieder erinnert. Das ist die Absicht dieses Artikels, von der Durchführung der Evaluierung als einmalige Bauchprüfung bis hin zur Integration in die RAG-Systeminfrastruktur, dem stillen Sitzen im CI und dem Erfassen der Änderung, die andernfalls erfolgt wäre.

Wenn Sie bei Null anfangen, versuchen Sie nicht, alle sechs Schritte auf einmal aufzubauen. Ein goldener Datensatz mit zwanzig guten Fragen und einem manuell überprüften RAGAS-Rating ist den meisten heute in Produktion befindlichen RAG-Systemen bereits voraus. Der Relaxation kann hinzugefügt werden, wenn das System wächst und Ihre Geduld für das manuelle Lesen von Antworten wächst.

Das gibt es derzeit in Unternehmen zu finden – es gibt ein vorgeschlagenes Produkt oder eine Funktion, die den Einsatz von KI beinhalten würde, wie etwa einen LLM-basierten Agenten, und es beginnen Diskussionen darüber, wie das Projekt geplant und aufgebaut werden soll. Produkt und Technik werden großartige Ideen haben, wie dieses Device nützlich sein könnte und wie viel Begeisterung es für das Unternehmen erzeugen kann. Wenn ich jedoch in diesem Raum bin, möchte ich nach dem Vorschlag des Projekts als Erstes wissen: „Wie werden wir das bewerten?“ Manchmal stellt sich dabei die Frage, ob die KI-Bewertung wirklich wichtig oder notwendig ist oder ob dies auf einen späteren Zeitpunkt (oder nie) warten kann.

Fakt ist: KI-Auswertungen braucht man nur, wenn man wissen will, ob es funktioniert. Wenn Sie mit der Erstellung und dem Versand zufrieden sind, ohne die Auswirkungen auf Ihr Unternehmen oder Ihre Kunden zu kennen, können Sie die Bewertung überspringen – die meisten Unternehmen wären damit jedoch eigentlich nicht einverstanden. Niemand möchte sich vorstellen, Dinge zu bauen, ohne sicher zu sein, ob sie funktionieren.

Lassen Sie uns additionally darüber sprechen, was Sie benötigen, bevor Sie mit der Entwicklung von KI beginnen, damit Sie diese bewerten können.

Das Ziel

Das magazine offensichtlich klingen, aber was soll Ihre KI tun? Was ist der Zweck davon und wie wird es aussehen, wenn es funktioniert?

Sie werden überrascht sein, wie viele Menschen sich an die Entwicklung von KI-Produkten wagen, ohne eine Antwort auf diese Frage zu haben. Aber es ist wirklich wichtig, dass wir innehalten und gründlich darüber nachdenken, denn um zu wissen, wie wir diesen Erfolg messen können, müssen wir wissen, was wir uns vorstellen, wenn wir uns den Erfolg eines Projekts vorstellen.

Es ist auch wichtig, dass Sie sich Zeit für diese Frage nehmen, bevor Sie beginnen, da Sie möglicherweise feststellen, dass Sie und Ihre Kollegen/Führungskräfte sich über die Antwort nicht wirklich einig sind. Allzu oft beschließen Unternehmen, KI auf irgendeine Weise in ihr Produkt einzubauen, ohne den Umfang des Projekts klar zu definieren, weil KI an sich als wertvoll angesehen wird. Mit fortschreitendem Projekt kommt dann der interne Konflikt darüber zum Vorschein, was Erfolg ist, wenn die Erwartungen einer Individual erfüllt werden und die einer anderen nicht. Dies kann ein echtes Durcheinander sein und wird sich erst lösen, wenn eine Menge Zeit, Energie und Mühe aufgewendet wurden. Die einzige Möglichkeit, dies zu beheben, besteht darin, sich im Voraus ausdrücklich darauf zu einigen, was Sie erreichen möchten.

KPIs

Es geht jedoch nicht nur darum, sich ein mentales Bild von einem Szenario auszudenken, in dem dieses KI-Produkt oder diese KI-Funktion funktioniert. Diese Imaginative and prescient muss in messbare Formen, beispielsweise KPIs, heruntergebrochen werden, damit wir später die für ihre Berechnung erforderlichen Bewertungstools erstellen können. Während qualitative oder Advert-hoc-Daten eine große Hilfe sein können, um Farbe zu gewinnen oder einen „Schnüffeltest“ durchzuführen, wird es nicht ausreichen, Menschen das KI-Device advert hoc, ohne einen systematischen Plan und Prozess, auszuprobieren, um genügend richtige Informationen zu liefern, um den Produkterfolg zu verallgemeinern.

Wenn wir uns bei der Beurteilung der Ergebnisse eines Projekts auf Stimmungen, „es scheint in Ordnung zu sein“ oder „niemand beschwert sich“ verlassen, ist das sowohl faul als auch ineffektiv. Das Sammeln der Daten, um ein statistisch aussagekräftiges Bild der Projektergebnisse zu erhalten, kann manchmal kostspielig und zeitaufwändig sein, aber die Various besteht darin, pseudowissenschaftliche Vermutungen darüber anzustellen, wie die Dinge funktionierten. Sie können nicht darauf vertrauen, dass die Stichproben oder das freiwillig abgegebene Suggestions wirklich repräsentativ für die umfassenden Erfahrungen sind, die die Menschen machen werden. Menschen machen sich normalerweise nicht die Mühe, uns über ihre guten oder schlechten Erfahrungen zu informieren, daher müssen Sie sie systematisch befragen. Darüber hinaus können Ihre Testfälle für ein LLM-basiertes Device nicht einfach spontan erstellt werden – Sie müssen bestimmen, welche Szenarios Sie interessieren, Checks definieren, die diese erfassen, und sie so oft ausführen, dass Sie sich über die Bandbreite der Ergebnisse sicher sein können. Das Definieren und Ausführen der Checks erfolgt später, aber Sie müssen jetzt Nutzungsszenarien identifizieren und mit der Planung beginnen.

Legen Sie die Torpfosten vor dem Spiel fest

Es ist auch wichtig, über Bewertung und Messung nachzudenken, bevor Sie beginnen, damit Sie und Ihre Groups nicht explizit oder implizit in Versuchung geraten, mit den Zahlen zu spielen. Das Ermitteln Ihrer KPIs nach der Erstellung oder Bereitstellung des Projekts kann natürlich dazu führen, dass Sie Metriken auswählen, die einfacher zu messen, leichter zu erreichen oder beides sind. In der sozialwissenschaftlichen Forschung gibt es ein Konzept, das zwischen dem, was gemessen werden kann, und dem, was tatsächlich zählt, unterscheidet und als „Messvalidität“ bezeichnet wird.

Wenn Sie beispielsweise für eine Forschungsstudie die Gesundheit von Menschen messen und feststellen möchten, ob Ihre Intervention ihre Gesundheit verbessert hat, müssen Sie definieren, was Sie in diesem Zusammenhang unter „Gesundheit“ verstehen, es aufschlüsseln und zahlreiche Messungen der verschiedenen Komponenten vornehmen, die Gesundheit umfasst. Wenn Sie, anstatt all diese Arbeit zu erledigen und Zeit und Geld aufzuwenden, nur Größe und Gewicht messen und den BMI berechnen würden, hätten Sie keine Messgültigkeit. Der BMI magazine, abhängig von Ihrer Sichtweise, einen Zusammenhang mit der Gesundheit haben, ist aber sicherlich kein umfassendes Maß für das Konzept. Gesundheit kann nicht allein anhand des BMI gemessen werden, auch wenn es kostengünstig und einfach ist, die Größe und das Gewicht von Menschen zu ermitteln.

Aus diesem Grund müssen Sie, nachdem Sie herausgefunden haben, was Ihre Erfolgsvision in der Praxis ist, diese formalisieren und Ihre Imaginative and prescient in messbare Ziele aufschlüsseln. Die von Ihnen definierten KPIs müssen später möglicherweise weiter aufgeschlüsselt oder detaillierter gestaltet werden, aber bis die Entwicklungsarbeit zur Erstellung Ihres KI-Instruments beginnt, wird es eine bestimmte Menge an Informationen geben, die Sie nicht kennen können. Bevor Sie beginnen, geben Sie Ihr Bestes, um die Ziele festzulegen, die Sie anstreben, und bleiben Sie dabei.

Denken Sie an das Risiko

Insbesondere beim Einsatz von LLM-basierter Technologie halte ich es für äußerst wichtig, vor dem Begin ein sehr ehrliches Gespräch in Ihrer Organisation über die Risikotoleranz zu führen. Ich empfehle, die Risikobesprechung an den Anfang des Prozesses zu stellen, denn genau wie bei der Definition von Erfolg kann dies zu Denkunterschieden zwischen den am Projekt beteiligten Personen führen und diese Unterschiede müssen gelöst werden, damit ein KI-Projekt fortgesetzt werden kann. Dies kann sogar Einfluss darauf haben, wie Sie Erfolg definieren, und es wirkt sich auch auf die Arten von Checks aus, die Sie später im Prozess erstellen.

LLMs sind nichtdeterministisch, was bedeutet, dass sie bei gleichen Eingaben in verschiedenen Situationen unterschiedlich reagieren können. Für ein Unternehmen bedeutet dies, dass Sie das Risiko in Kauf nehmen, dass die Artwork und Weise, wie ein LLM auf einen bestimmten Enter reagiert, von Zeit zu Zeit neuartig, unerwünscht oder einfach nur seltsam sein kann. Sie können nicht immer mit Sicherheit garantieren, dass sich ein KI-Agent oder LLM so verhält, wie Sie es erwarten. Selbst wenn es sich in 99 von 100 Fällen so verhält, wie Sie es erwarten, müssen Sie herausfinden, welchen Charakter dieser hundertste Fall haben wird, die Fehler- oder Fehlermodi verstehen und entscheiden, ob Sie das damit verbundene Risiko akzeptieren können – dazu gehört die KI-Bewertung.

Abschluss

Mir ist klar, dass sich das nach viel anfühlt. Ich gebe Ihnen eine ganze To-Do-Liste, bevor jemand eine Zeile Code geschrieben hat! Aufgrund des inhärenten nichtdeterministischen Charakters von LLMs, den ich beschrieben habe, ist die Bewertung für KI-Projekte jedoch wichtiger als für viele andere Arten von Softwareprojekten. Die Erstellung eines KI-Projekts, das Mehrwert schafft und das Unternehmen verbessert, erfordert eine genaue Prüfung, Planung und eine ehrliche Selbsteinschätzung darüber, was Sie erreichen möchten und wie Sie mit dem Unerwarteten umgehen. Wenn Sie mit der Erstellung von KI-Bewertungen fortfahren, werden Sie darüber nachdenken, welche Artwork von Problemen auftreten können (Halluzinationen, Missbrauch von Werkzeugen usw.) und wie Sie feststellen können, wann diese auftreten, damit Sie ihre Häufigkeit reduzieren und auf sie vorbereitet sein können, wenn sie auftreten.

---

Lesen Sie mehr über meine Arbeit unter www.stephaniekirmer.com

Einführung

Die KI-Entwicklung macht erhebliche Fortschritte, insbesondere mit dem Aufkommen von Giant Language Fashions (LLMs) und Retrieval-Augmented Era (RAG) Anwendungen. Da Entwickler bestrebt sind, robustere und zuverlässigere KI-Systeme zu entwickeln, sind Instruments, die die Bewertung und Überwachung erleichtern, unverzichtbar geworden. Ein solches Device ist Opik, eine Open-Supply-Plattform zur Optimierung der Bewertung, Prüfung und Überwachung von LLM-Anwendungen. In diesem Artikel werden LLM- und RAG-Anwendungen mit Opik bewertet und überwacht.

Überblick

1. Opik ist eine von Comet entwickelte Open-Supply-Plattform zur Bewertung und Überwachung von LLM-Anwendungen.
2. Es ermöglicht die Protokollierung und Nachverfolgung von LLM-Interaktionen und hilft Entwicklern, Probleme in Echtzeit zu identifizieren und zu beheben.
3. Die Bewertung von LLMs ist von entscheidender Bedeutung, um Genauigkeit und Relevanz sicherzustellen und Halluzinationen in den Modellergebnissen zu vermeiden.
4. Opik unterstützt die Integration mit Frameworks wie Pytest und erleichtert so die Ausführung wiederverwendbarer Evaluierungspipelines.
5. Die Plattform bietet sowohl Python SDK als auch eine Benutzeroberfläche und deckt damit ein breites Spektrum an Benutzerpräferenzen ab.
6. Opik kann mit Ragas zur Überwachung und Bewertung von RAG-Systemen verwendet werden, indem Metriken wie Antwortrelevanz und Kontextgenauigkeit berechnet werden.

Was ist Opik?

Opik ist ein Open-Supply-LLM Evaluierungs- und Überwachungsplattform von Comet. Es ermöglicht Ihnen, Ihre LLM-Traces in Entwicklung und Produktion zu protokollieren, zu überprüfen und auszuwerten. Sie können die Plattform und unser LLM auch als Richterbewerter nutzen, um Probleme mit Ihrer LLM-Bewerbung zu identifizieren und zu beheben.

Warum ist eine Bewertung wichtig?

Bewerten LLMs und RAG-Systeme gehen über die Prüfung der Genauigkeit hinaus. Dazu gehören Faktoren wie Antwortrelevanz, Richtigkeit, Kontextgenauigkeit und die Vermeidung von Halluzinationen. Instruments wie Opik und Ragas Ermöglichen Sie den Groups Folgendes:

• Verfolgen Sie die LLM-Leistung in Echtzeit und identifiziert Engpässe und Bereiche, in denen das System möglicherweise falsche oder irrelevante Ausgaben generiert.
• Bewerten Sie RAG-Pipelinesum sicherzustellen, dass das Abrufsystem genaue, relevante und vollständige Informationen für die anstehenden Aufgaben bereitstellt.

Hauptmerkmale von Opik

Hier sind die wichtigsten Funktionen von Opik:

1. Finish-to-Finish-LLM-Bewertung

• Opik verfolgt automatisch die gesamte LLM-Pipeline und liefert Einblicke in jede Komponente der Anwendung. Diese Fähigkeit ist entscheidend für das Debuggen und das Verständnis, wie verschiedene Teile des Techniques interagieren1.
• Es unterstützt komplexe Auswertungen sofort und ermöglicht es Entwicklern, Metriken zu implementieren, die die Modellleistung schnell bewerten.

2. Echtzeitüberwachung

• Die Plattform ermöglicht die Echtzeitüberwachung von LLM-Anwendungen, was dabei hilft, unbeabsichtigtes Verhalten und Leistungsprobleme zu erkennen, sobald sie auftreten.
• Entwickler können Interaktionen mit ihren LLM-Anwendungen protokollieren und diese Protokolle überprüfen, um das Verständnis und die Leistung kontinuierlich zu verbessern24.

3. Integration mit Check-Frameworks

• Opik lässt sich nahtlos in gängige Check-Frameworks wie Pytest integrieren und ermöglicht so „Modell-Unit-Checks“. Diese Funktion erleichtert die Erstellung wiederverwendbarer Evaluierungspipelines, die auf verschiedene Arten angewendet werden können Anwendungen.
• Entwickler können Bewertungsdatensätze innerhalb der Plattform speichern und Bewertungen mithilfe integrierter Metriken zur Halluzinationserkennung und anderen wichtigen Maßnahmen durchführen.

4. Benutzerfreundliche Oberfläche

• Die Plattform bietet sowohl a Python SDK für Entwickler, die Codierung bevorzugen, und eine Benutzeroberfläche für diejenigen, die grafische Interaktion bevorzugen. Dieser duale Ansatz macht es einem breiteren Benutzerkreis zugänglich.

Erste Schritte mit Opik

Opik ist für die nahtlose Integration in LLM-Systeme wie die GPT-Modelle von OpenAI konzipiert. Auf diese Weise können Sie Ablaufverfolgungen protokollieren, Ergebnisse auswerten und die Leistung in jedem Pipeline-Schritt überwachen. Hier erfahren Sie, wie Sie beginnen.

Protokollspuren für OpenAI LLM-Aufrufe – Setup-Umgebung

1. Erstellen Sie ein Opik-Konto: Gehen Sie rüber zu Komet und ein Konto erstellen. Zum Protokollieren von Traces benötigen Sie einen API-Schlüssel.
2. Protokollierungsspuren für OpenAI LLM-Aufrufe: Mit Opik können Sie Spuren protokollieren OpenAI Aufrufe, indem Sie sie mit der Funktion track_openai umschließen. Dadurch wird sichergestellt, dass jede Interaktion mit dem LLM protokolliert wird, was eine detaillierte Analyse ermöglicht.

Set up

Sie können Opik mit pip installieren:

!pip set up --upgrade --quiet opik openai

import opik

opik.configure(use_local=False)

import os

import getpass

if "OPENAI_API_KEY" not in os.environ:

    os.environ("OPENAI_API_KEY") = getpass.getpass("Enter your OpenAI API key: ")

Opik lässt sich in OpenAI integrieren, um eine einfache Möglichkeit zur Protokollierung von Ablaufverfolgungen für alle OpenAI-LLM-Aufrufe zu bieten.

Comet bietet eine gehostete Model der Opik-Plattform. Sie können ein Konto erstellen und Ihren API-Schlüssel erhalten.

Protokollierungsspuren für OpenAI LLM-Aufrufe – Protokollierungsspuren

from opik.integrations.openai import track_openai

from openai import OpenAI

os.environ("OPIK_PROJECT_NAME") = "openai-integration-demo"

consumer = OpenAI()

openai_client = track_openai(consumer)

immediate = """

Write a brief two sentence story about Opik.

"""

completion = openai_client.chat.completions.create(

    mannequin="gpt-3.5-turbo",

    messages=(

        {"position": "person", "content material": immediate}

    )

)

print(completion.selections(0).message.content material)

Um Spuren zu Opik zu protokollieren, müssen wir unsere OpenAI-Aufrufe mit der Funktion track_openai umschließen.

Dieses Beispiel zeigt, wie man einen von Opik umhüllten OpenAI-Consumer für die Hint-Protokollierung einrichtet und mit einer einfachen Eingabeaufforderung eine Chat-Abschlussanforderung erstellt.

Die Eingabeaufforderungs- und Antwortnachrichten werden automatisch in OPik protokolliert und können in der Benutzeroberfläche angezeigt werden.

Protokollierungsspuren für OpenAI LLM-Aufrufe – Protokollierung mehrstufiger Spuren

from opik import monitor

from opik.integrations.openai import track_openai

from openai import OpenAI

os.environ("OPIK_PROJECT_NAME") = "openai-integration-demo"

consumer = OpenAI()

openai_client = track_openai(consumer)

@monitor

def generate_story(immediate):

    res = openai_client.chat.completions.create(

        mannequin="gpt-3.5-turbo",

        messages=(

            {"position": "person", "content material": immediate}

        )

    )

    return res.selections(0).message.content material

@monitor

def generate_topic():

    immediate = "Generate a subject for a narrative about Opik."

    res = openai_client.chat.completions.create(

        mannequin="gpt-3.5-turbo",

        messages=(

            {"position": "person", "content material": immediate}

        )

    )

    return res.selections(0).message.content material

@monitor

def generate_opik_story():

    matter = generate_topic()

    story = generate_story(matter)

    return story

generate_opik_story()

Wenn Ihre LLM-Pipeline mehrere Schritte enthält, können Sie den Monitor Decorator verwenden, um die Ablaufverfolgungen für jeden Schritt zu protokollieren.

Wenn OpenAI innerhalb eines dieser Schritte aufgerufen wird, wird der LLM-Aufruf dem entsprechenden Schritt zugeordnet.

Dieses Beispiel zeigt, wie Sie mithilfe des @track-Dekorators Ablaufverfolgungen für mehrere Schritte in einem Prozess protokollieren und dabei den Fluss von der Themengenerierung zur Story-Generierung erfassen.

Opik mit Ragas zur Überwachung und Bewertung von RAG Techniques

!pip set up --quiet --upgrade opik ragas

import opik

opik.configure(use_local=False)

• Hier sind zwei Hauptmöglichkeiten, Opik mit Ragas zu verwenden:
  • Verwendung von Ragas-Metriken zur Bewertung von Spuren.
  • Verwenden der Ragas-Bewertungsfunktion zum Bewerten eines Datensatzes.
• Komet stellt eine gehostete Model der Opik-Plattform bereit. Du kannst ein Konto erstellen und holen Sie sich dort Ihren API-Schlüssel.

Beispiel zum Festlegen eines API-Schlüssels:

import os

import getpass

if "OPENAI_API_KEY" not in os.environ:

    os.environ("OPENAI_API_KEY") = getpass.getpass("Enter your OpenAI API key: ")

Erstellen einer einfachen RAG-Pipeline mit Ragas-Metriken

Ragas bietet eine Reihe von Metriken, die zur Bewertung der Qualität einer RAG-Pipeline verwendet werden können, einschließlich, aber nicht beschränkt auf: Antwortrelevanz, Antwortähnlichkeit, Antwortkorrektheit, Kontextgenauigkeit, Kontextrückruf, Kontextentitätsrückruf, Zusammenfassungsbewertung.

Eine vollständige Liste der Metriken finden Sie im Ragas-Dokumentation.

Diese Metriken können im Handumdrehen berechnet und in Opik in Traces oder Spans protokolliert werden. In diesem Beispiel erstellen wir zunächst eine einfache RAG-Pipeline und bewerten sie dann mithilfe der Metrik „answer_relevancy“.

# Import the metric

from ragas.metrics import AnswerRelevancy

# Import some extra dependencies

from langchain_openai.chat_models import ChatOpenAI

from langchain_openai.embeddings import OpenAIEmbeddings

from ragas.llms import LangchainLLMWrapper

from ragas.embeddings import LangchainEmbeddingsWrapper

# Initialize the Ragas metric

llm = LangchainLLMWrapper(ChatOpenAI())

emb = LangchainEmbeddingsWrapper(OpenAIEmbeddings())

answer_relevancy_metric = AnswerRelevancy(llm=llm, embeddings=emb)

Um die Ragas-Metrik ohne Verwendung der Evaluierungsfunktion zu verwenden, müssen Sie sie mit einem RunConfig-Objekt und einem LLM-Anbieter initialisieren. In diesem Beispiel verwenden wir LangChain als LLM-Anbieter mit aktiviertem Opik-Tracer.

Wir beginnen zunächst mit der Initialisierung der Ragas-Metrik.

# Run this cell first in case you are operating this in a Jupyter pocket book

import nest_asyncio

nest_asyncio.apply()

import asyncio

from ragas.integrations.opik import OpikTracer

from ragas.dataset_schema import SingleTurnSample

import os

os.environ("OPIK_PROJECT_NAME") = "ragas-integration"

# Outline the scoring operate

def compute_metric(metric, row):

    row = SingleTurnSample(**row)

    opik_tracer = OpikTracer(tags=("ragas"))

    async def get_score(opik_tracer, metric, row):

        rating = await metric.single_turn_ascore(row, callbacks=(opik_tracer))

        return rating

    # Run the async operate utilizing the present occasion loop

    loop = asyncio.get_event_loop()

    outcome = loop.run_until_complete(get_score(opik_tracer, metric, row))

    return outcome

• Sobald die Metrik initialisiert ist, können Sie sie zum Bewerten einer Beispielfrage verwenden.
• Dazu müssen wir zunächst eine Bewertungsfunktion definieren, die einen Datensatz mit Eingaben, Kontext usw. aufnehmen und ihn anhand der zuvor definierten Metrik bewerten kann.
• Da die Metrikbewertung asynchron erfolgt, müssen Sie die Asyncio-Bibliothek verwenden, um die Bewertungsfunktion auszuführen.

# Rating a easy instance

row = {

   "user_input": "What's the capital of France?",

   "response": "Paris",

   "retrieved_contexts": ("Paris is the capital of France.", "Paris is in France."),

}

rating = compute_metric(answer_relevancy_metric, row)

print("Reply Relevancy rating:", rating)

Wenn Sie nun zu Opik navigieren, können Sie sehen, dass im Default Venture-Projekt ein neuer Hint erstellt wurde.

Sie können die Funktion „update_current_trace“ verwenden, um Ablaufverfolgungen zu bewerten.

Diese Methode hat den Vorteil, dass die Bewertungsspanne zur Ablaufverfolgung hinzugefügt wird, was eine tiefergehende Untersuchung des RAG-Prozesses ermöglicht. Da die Ragas-Metrik jedoch synchron berechnet wird, ist sie möglicherweise nicht für den Einsatz in Produktionsszenarien geeignet.

from opik import monitor, opik_context

@monitor

def retrieve_contexts(query):

    # Outline the retrieval operate, on this case we'll onerous code the contexts

    return ("Paris is the capital of France.", "Paris is in France.")

@monitor

def answer_question(query, contexts):

    # Outline the reply operate, on this case we'll onerous code the reply

    return "Paris"

@monitor(identify="Compute Ragas metric rating", capture_input=False)

def compute_rag_score(answer_relevancy_metric, query, reply, contexts):

    # Outline the rating operate

    row = {"user_input": query, "response": reply, "retrieved_contexts": contexts}

    rating = compute_metric(answer_relevancy_metric, row)

    return rating

@monitor

def rag_pipeline(query):

    # Outline the pipeline

    contexts = retrieve_contexts(query)

    reply = answer_question(query, contexts)

    rating = compute_rag_score(answer_relevancy_metric, query, reply, contexts)

    opik_context.update_current_trace(

        feedback_scores=({"identify": "answer_relevancy", "worth": spherical(rating, 4)})

    )

    return reply

rag_pipeline("What's the capital of France?")

Datensätze auswerten

from datasets import load_dataset

from ragas.metrics import context_precision, answer_relevancy, faithfulness

from ragas import consider

from ragas.integrations.opik import OpikTracer

fiqa_eval = load_dataset("explodinggradients/fiqa", "ragas_eval")

# Reformat the dataset to match the schema anticipated by the Ragas consider operate

dataset = fiqa_eval("baseline").choose(vary(3))

dataset = dataset.map(

    lambda x: {

        "user_input": x("query"),

        "reference": x("ground_truths")(0),

        "retrieved_contexts": x("contexts"),

    }

)

opik_tracer_eval = OpikTracer(tags=("ragas_eval"), metadata={"evaluation_run": True})

outcome = consider(

    dataset,

    metrics=(context_precision, faithfulness, answer_relevancy),

    callbacks=(opik_tracer_eval),

)

print(outcome)

Wenn Sie einen Datensatz bewerten möchten, können Sie die Auswertungsfunktion von Raga verwenden. Wenn diese Funktion aufgerufen wird, berechnet die Ragas-Bibliothek die Metriken für jede Zeile im Datensatz und gibt eine Zusammenfassung der Ergebnisse zurück.

Verwenden Sie den OpikTracer-Callback, um die Bewertungsergebnisse auf der Opik-Plattform zu protokollieren:

Evaluierung von LLM-Anwendungen mit Opik

Durch die Bewertung Ihrer LLM-Anwendung können Sie Vertrauen in deren Leistung gewinnen. Dieser Evaluierungssatz wird häufig sowohl während der Entwicklung als auch im Rahmen des Testens einer Anwendung durchgeführt.

Die Auswertung erfolgt in fünf Schritten:

1. Fügen Sie Tracing zu Ihrer LLM-Anwendung hinzu.
2. Definieren Sie die Bewertungsaufgabe.
3. Wählen Sie den Datensatz aus, anhand dessen Sie Ihre Bewerbung bewerten möchten.
4. Wählen Sie die Kennzahlen aus, mit denen Sie Ihre Bewerbung bewerten möchten.
5. Erstellen Sie das Bewertungsexperiment und führen Sie es aus.

Fügen Sie Tracing zu Ihrer LLM-Anwendung hinzu.

from opik import monitor

from opik.integrations.openai import track_openai

import openai

openai_client = track_openai(openai.OpenAI())

# This technique is the LLM utility that you simply need to consider

# Usually, this isn't up to date when creating evaluations

@monitor

def your_llm_application(enter: str) -> str:

    response = openai_client.chat.completions.create(

        mannequin="gpt-3.5-turbo",

        messages=({"position": "person", "content material": enter}),

    )

    return response.selections(0).message.content material

@monitor

def your_context_retriever(enter: str) -> str:

    return ("...")

• Obwohl dies nicht erforderlich ist, wird das Hinzufügen von Monitoring zu Ihrer LLM-Bewerbung empfohlen. Dies ermöglicht einen vollständigen Einblick in jeden Evaluierungslauf.
• Das Beispiel zeigt die Verwendung einer Kombination aus dem Monitor Decorator und der Funktion track_openai zum Verfolgen der LLM-Anwendung.

Dadurch wird sichergestellt, dass Antworten aus den Modell- und Kontextabrufprozessen während der Auswertung verfolgt werden.

Definieren Sie die Bewertungsaufgabe

def evaluation_task(x: DatasetItem):

    return {

        "enter": x.enter('user_question'),

        "output": your_llm_application(x.enter('user_question')),

        "context": your_context_retriever(x.enter('user_question'))

    }

• Sie können die Evaluierungsaufgabe definieren, nachdem Sie Ihrer LLM-Anwendung Instrumentierung hinzugefügt haben.
• Die Auswertungsaufgabe verwendet ein Datensatzelement als Eingabe und gibt ein Wörterbuch zurück. Das Wörterbuch enthält Schlüssel, die den Parametern entsprechen, die von den von Ihnen verwendeten Metriken erwartet werden.
• In diesem Beispiel ruft die Funktion „evaluation_task“ die Eingabe aus dem Datensatz (x.enter(‚user_question‘)) ab, führt sie durch die LLM-Anwendung und ruft den Kontext mithilfe der Methode „your_context_retriever“ ab.

Mit dieser Methode werden die Auswertungsdaten für die weitere Analyse strukturiert.

Wählen Sie die Auswertungsdaten

Wenn Sie bereits einen Datensatz erstellt haben:

Sie können die Funktion Opik.get_dataset verwenden, um es abzurufen:

Codebeispiel:

from opik import Opik

consumer = Opik()

dataset = consumer.get_dataset(identify="your-dataset-name")

Wenn Sie noch keinen Datensatz haben:

Sie können eines mit der Funktion Opik.create_dataset erstellen:

Codebeispiel:

from opik import Opik

from opik.datasets import DatasetItem

consumer = Opik()

dataset = consumer.create_dataset(identify="your-dataset-name")

dataset.insert((

    DatasetItem(enter="Hiya, world!", expected_output="Hiya, world!"),

    DatasetItem(enter="What's the capital of France?", expected_output="Paris"),

))

• Um einen vorhandenen Datensatz abzurufen, verwenden Sie get_dataset mit dem Datensatznamen.
• Um einen neuen Datensatz zu erstellen, verwenden Sie create_dataset. Mit der Einfügefunktion können Sie Datenelemente in den Datensatz einfügen.

Wählen Sie die Bewertungsmetriken

Im selben Bewertungsexperiment können Sie mehrere Metriken verwenden, um Ihre Anwendung zu bewerten:

from opik.analysis.metrics import Equals, Hallucination

equals_metric= Equals()

hallucination_metric=Hallucination()

Opik bietet eine Reihe integrierter Bewertungsmetriken, aus denen Sie auswählen können. Diese sind in zwei Hauptkategorien unterteilt:

1. Heuristische Metriken: Diese Metriken sind deterministischer Natur, zum Beispiel gleich oder enthält
2. LLM als Richter: Diese Metriken verwenden ein LLM, um die Qualität der Ausgabe zu beurteilen. Typischerweise werden diese zur Erkennung von Halluzinationen oder Kontextrelevanz verwendet

Führen Sie die Auswertung durch

analysis= consider(experiment_name=”My experiment”,dataset=dataset,activity=evaluation_task,scoring_metrics=(hallucination_metric),experiment_config={”mannequin”: Mannequin})

Nachdem wir nun die Aufgabe, die wir auswerten möchten, den auszuwertenden Datensatz und die Metriken, mit denen wir auswerten möchten, haben, können wir die Auswertung durchführen.

Abschluss

Opik stellt einen bedeutenden Fortschritt bei den verfügbaren Instruments zur Bewertung und Überwachung von LLM-Anwendungen dar. Entwickler können sicher vertrauenswürdige KI-Systeme aufbauen, indem sie umfassende Funktionen zum Verfolgen, Bewerten und Debuggen von LLMs in einem benutzerfreundlichen Rahmen anbieten. Mit der Weiterentwicklung der KI-Technologie werden Instruments wie Opik von entscheidender Bedeutung sein, um sicherzustellen, dass diese Systeme in realen Anwendungen effektiv und zuverlässig funktionieren.

Wenn Sie außerdem on-line nach einem Generative-KI-Kurs suchen, dann schauen Sie sich Folgendes an: GenAI Pinnacle-Programm

Häufig gestellte Fragen

Erfolgsgeschichten

Erfolgsgeschichte 1: KI in Finanzdienstleistungen

Herausforderung: Es wurde festgestellt, dass KI-Modelle, die beim Kredit-Scoring eingesetzt werden, unbeabsichtigt bestimmte demografische Gruppen diskriminieren und so die in den Trainingsdaten vorhandenen historischen Verzerrungen fortbestehen lassen.

Lösung: Ein führendes Finanzdienstleistungsunternehmen implementierte ein Human-in-the-Loop-System, um die Entscheidungen seiner KI-Modelle neu zu bewerten. Durch die Einbeziehung einer vielfältigen Gruppe von Finanzanalysten und Ethikern in den Bewertungsprozess konnten sie Verzerrungen im Entscheidungsprozess des Modells identifizieren und korrigieren.

Ergebnis: Das überarbeitete KI-Modell wies eine deutliche Reduzierung verzerrter Ergebnisse auf, was zu gerechteren Kreditbewertungen führte. Die Initiative des Unternehmens erhielt Anerkennung für die Förderung ethischer KI-Praktiken im Finanzsektor und ebnete den Weg für inklusivere Kreditvergabepraktiken.

Erfolgsgeschichte 2: KI im Recruiting

Herausforderung: Einem Unternehmen fiel auf, dass sein KI-gesteuertes Rekrutierungstool für technische Positionen qualifizierte weibliche Bewerber häufiger ausfilterte als ihre männlichen Kollegen.

Lösung: Die Organisation richtete ein Human-in-the-Loop-Bewertungsgremium ein, dem HR-Fachleute, Experten für Vielfalt und Inklusion sowie externe Berater angehörten, um die Kriterien und den Entscheidungsprozess der KI zu überprüfen. Sie führten neue Trainingsdaten ein, definierten die Bewertungsmetriken des Modells neu und integrierten kontinuierliches Suggestions des Gremiums, um die Algorithmen der KI anzupassen.

Ergebnis: Das neu kalibrierte KI-Software zeigte eine deutliche Verbesserung des Geschlechterverhältnisses unter den in die engere Wahl gekommenen Kandidaten. Das Unternehmen berichtete von einer vielfältigeren Belegschaft und einer verbesserten Teamleistung, was den Wert menschlicher Aufsicht in KI-gesteuerten Rekrutierungsprozessen unterstreicht.

Erfolgsgeschichte 3: KI in der Gesundheitsdiagnostik

Herausforderung: Es stellte sich heraus, dass KI-Diagnosetools bei der Identifizierung bestimmter Krankheiten bei Patienten aus unterrepräsentierten ethnischen Gruppen weniger genau sind, was Zweifel an der Gerechtigkeit in der Gesundheitsversorgung aufkommen lässt.

Lösung: Ein Konsortium aus Gesundheitsdienstleistern arbeitete mit KI-Entwicklern zusammen, um ein breiteres Spektrum an Patientendaten zu erfassen und ein Feedbacksystem mit menschlicher Beteiligung zu implementieren. An der Evaluierung und Feinabstimmung der KI-Diagnosemodelle waren Mediziner mit unterschiedlichem Hintergrund beteiligt, die Einblicke in kulturelle und genetische Faktoren lieferten, die sich auf das Krankheitsbild auswirken.

Ergebnis: Die verbesserten KI-Modelle erzielten eine höhere Genauigkeit und Gerechtigkeit bei der Diagnose aller Patientengruppen. Diese Erfolgsgeschichte wurde auf medizinischen Konferenzen und in wissenschaftlichen Zeitschriften vorgestellt und inspirierte ähnliche Initiativen in der Gesundheitsbranche, um eine gerechte KI-gestützte Diagnostik sicherzustellen.

Erfolgsgeschichte 4: KI in der öffentlichen Sicherheit

Herausforderung: Gesichtserkennungstechnologien, die im Rahmen von Initiativen zur öffentlichen Sicherheit eingesetzt werden, wurden dafür kritisiert, dass es bei bestimmten ethnischen Gruppen häufiger zu Fehlidentifizierungen kommt, was zu Bedenken hinsichtlich Equity und Datenschutz führt.

Lösung: Ein Stadtrat arbeitete mit Technologieunternehmen und zivilgesellschaftlichen Organisationen zusammen, um den Einsatz von KI im Bereich der öffentlichen Sicherheit zu überprüfen und zu überarbeiten. Dazu gehörte die Einrichtung eines vielfältigen Aufsichtsausschusses, der die Technologie bewerten, Verbesserungen empfehlen und ihren Einsatz überwachen sollte.

Ergebnis: Durch iteratives Suggestions und Anpassungen verbesserte sich die Genauigkeit des Gesichtserkennungssystems in allen Bevölkerungsgruppen deutlich, was die öffentliche Sicherheit erhöhte und gleichzeitig die bürgerlichen Freiheiten wahrte. Der kollaborative Ansatz wurde als Modell für den verantwortungsvollen Einsatz von KI in staatlichen Diensten gelobt.

Diese Erfolgsgeschichten veranschaulichen die tiefgreifende Wirkung der Einbeziehung von menschlichem Suggestions und ethischen Überlegungen in die Entwicklung und Bewertung von KI. Indem sie Voreingenommenheit aktiv angehen und sicherstellen, dass unterschiedliche Perspektiven in den Bewertungsprozess einbezogen werden, können Unternehmen die Leistungsfähigkeit von KI gerechter und verantwortungsvoller nutzen.

Abschluss

Die Einbeziehung menschlicher Instinct in die Bewertung von KI-Modellen ist zwar von Vorteil, erfordert aber einen wachsamen Umgang mit Ethik und Voreingenommenheit. Durch die Umsetzung von Strategien für Vielfalt, Transparenz und kontinuierliches Lernen können wir Voreingenommenheit abbauen und auf ethischere, gerechtere und effektivere KI-Systeme hinarbeiten. Während wir voranschreiten, bleibt das Ziel klar: die Entwicklung einer KI, die der gesamten Menschheit gleichermaßen dient und auf einer starken ethischen Grundlage beruht.