Hallo! Haben Sie sich jemals gefragt, warum einige der heutigen Anwendungen geradezu magisch intelligent wirken? Ein großer Teil dieser Magie kommt von etwas namens RAG und LLM. Stellen Sie sich RAG (Retrieval-Augmented Generation) als den klugen Bücherwurm der KI-Welt vor. Es durchsucht unzählige Informationen, um genau das zu finden, was für Ihre Frage benötigt wird. Dann gibt es noch LLM (Large Language Model), wie die berühmte GPT-Serie, das aufgrund seiner beeindruckenden Textgenerierungsfunktionen eine reibungslose Antwort generiert. Mit diesen beiden zusammen haben Sie eine KI, die nicht nur intelligent, sondern auch äußerst relevant und kontextbewusst ist. Es ist, als würde man einen superschnellen Forschungsassistenten mit einem geistreichen Gesprächspartner kombinieren. Diese Kombination eignet sich hervorragend für alles, von der schnellen Suche nach bestimmten Informationen bis hin zu einem Chat, der sich überraschend real anfühlt. Aber hier ist der Haken: Woher wissen wir, ob unsere KI tatsächlich hilfreich ist und nicht nur ausgefallenen Jargon von sich gibt? Hier kommt die Bewertung ins Spiel. Sie ist von entscheidender Bedeutung und nicht nur ein „Nice-to-have“. Wir müssen sicherstellen, dass unsere KI nicht nur präzise, sondern auch relevant und nützlich ist und nicht in seltsame Richtungen gerät. Denn was nützt ein intelligenter Assistent, wenn er nicht versteht, was Sie brauchen, oder Ihnen Antworten gibt, die völlig daneben liegen? Die Evaluierung unserer RAG + LLM-Anwendung gleicht einem Realitätscheck. Es zeigt uns, ob wir wirklich auf dem richtigen Weg sind, eine KI zu entwickeln, die wirklich hilfreich und nicht nur technisch beeindruckend ist. In diesem Beitrag befassen wir uns daher damit, wie wir genau das erreichen – um sicherzustellen, dass unsere KI in der Praxis genauso großartig ist wie in der Theorie! Entwicklungsphase In der Entwicklungsphase ist es wichtig, im Sinne einer typischen Evaluierungspipeline für maschinelles Lernmodell zu denken. In einem Standard-KI/ML-Setup arbeiten wir normalerweise mit mehreren Datensätzen, wie z. B. Entwicklungs-, Trainings- und Testsätzen, und verwenden quantitative Metriken, um die Wirksamkeit des Modells zu messen. Die Bewertung großer Sprachmodelle (LLMs) stellt jedoch besondere Herausforderungen dar. Herkömmliche quantitative Metriken haben Schwierigkeiten, die Qualität der Ergebnisse von LLMs zu erfassen, da diese Modelle sich dadurch auszeichnen, dass sie eine Sprache erzeugen, die sowohl abwechslungsreich als auch kreativ ist. Daher ist es schwierig, über umfassende Etiketten für eine effektive Bewertung zu verfügen. In akademischen Kreisen könnten Forscher Benchmarks und Scores wie MMLU verwenden, um LLMs einzustufen, und menschliche Experten könnten hinzugezogen werden, um die Qualität der LLM-Ergebnisse zu bewerten. Diese Methoden lassen sich jedoch nicht nahtlos in die Produktionsumgebung überführen, wo das Entwicklungstempo schnell ist und praktische Anwendungen sofortige Ergebnisse erfordern. Es geht nicht nur um die LLM-Leistung; Die realen Anforderungen berücksichtigen den gesamten Prozess, der den Datenabruf, die zeitnahe Erstellung und den Beitrag des LLM umfasst. Es ist unpraktisch, für jede neue Systemiteration oder bei Änderungen an Dokumenten oder Domänen einen von Menschen kuratierten Benchmark zu erstellen. Darüber hinaus erlaubt das schnelle Entwicklungstempo in der Branche nicht den Luxus, lange darauf zu warten, dass menschliche Tester jedes Update vor der Bereitstellung bewerten. Daher stellt die Anpassung der in der Wissenschaft funktionierenden Bewertungsstrategien an die schnelle und ergebnisorientierte Produktionsumgebung eine erhebliche Herausforderung dar. Wenn Sie also in diesen Fall geraten, denken Sie vielleicht über so etwas wie einen Pseudo-Score nach, der von einem Master-LLM bereitgestellt wird. Dieser Wert könnte eine Kombination aus automatisierten Bewertungsmetriken und einer destillierten Essenz menschlichen Urteilsvermögens widerspiegeln. Ein solcher hybrider Ansatz zielt darauf ab, die Lücke zwischen dem differenzierten Verständnis menschlicher Bewerter und der skalierbaren, systematischen Analyse maschineller Bewertung zu schließen. Wenn Ihr Team beispielsweise ein internes LLM entwickelt, das auf Ihre spezifische Domäne und Daten geschult ist, erfordert der Prozess in der Regel eine gemeinsame Anstrengung von Entwicklern, Projektingenieuren und Datenwissenschaftlern. Jedes Mitglied spielt eine entscheidende Rolle: sind die Architekten. Sie konstruieren das Framework der Anwendung und stellen sicher, dass die RAG- und LLM-Kette nahtlos integriert ist und mühelos durch verschiedene Szenarien navigieren kann. Entwickler sind die Kreativen. Sie entwickeln Szenarien und Eingabeaufforderungen, die reale Benutzerinteraktionen nachahmen. Sie grübeln über das „Was wäre wenn“ und bringen das System dazu, sich mit einem breiten Spektrum an Themen und Fragen zu befassen. Prompt Engineers sind die Strategen. Sie analysieren die Antworten, vertiefen sich in die Daten und nutzen ihr statistisches Fachwissen, um zu beurteilen, ob die Leistung der KI den Anforderungen entspricht. Datenwissenschaftler Die Feedbackschleife ist hier unerlässlich. Während unsere KI auf Eingabeaufforderungen reagiert, prüft das Team jede Ausgabe. Hat die KI die Frage verstanden? War die Antwort korrekt und relevant? Könnte die Sprache flüssiger sein? Dieses Feedback wird dann zur Verbesserung in das System zurückgeleitet. Um dies noch weiter zu verbessern, stellen Sie sich vor, Sie würden ein Master-LLM wie GPT-4 von OpenAI als Benchmark für die Bewertung Ihres selbst entwickelten LLM verwenden. Ihr Ziel ist es, die Leistung der GPT-Serie zu erreichen oder sogar zu übertreffen, die für ihre Robustheit und Vielseitigkeit bekannt ist. So könnten Sie vorgehen: Erstellen Sie zunächst einen Datensatz, der die Nuancen Ihrer Domain widerspiegelt. Dieser Datensatz könnte von Experten kuratiert oder mithilfe von GPT-4 synthetisiert werden, um Zeit zu sparen und sicherzustellen, dass er Ihrem Goldstandard entspricht. Generieren eines relevanten Datensatzes: Nutzen Sie die Stärken des Master-LLM, um Sie bei der Definition Ihrer Metriken zu unterstützen. Sie haben die Freiheit, Metriken auszuwählen, die Ihren Zielen am besten entsprechen, vorausgesetzt, dass der Master-LLM die komplexeren Aufgaben bewältigen kann. Im Community-Standard möchten Sie vielleicht einige Arbeiten von und einigen anderen Bibliotheken wie sehen. Sie verfügen über einige Metriken wie Treue, Kontexterinnerung, Kontextgenauigkeit, Antwortähnlichkeit usw. Definieren von Erfolgsmetriken: Langchain Ragas Um mit schnellen Entwicklungszyklen Schritt zu halten, richten Sie eine automatisierte Pipeline ein. Dadurch wird die Leistung der Anwendung nach jedem Update oder jeder Änderung konsistent anhand Ihrer vordefinierten Metriken bewertet. Durch die Automatisierung des Prozesses stellen Sie sicher, dass Ihre Bewertung nicht nur gründlich, sondern auch effizient iterativ ist, was eine schnelle Optimierung und Verfeinerung ermöglicht. Automatisieren Sie Ihre Evaluierungspipeline: In der folgenden Demonstration zeige ich Ihnen beispielsweise, wie Sie mithilfe von GPT-4 von OpenAI automatisch verschiedene Open-Source-LLMs für eine einfache Konversationsaufgabe zum Abrufen von Dokumenten evaluieren. Zunächst verwenden wir OpenAI GPT-4, um einen synthetisierten Datensatz zu erstellen, der aus einem Dokument abgeleitet wird, wie unten gezeigt: import os import json import pandas as pd from dataclasses import dataclass from langchain.chat_models import ChatOpenAI from langchain.chains import LLMChain from langchain.prompts import PromptTemplate from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import CharacterTextSplitter from langchain.output_parsers import JsonOutputToolsParser, PydanticOutputParser from langchain.prompts import ChatPromptTemplate, HumanMessagePromptTemplate QA_DATASET_GENERATION_PROMPT = PromptTemplate.from_template( "You are an expert on generate question-and-answer dataset based on a given context. You are given a context. " "Your task is to generate a question and answer based on the context. The generated question should be able to" " to answer by leverage the given context. And the generated question-and-answer pair must be grammatically " "and semantically correct. Your response must be in a json format with 2 keys: question, answer. For example," "\n\n" "Context: France, in Western Europe, encompasses medieval cities, alpine villages and Mediterranean beaches. Paris, its capital, is famed for its fashion houses, classical art museums including the Louvre and monuments like the Eiffel Tower." "\n\n" "Response: {{" "\n" " \"question\": \"Where is France and what is it's capital?\"," "\n" " \"answer\": \"France is in Western Europe and it's capital is Paris.\"" "\n" "}}" "\n\n" "Context: The University of California, Berkeley is a public land-grant research university in Berkeley, California. Established in 1868 as the state's first land-grant university, it was the first campus of the University of California system and a founding member of the Association of American Universities." "\n\n" "Response: {{" "\n" " \"question\": \"When was the University of California, Berkeley established?\"," "\n" " \"answer\": \"The University of California, Berkeley was established in 1868.\"" "\n" "}}" "\n\n" "Now your task is to generate a question-and-answer dataset based on the following context:" "\n\n" "Context: {context}" "\n\n" "Response: ", ) OPENAI_API_KEY = os.getenv("OPENAI_API_KEY") if OPENAI_API_KEY is None: raise ValueError("OPENAI_API_KEY is not set") llm = ChatOpenAI( model="gpt-4-1106-preview", api_key=OPENAI_API_KEY, temperature=0.7, response_format={ "type": "json_object" }, ) chain = LLMChain( prompt=QA_DATASET_GENERATION_PROMPT, llm=llm ) file_loader = PyPDFLoader("./data/cidr_lakehouse.pdf") text_splitter = CharacterTextSplitter(chunk_size=1000) chunks = text_splitter.split_documents(file_loader.load()) questions, answers = [], [] for chunk in chunks: for _ in range(2): response = chain.invoke({ "context": chunk }) obj = json.loads(response["text"]) questions.append(obj["question"]) answers.append(obj["answer"]) df = pd.DataFrame({ "question": questions, "answer": answers }) df.to_csv("./data/cidr_lakehouse_qa.csv", index=False) Nachdem wir den oben genannten Code ausgeführt haben, erhalten wir als Ergebnis eine CSV-Datei. Diese Datei enthält Fragen- und Antwortpaare, die sich auf das von uns eingegebene Dokument beziehen, wie folgt: Anschließend erstellen wir mithilfe von Langchain einfache DocumentRetrievalQA-Ketten und ersetzen diese durch mehrere Open-Source-LLMs, die lokal über Ollama ausgeführt werden. Mein vorheriges Tutorial dazu finden Sie hier. from tqdm import tqdm from langchain.chains import RetrievalQA from langchain.chat_models import ChatOllama from langchain.vectorstores import FAISS from langchain.embeddings import HuggingFaceEmbeddings vector_store = FAISS.from_documents(chunks, HuggingFaceEmbeddings()) retriever = vector_store.as_retriever() def test_local_retrieval_qa(model: str): chain = RetrievalQA.from_llm( llm=ChatOllama(model=model), retriever=retriever, ) predictions = [] for it, row in tqdm(df.iterrows(), total=len(df)): resp = chain.invoke({ "query": row["question"] }) predictions.append(resp["result"]) df[f"{model}_result"] = predictions test_local_retrieval_qa("mistral") test_local_retrieval_qa("llama2") test_local_retrieval_qa("zephyr") test_local_retrieval_qa("orca-mini") test_local_retrieval_qa("phi") df.to_csv("./data/cidr_lakehouse_qa_retrieval_prediction.csv", index=False) Zusammenfassend stellt der obige Code eine einfache Dokumentenabrufkette her. Wir führen diese Kette mit mehreren Modellen aus, wie zum Beispiel Mistral, Llama2, Zephyr, Orca-mini und Phi. Daher fügen wir unserem vorhandenen DataFrame fünf zusätzliche Spalten hinzu, um die Vorhersageergebnisse jedes LLM-Modells zu speichern. Definieren wir nun eine Masterkette mit GPT-4 von OpenAI, um die Vorhersageergebnisse auszuwerten. In diesem Setup berechnen wir einen Korrektheitswert, der einem ungefähren F1-Wert ähnelt, wie er bei herkömmlichen KI/ML-Problemen üblich ist. Um dies zu erreichen, wenden wir parallele Konzepte wie True Positives (TP), False Positives (FP) und False Negatives (FN) an, die wie folgt definiert sind: TP: Aussagen, die sowohl in der Antwort als auch in der Grundwahrheit vorhanden sind. FP: Aussagen, die in der Antwort vorhanden sind, aber nicht in der Grundwahrheit gefunden werden. FN: Relevante Aussagen finden sich in der Grundwahrheit, wurden aber in der Antwort weggelassen. Mit diesen Definitionen können wir Präzision, Rückruf und den F1-Score mithilfe der folgenden Formeln berechnen: import os import numpy as np import pandas as pd from tqdm import tqdm from langchain.chains import LLMChain from langchain.chat_models import ChatOpenAI from langchain.prompts import PromptTemplate OPENAI_API_KEY = os.getenv("OPENAI_API_KEY") if OPENAI_API_KEY is None: raise ValueError("OPENAI_API_KEY is not set") CORRECTNESS_PROMPT = PromptTemplate.from_template( """ Extract following from given question and ground truth. Your response must be in a json format with 3 keys and does not need to be in any specific order: - statements that are present in both the answer and the ground truth - statements present in the answer but not found in the ground truth - relevant statements found in the ground truth but omitted in the answer Please be concise and do not include any unnecessary information. You should classify the statements as claims, facts, or opinions with semantic matching, no need exact word-by-word matching. Question:What powers the sun and what is its primary function? Answer: The sun is powered by nuclear fission, similar to nuclear reactors on Earth, and its primary function is to provide light to the solar system. Ground truth: The sun is actually powered by nuclear fusion, not fission. In its core, hydrogen atoms fuse to form helium, releasing a tremendous amount of energy. This energy is what lights up the sun and provides heat and light, essential for life on Earth. The sun's light also plays a critical role in Earth's climate system and helps to drive the weather and ocean currents. Extracted statements: [ {{ "statements that are present in both the answer and the ground truth": ["The sun's primary function is to provide light"], "statements present in the answer but not found in the ground truth": ["The sun is powered by nuclear fission", "similar to nuclear reactors on Earth"], "relevant statements found in the ground truth but omitted in the answer": ["The sun is powered by nuclear fusion, not fission", "In its core, hydrogen atoms fuse to form helium, releasing a tremendous amount of energy", "This energy provides heat and light, essential for life on Earth", "The sun's light plays a critical role in Earth's climate system", "The sun helps to drive the weather and ocean currents"] }} ] Question: What is the boiling point of water? Answer: The boiling point of water is 100 degrees Celsius at sea level. Ground truth: The boiling point of water is 100 degrees Celsius (212 degrees Fahrenheit) at sea level, but it can change with altitude. Extracted statements: [ {{ "statements that are present in both the answer and the ground truth": ["The boiling point of water is 100 degrees Celsius at sea level"], "statements present in the answer but not found in the ground truth": [], "relevant statements found in the ground truth but omitted in the answer": ["The boiling point can change with altitude", "The boiling point of water is 212 degrees Fahrenheit at sea level"] }} ] Question: {question} Answer: {answer} Ground truth: {ground_truth} Extracted statements:""", ) judy_llm = ChatOpenAI( model="gpt-4-1106-preview", api_key=OPENAI_API_KEY, temperature=0.0, response_format={ "type": "json_object" }, ) judy_chain = LLMChain( prompt=CORRECTNESS_PROMPT, llm=judy_llm ) def evaluate_correctness(column_name: str): chain = LLMChain( prompt=CORRECTNESS_PROMPT, llm=ChatOpenAI( model="gpt-4-1106-preview", api_key=OPENAI_API_KEY, temperature=0.0, response_format={ "type": "json_object" }, ) ) key_map = { "TP": "statements that are present in both the answer and the ground truth", "FP": "statements present in the answer but not found in the ground truth", "FN": "relevant statements found in the ground truth but omitted in the answer", # noqa: E501 } TP, FP, FN = [], [], [] for it, row in tqdm(df.iterrows(), total=len(df)): resp = chain.invoke({ "question": row["question"], "answer": row[column_name], "ground_truth": row["answer"] }) obj = json.loads(resp["text"]) TP.append(len(obj[key_map["TP"]])) FP.append(len(obj[key_map["FP"]])) FN.append(len(obj[key_map["FN"]])) # convert to numpy array TP = np.array(TP) FP = np.array(FP) FN = np.array(FN) df[f"{column_name}_recall"] = TP / (TP + FN) df[f"{column_name}_precision"] = TP / (TP + FP) df[f"{column_name}_correctness"] = 2 * df[f"{column_name}_recall"] * df[f"{column_name}_precision"] / (df[f"{column_name}_recall"] + df[f"{column_name}_precision"]) evaluate_correctness("mistral_result") evaluate_correctness("llama2_result") evaluate_correctness("zephyr_result") evaluate_correctness("orca-mini_result") evaluate_correctness("phi_result") print("|====Model====|=== Recall ===|== Precision ==|== Correctness ==|") print(f"|mistral | {df['mistral_result_recall'].mean():.4f} | {df['mistral_result_precision'].mean():.4f} | {df['mistral_result_correctness'].mean():.4f} |") print(f"|llama2 | {df['llama2_result_recall'].mean():.4f} | {df['llama2_result_precision'].mean():.4f} | {df['llama2_result_correctness'].mean():.4f} |") print(f"|zephyr | {df['zephyr_result_recall'].mean():.4f} | {df['zephyr_result_precision'].mean():.4f} | {df['zephyr_result_correctness'].mean():.4f} |") print(f"|orca-mini | {df['orca-mini_result_recall'].mean():.4f} | {df['orca-mini_result_precision'].mean():.4f} | {df['orca-mini_result_correctness'].mean():.4f} |") print(f"|phi | {df['phi_result_recall'].mean():.4f} | {df['phi_result_precision'].mean():.4f} | {df['phi_result_correctness'].mean():.4f} |") print("|==============================================================|") df.to_csv("./data/cidr_lakehouse_qa_retrieval_prediction_correctness.csv", index=False) Okay, jetzt haben wir einen einfachen Benchmark für mehrere Modelle. Dies kann als vorläufiger Indikator dafür angesehen werden, wie jedes Modell die Dokumentenabrufaufgabe bewältigt. Obwohl diese Zahlen eine Momentaufnahme darstellen, sind sie nur der Anfang der Geschichte. Sie dienen als Grundlage für das Verständnis, welche Modelle besser in der Lage sind, genaue und relevante Informationen aus einem bestimmten Korpus abzurufen. Den Quellcode finden Sie . hier Human-In-Loop-Feedback Wenn es darum geht, unsere KI durch Human-In-Loop-Feedback zu optimieren, ist die Synergie zwischen menschlichen Testern und dem Master-LLM von entscheidender Bedeutung. Bei dieser Beziehung geht es nicht nur darum, Feedback zu sammeln, sondern ein reaktionsfähiges KI-System zu schaffen, das sich an menschliche Eingaben anpasst und daraus lernt. Der interaktive Prozess Tester beschäftigen sich mit der RAG + LLM-Kette und bewerten deren Ergebnisse aus menschlicher Sicht. Sie geben Feedback zu Aspekten wie der Relevanz, Genauigkeit und Natürlichkeit der Antworten der KI. Der Input des Testers: Hier passiert die Magie. Das Feedback menschlicher Tester wird direkt an den Master-LLM übermittelt. Im Gegensatz zu Standardmodellen ist das Master-LLM darauf ausgelegt, dieses Feedback zu verstehen und zu interpretieren, um die nachfolgenden Ergebnisse zu verfeinern. Feedback zum Master LLM: Mit diesem Feedback passt der Master-LLM den Prompt für unser Entwicklungs-LLM an. Dieser Prozess ist vergleichbar mit dem Unterrichten eines Studenten durch einen Mentor. Das Master-LLM modifiziert sorgfältig die Art und Weise, wie das Entwicklungs-LLM Aufforderungen interpretiert und darauf reagiert, um einen effektiveren und kontextbewussteren Reaktionsmechanismus sicherzustellen. Prompt-Tuning durch den Master-LLM: Die Doppelrolle des Master-LLM Der Master LLM fungiert sowohl als Benchmark für das intern entwickelte LLM als auch als aktiver Teilnehmer in der Feedbackschleife. Es bewertet das Feedback, passt die Eingabeaufforderungen oder Modellparameter an und „lernt“ im Wesentlichen aus menschlichen Interaktionen. Der Vorteil der Echtzeitanpassung Dieser Prozess ist transformativ. Dadurch kann sich die KI in Echtzeit anpassen, wodurch sie agiler und an die Komplexität menschlicher Sprache und Denkprozesse angepasst wird. Eine solche Echtzeitanpassung stellt sicher, dass die Lernkurve der KI steil und kontinuierlich ist. Der Zyklus der Verbesserung Durch diesen Zyklus aus Interaktion, Feedback und Anpassung wird unsere KI zu mehr als nur einem Werkzeug; Es wird zu einer lernenden Einheit, die sich durch jede Interaktion mit einem menschlichen Tester verbessern kann. Dieses Human-in-the-Loop-Modell sorgt dafür, dass unsere KI nicht stagniert, sondern sich zu einem effizienteren und intuitiveren Assistenten entwickelt. Zusammenfassend geht es beim Human-In-Loop-Feedback nicht nur darum, menschliche Erkenntnisse zu sammeln – es geht darum, eine dynamische und anpassungsfähige KI zu schaffen, die ihr Verhalten optimieren kann, um den Benutzern einen besseren Service zu bieten. Dieser iterative Prozess stellt sicher, dass unsere RAG + LLM-Anwendungen auf dem neuesten Stand bleiben und nicht nur Antworten, sondern kontextbezogene, differenzierte Antworten liefern, die ein echtes Verständnis der Benutzerbedürfnisse widerspiegeln. Für eine einfache Demo können Sie in diesem sehen, wie ClearML dieses Konzept verwendet, um Promptimizer zu verbessern. Video Betriebsphase Der Übergang in die ist wie der Übergang von den Generalproben zum Eröffnungsabend. Hier sind unsere RAG + LLM-Anwendungen keine hypothetischen Einheiten mehr; Sie werden zu aktiven Teilnehmern an den täglichen Arbeitsabläufen echter Benutzer. Diese Phase ist der Lackmustest für alle Vorbereitungen und Feinabstimmungen, die in der Entwicklungsphase durchgeführt wurden. Operationsphase In dieser Phase stimmen sich unsere Teams – Betriebs-, Produkt- und Analystenteams – auf die Bereitstellung und Verwaltung der Anwendungen ab und stellen so sicher, dass alles, was wir erstellt haben, nicht nur funktioniert, sondern auch in einer Live-Umgebung funktioniert. Hier können wir über die Implementierung von A/B-Teststrategien nachdenken, um die Wirksamkeit unserer Anwendungen kontrolliert zu messen. Wir teilen unsere Benutzerbasis in zwei Segmente auf – das Kontrollsegment, das weiterhin die etablierte Version der Anwendung verwendet (Version 1), und das Testsegment, das die neuen Funktionen in Version 2 ausprobiert (eigentlich). Sie können auch mehrere A/B-Tests gleichzeitig durchführen. Dies ermöglicht es uns, Vergleichsdaten zur Benutzererfahrung, zur Aufnahmefähigkeit von Funktionen und zur Gesamtleistung zu sammeln. A/B-Testing-Framework: Das Betriebsteam ist für den reibungslosen Rollout beider Versionen verantwortlich und stellt sicher, dass die Infrastruktur robust ist und dass etwaige Versionsübergänge für den Benutzer reibungslos verlaufen. Operativer Rollout: Das Produktteam arbeitet am Puls der Zeit des Benutzerfeedbacks und arbeitet daran, das Produkt zu iterieren. Dieses Team stellt sicher, dass die neuen Funktionen den Benutzerbedürfnissen und der gesamten Produktvision entsprechen. Produktentwicklung: Das Analystenteam untersucht die im Rahmen des A/B-Tests gesammelten Daten gründlich. Ihre Erkenntnisse sind entscheidend dafür, ob die neue Version die alte übertrifft und ob sie für eine breitere Veröffentlichung bereit ist. Analytische Erkenntnisse: Key Performance Indicators (KPIs) werden überwacht, um den Erfolg jeder Version zu messen. Dazu gehören Kennzahlen zum Benutzerengagement, Zufriedenheitswerte und die Genauigkeit der Anwendungsausgaben. Leistungsmetriken: Die Betriebsphase ist dynamisch und basiert auf kontinuierlichen Feedbackschleifen, die nicht nur die Anwendungen verbessern, sondern auch das Engagement und die Zufriedenheit der Benutzer steigern. Es ist eine Phase, die durch Überwachung, Analyse, Iteration und vor allem Lernen aus Live-Daten gekennzeichnet ist. In dieser Phase ist es unser Ziel, die hohen Standards der Entwicklungsphase nicht nur aufrechtzuerhalten, sondern zu übertreffen, um sicherzustellen, dass unsere RAG + LLM-Anwendung weiterhin an der Spitze von Innovation und Benutzerfreundlichkeit steht. Abschluss Zusammenfassend stellt die Integration von Retrieval-Augmented Generation (RAG) und Large Language Models (LLMs) einen bedeutenden Fortschritt in der KI dar, der tiefgreifende Datenabfrage mit anspruchsvoller Textgenerierung verbindet. Wir benötigen jedoch eine geeignete und effektive Methode zur Bewertung und eine iterative Entwicklungsstrategie. In der Entwicklungsphase liegt der Schwerpunkt auf der individuellen Anpassung der KI-Bewertung und deren Verbesserung durch Human-in-the-Loop-Feedback, um sicherzustellen, dass diese Systeme einfühlsam und an reale Szenarien anpassbar sind. Dieser Ansatz unterstreicht die Entwicklung der KI von einem bloßen Werkzeug zu einem Kooperationspartner. In der Betriebsphase werden diese Anwendungen in realen Szenarien getestet. Dabei kommen Strategien wie A/B-Tests und kontinuierliche Feedbackschleifen zum Einsatz, um die Wirksamkeit und kontinuierliche Weiterentwicklung auf der Grundlage der Benutzerinteraktion sicherzustellen.
