RAG als Service vs. Eigenentwicklung: Kosten und Entscheidungshilfe
Ein Service und eine Eigenentwicklung berechnen nicht dieselben Leistungen, und die auf dem Papier günstigere Option ist oft diejenige, die ab dem zweiten Jahr mehr kostet. Ein Komponentenvergleich und die Situationen, in denen die jeweilige Option überzeugt.
Retrieval-Augmented Generation, meist als RAG abgekürzt, ist das Muster hinter den meisten geschäftlichen KI-Anwendungen, die Antworten aus Ihren eigenen Dokumenten liefern: Das System durchsucht zunächst Ihre Wissensdatenbank, anschließend formuliert das Sprachmodell eine Antwort auf Grundlage der gefundenen Informationen. Supportmitarbeiter die das Handbuch zitieren, Vertriebstools, die auf die Produktdokumentation zugreifen, interne Assistenten, die Fragen anhand von Richtlinien und Tickets beantworten: Hinter all diesen Anwendungen steckt meist RAG.
Wenn Sie erwägen, RAG in Ihrem Unternehmen einzusetzen, stehen Sie vor derselben Frage wie bei jeder Entscheidung zwischen Eigenentwicklung und Zukauf: Bezahlen Sie einen Service für den Betrieb oder entwickeln Sie ihn mit Ihrem eigenen Team? Der Einstiegspreis ist ein naheliegender Ausgangspunkt. Um die beiden Optionen fair zu vergleichen, sollten Sie betrachten, wofür Sie im Laufe der Zeit bezahlen und wer Probleme behebt, wenn etwas ausfällt. Ein Anbieter berechnet möglicherweise die Nutzung, während eine Eigenentwicklung Infrastruktur und Arbeitszeit des Teams erfordert. Auch die Risiken unterscheiden sich. Sie sind darauf angewiesen, dass der Anbieter seine Ausfälle behebt, während Ihr Team bei einer Eigenentwicklung Probleme selbst untersucht. Diese Unterschiede können dazu führen, dass die bei der Einführung günstigere Option im zweiten Jahr teurer ist. Wir schlüsseln die Kosten von Zukauf und Eigenentwicklung auf und erläutern, wann welcher Ansatz sinnvoll ist.
Was „RAG als Service“ tatsächlich bedeutet
RAG als Service bedeutet, dass ein Anbieter die Retrieval-Pipeline für Sie betreibt. Sie verbinden Ihre Dokumente, der Service indexiert sie, und Sie senden Fragen an seine API oder nutzen seine Oberfläche. Der Anbieter ist für Embeddings, Vektorspeicher, Retrieval-Logik, Modellaufrufe, Aktualisierungen und Verfügbarkeit verantwortlich. Ihr Team ist für die Dokumente, Zugriffsregeln und Antworten des Systems verantwortlich.
Der Leistungsumfang variiert je nach Anbieter. Einige Services sind eine gehostete Version einer Standard-Pipeline: Dokumente hochladen, Fragen stellen, fundierte Antworten erhalten. Andere sind eher Plattformen: mit Konnektoren zu Ihren bestehenden Systemen, berechtigungsabhängigem Retrieval, Evaluierungs-Dashboards und Warteschlangen für die menschliche Prüfung. Der Unterschied ist für die Kosten relevant, denn eine einfache gehostete Pipeline und eine gesteuerte Unternehmensplattform werden wie unterschiedliche Produkte bepreist, selbst wenn beide sich als RAG als Service bezeichnen. Fragen Sie vor dem Preisvergleich, was enthalten ist: Indexierung, Konnektoren, Berechtigungsverwaltung, Evaluierung, Support und Datenresidenz werden häufig separat berechnet und sind nicht Teil der Grundgebühr.
Was „Eigenentwicklung“ tatsächlich bedeutet
Bei einer Eigenentwicklung ist Ihr Team für die Pipeline verantwortlich. Jemand wählt das Embedding-Modell aus, richtet den Vektorspeicher ein, schreibt die Retrieval-Logik, bindet das Sprachmodell an, entwickelt die Oberfläche und hält all das am Laufen. Die Arbeit ist kein einzelnes Projekt, sondern ein System mit Komponenten, die unterschiedlich schnell veralten. Embeddings werden besser, der Vektorspeicher wächst, Dokumente ändern sich, und die Evaluierung endet praktisch nie.
Eine Eigenentwicklung bedeutet nicht zwangsläufig, dass Sie jeden Bestandteil von Grund auf entwickeln. Die meisten Teams kombinieren vorhandene Komponenten: eine Embedding-API, eine verwaltete oder selbst gehostete Vektordatenbank, eine Sprachmodell-API und benutzerdefinierten Code für Retrieval und Oberfläche. Die Entscheidung zwischen Eigenentwicklung und Zukauf innerhalb eines Eigenentwicklungsprojekts ist eine eigene Frage. Was bei einer Eigenentwicklung definitionsgemäß intern bleibt, ist die Verantwortung: für die Architektur, die Wartung und die Rechenschaft, wenn Antworten falsch sind.
Kosten der RAG-Implementierungsoptionen
Keine der beiden Optionen hat einen einzigen Preis. Beide Rechnungen bestehen aus mehreren Komponenten, und diese Komponenten unterscheiden sich. Vergleichen Sie sie Zeile für Zeile, nicht Gesamtkosten mit Gesamtkosten.
Ein RAG-Service berechnet typischerweise die Nutzung, die Anzahl der Benutzer oder Dokumente sowie die Einführung. Die wiederkehrende Rechnung umfasst normalerweise die gehostete Pipeline, die in Ihrem Auftrag ausgeführten Modellaufrufe, den Speicher für den Index und den Support. Zusätzlich sollten Sie mit einmaligen Einführungskosten rechnen: für die Anbindung Ihrer Quellen, die Bereinigung von Dokumentberechtigungen und die Optimierung des Retrievals für Ihre Inhalte. Die Kostentreiber sind das Fragenvolumen, Größe und Änderungsrate des Dokumentbestands, die Anzahl der angebundenen Systeme sowie die von Ihnen gestellten Sicherheits- und Compliance-Anforderungen. Die Kosten hängen von allen vier Faktoren ab, daher sagt ein Angebot für den Dokumentbestand eines Unternehmens wenig über Ihre Situation aus.
Eine Eigenentwicklung hat eine andere Kostenstruktur. Die ersten Kosten entstehen durch die Entwicklungszeit: Die Entwicklung selbst wird bei einem klar abgegrenzten Pilotprojekt in der Regel in Wochen, nicht in Monaten gemessen, sofern die Dokumente zugänglich und der Anwendungsfall eng gefasst ist. Die zweiten Kosten betreffen die Infrastruktur: Hosting für den Vektorspeicher und die Anwendung, Embedding- und Modellaufrufe pro Frage sowie Speicher, der mit dem Dokumentbestand wächst. Die dritten Kosten werden von Teams unterschätzt: die Wartung. Jemand muss geänderte Dokumente neu indexieren, die Retrieval-Qualität überwachen, Modellaktualisierungen verarbeiten, Sicherheitsprobleme beheben und Verantwortung für falsche Antworten übernehmen. Die vierten Kosten betreffen die Zuständigkeit: eine namentlich benannte Person oder ein Team, die bzw. das das System regelmäßig überprüft. Ohne diese Zuständigkeit driftet ein internes RAG-System genauso wie jedes andere System ohne Verantwortliche, und die Abweichungen werden von den Benutzern entdeckt, nicht von den Dashboards.
Betrachten Sie die Gesamtkosten als ein Modell, das Sie verfeinern, nicht als eine Zahl, die Sie einmal berechnen. Ein Pilotprojekt liefert Ihnen reale Werte für Ihre Dokumente und Ihr Volumen: Kosten pro Frage, Indexierungskosten pro Dokumentbatch und Wartungsstunden pro Woche. Verwenden Sie diese Werte, um die Optionen für die nächste Phase zu vergleichen, statt die Marketingseite mit der Schätzung zu vergleichen.
RAG-Service vs. Eigenentwicklung
| RAG als Service | Eigenentwicklung | |
|---|---|---|
| Zeit bis zu den ersten funktionierenden Antworten | Tage bis Wochen nach der Einführung | Wochen bei einem klar abgegrenzten Pilotprojekt |
| Vorabkosten | Einführung und Einrichtung | Entwicklungszeit für die Entwicklung |
| Wiederkehrende Kosten | Abonnement- oder nutzungsabhängige Gebühren | Infrastruktur, Modellaufrufe, Wartung |
| Wer die Pipeline wartet | Der Anbieter | Ihr Team |
| Kontrolle über das Retrieval | Auf die Optionen des Anbieters beschränkt | Vollständig, bis hin zur Ranking-Logik |
| Datenverarbeitung | Der Anbieter hostet Ihren Index; prüfen Sie Datenresidenz und Aufbewahrungsfristen | Sie entscheiden, wo die Daten gespeichert werden |
| Wechselkosten | Exportbeschränkungen, erneute Indexierung an anderer Stelle | Integrationen neu erstellen; das Wissen bleibt bei Ihnen |
| Am besten geeignet für | Standarddokumente, kleines Team, Bedarf an hohem Tempo | Sensible Daten, individuelle Suche, umfassende Integration |
RAG-Entscheidung
Sie sind unsicher, ob Sie RAG kaufen oder selbst entwickeln sollten?
Ein begrenzter Pilotversuch mit Ihren echten Dokumenten liefert Ihnen die Zahlen, die Klarheit schaffen: Kosten pro Frage, Antwortqualität und die Wartungsstunden, die Ihr Team tatsächlich aufwendet.

Betrachten Sie die Tabelle als Ausgangspunkt, nicht als endgültige Entscheidung. Die Zeile, die die Antwort bestimmt, ist nur selten die Preiszeile. Meist geht es um Kontrolle, Datenverarbeitung oder darum, wer das System im zweiten Jahr wartet.
Wann RAG as a Service sinnvoll ist
Ein Service passt gut, wenn Tempo und Fokus wichtiger sind als Kontrolle. Wenn Ihre Dokumente in gängigen Office-Formaten vorliegen, Ihr Team klein ist und Sie innerhalb weniger Wochen funktionierende Antworten benötigen, nimmt Ihnen ein Service die gesamte Entwicklungs- und Wartungslast ab. Der Anbieter hat die unspektakulären Teile bereits gelöst: Indexierung, Aufteilung in Textabschnitte, Optimierung der Suche und Verfügbarkeit. Ihr Team konzentriert sich auf die Dokumente und Antworten, nicht auf die Pipeline.
Ein Service passt gut für einen Pilotversuch. Wenn Sie noch nicht wissen, ob RAG Ihrem Unternehmen hilft, ist ein Service eine günstigere Möglichkeit, dies herauszufinden, als die Entwicklung selbst zu finanzieren. Stellen Sie echte Fragen zu echten Dokumenten, messen Sie die Antworten und entscheiden Sie auf Grundlage von Fakten. Wenn der Pilotversuch den Nutzen bestätigt und der Service passt, bleiben Sie dabei. Wenn er den Nutzen bestätigt, der Service aber nicht passt, wissen Sie, was Sie stattdessen entwickeln sollten, anstatt zu raten.
Ein Service passt auch gut, wenn Ihre Nutzung ungleichmäßig ist. Ein Support-Assistent, der täglich Hunderte Fragen beantwortet, benötigt eine andere Einrichtung als ein internes Tool, das von zwanzig Personen genutzt wird. Bei einem Service zahlen Sie für die tatsächliche Nutzung und können skalieren, ohne Personal für die Pipeline einzustellen. Bei einer Eigenentwicklung bleiben die Wartungskosten ungefähr gleich, unabhängig davon, ob das System zehn oder zehntausend Fragen beantwortet.
Wann Sie RAG intern entwickeln sollten
Eine interne Entwicklung funktioniert gut, wenn die Suche selbst das Produkt ist. Wenn Ihre Dokumente eine individuelle Aufteilung in Textabschnitte benötigen, Ihr Ranking Geschäftsregeln berücksichtigen muss oder Ihre Antworten davon abhängen, mehrere Systeme mit jeweils eigenen Berechtigungen zu verbinden, wird die Standardpipeline eines Services Ihnen im Weg stehen. Eine Eigenentwicklung ermöglicht es Ihnen, die Suche an den Inhalt anzupassen, statt den Inhalt an den Anbieter anzupassen.
Sie funktioniert gut, wenn die Datenverarbeitung nicht verhandelbar ist. Manche Dokumente dürfen Ihre Infrastruktur nicht verlassen, manche Branchen verlangen Prüfpfade die der Anbieter nicht anbietet, und manche Verträge legen fest, wo Daten gespeichert werden dürfen. Wenn der Anbieter diese Bedingungen nicht erfüllen kann, ist der Preisvergleich irrelevant. Prüfen Sie Datenresidenz, Aufbewahrungsfristen und ob Ihre Dokumente zum Training gemeinsam genutzter Modelle verwendet werden, bevor Sie irgendetwas anderes vergleichen.
Sie funktioniert gut, wenn die Nutzung hoch und konstant ist. Bei hohem Volumen summieren sich Gebühren pro Frage oder pro Nutzer, während die Infrastrukturkosten einer Eigenentwicklung langsamer steigen. Der Wendepunkt hängt von Ihrem Volumen, Ihren Dokumenten und der Preisgestaltung des Anbieters ab. Deshalb ist ein Pilotversuch mit echten Zahlen wichtig: Führen Sie dieselbe Arbeitslast auf beide Arten aus und vergleichen Sie die monatliche Rechnung, nicht die Broschüre.
Sie funktioniert gut, wenn Sie bereits über das Team verfügen. Wenn Ihre Entwickler bereits einen Vektorspeicher, ein Suchsystem oder eine Datenplattform betreiben, sind die zusätzlichen Kosten für den eigenen Betrieb von RAG geringer als bei einem Team, das bei null beginnt. Die Entwicklung erweitert Systeme, die sie bereits warten, und das Wissen bleibt intern.

Kosten, die bei beiden Optionen anfallen
Einige Kosten hängen nicht von der gewählten Option ab, und gerade sie überraschen Käufer am meisten.
Die Datenaufbereitung steht an erster Stelle. RAG ist nur so gut wie die Dokumente, die durchsucht werden. Veraltete Seiten, doppelte Versionen, widersprüchliche Richtlinien und Dokumente ohne klaren Verantwortlichen führen allesamt zu falschen Antworten. Ihre Bereinigung kostet Zeit, unabhängig davon, ob die Pipeline Ihnen oder einem Anbieter gehört. Planen Sie sie als Teil des Projekts ein, nicht als optionales Extra.
Die Evaluierung steht an zweiter Stelle. Sie benötigen eine Reihe von Testfragen mit bekannten korrekten Antworten sowie einen Ablauf, der diese nach jeder Änderung an Dokumenten oder Modellen ausführt. Ohne Evaluierung verschlechtert sich die Qualität unbemerkt. Beide Optionen benötigen sie, und das dafür verantwortliche Team ist in jedem Fall Ihres.
Sicherheit und Berechtigungen stehen an dritter Stelle. RAG muss berücksichtigen, wer was sehen darf. Ein Dokument, das von allen durchsucht werden kann, ist ein Datenleck, das nur auf eine Frage wartet. Berechtigungsbewusste Suche ist eine Anforderung, kein Feature, und sie muss mit echten Benutzerkonten getestet werden, nicht anhand einer Einstellungsseite vorausgesetzt werden.
Drift steht an vierter Stelle. Dokumente ändern sich, Produkte ändern sich, und auch das Modell hinter den Antworten ändert sich. Ein RAG-System, das monatelang niemand überprüft, befindet sich nicht im Produktivbetrieb, sondern läuft unbeaufsichtigt. Legen Sie vor dem Start eine verantwortliche Person fest und halten Sie den Prüfturnus ein, bis die Fehlerquote stabil ist.
So treffen Sie die Entscheidung
Gehen Sie diese fünf Fragen durch mit Ihren tatsächlichen Dokumenten und Ihrem Volumen, nicht mit einer allgemeinen Checkliste.
1. Wo dürfen die Dokumente gespeichert werden? Wenn die Antwort Anbieter einschränkt, ist die Entscheidung bereits gefallen. Prüfen Sie zuerst Speicherort, Aufbewahrung und Nutzung zu Trainingszwecken.
2. Wie individuell ist der Abruf? Standarddokumente mit Standardfragen eignen sich für einen Service. Individuelle Chunk-Aufteilung, Geschäftsregeln im Ranking oder Verknüpfungen mehrerer Systeme sprechen für eine Eigenentwicklung.
3. Was kostet der Pilot bei den jeweiligen Optionen? Ein Service-Pilot umfasst die Einrichtung sowie einen Monat Nutzung. Ein Pilot zur Eigenentwicklung umfasst einige Wochen Entwicklungsarbeit. Vergleichen Sie diese beiden Zahlen, nicht die jährlichen Prognosen.
4. Wer ist im zweiten Jahr dafür verantwortlich? Für einen Service benötigen Sie auf Ihrer Seite eine verantwortliche Person für Dokumente, Berechtigungen und Evaluierung. Bei einer Eigenentwicklung braucht es zusätzlich zu all dem eine verantwortliche Person für die Pipeline. Wenn niemand dafür verantwortlich ist, funktioniert keine der beiden Optionen.
5. Was kostet ein Wechsel? Fragen Sie den Anbieter, wie Sie Ihren Index und Ihre Evaluierungshistorie exportieren können. Fragen Sie Ihr Team, wie schwierig es ist, eine individuelle Integration zu ersetzen. Die günstigere Option beim Einstieg ist nicht immer auch die günstigere beim Ausstieg.
Wenn die Antworten in unterschiedliche Richtungen weisen, starten Sie zuerst einen Pilot mit dem Service. Ein Monat echter Nutzung liefert die Zahlen, die den Streit beenden: Kosten pro Frage, Antwortqualität und die Wartungsstunden, die Ihr Team tatsächlich aufwendet.

Die Fallstricke
Entscheidung nach dem Listenpreis. Die Abonnementgebühr und die Schätzung für eine Eigenentwicklung sind nicht dieselbe Art von Zahl. Bei der einen fehlen Datenaufbereitung, Evaluierung und Verantwortung; bei der anderen fehlen Anbieter-Support und Verfügbarkeit. Vergleichen Sie die Gesamtkosten über ein Jahr tatsächlicher Nutzung, einschließlich der Arbeit, die Ihr Team in beiden Fällen erledigt.
Datenaufbereitung überspringen. Der Kauf eines Services bereinigt Ihre Dokumente nicht, und der Aufbau einer Pipeline behebt keine widersprüchlichen Richtlinien. Das Team, das diesen Schritt überspringt, bezahlt dafür in beiden Fällen mit falschen Antworten.
Kein Evaluierungsdatensatz. Ohne Testfragen und bekannte korrekte Antworten können Sie nicht feststellen, ob eine Änderung geholfen oder geschadet hat. Beide Optionen erfordern eine Evaluierung, und ein Service, der Ihnen seine Evaluierung nicht zeigen kann, verlangt von Ihnen, einer Demo zu vertrauen.
Abhängigkeit auf beiden Seiten. Ein Service kann Sie durch Exportbeschränkungen und Kosten für die Neuindizierung binden. Eine Eigenentwicklung kann Sie durch individuelle Integrationen binden, die sonst niemand versteht. Stellen Sie die Frage nach dem Ausstieg, bevor Sie unterschreiben oder entwickeln, nicht erst danach.
RAG wie ein Suchfeld behandeln. RAG ist kein Suchfeld mit einem Sprachmodell darüber. Es ist ein System, das Informationen abruft, Antworten anhand von Quellen fundiert und Antworten formuliert. Seine Qualität hängt gemeinsam von den Dokumenten, dem Abruf und der Prüfschleife ab. Eine Demo, die fünf vorbereitete Fragen beantwortet, beweist wenig. Echte Fragen, echte Dokumente und eine gemessene Fehlerquote liefern den Rest des Nachweises.
RAG-Architektur besprechen
Sie wägen einen verwalteten RAG-Service gegen eine Eigenentwicklung ab?
Bei Ridiculous Engineering bieten wir verwaltetes RAG an und unterstützen Teams beim Aufbau von Systemen, die sie selbst betreiben können. Lassen Sie uns die Dokumente, den Abruf und einen messbaren Pilot besprechen.
RAG-Architektur besprechenKI-Entwicklung und Automatisierung
Häufig gestellte Fragen
Was ist RAG als Service?
RAG als Service ist eine gehostete Pipeline für die retrieval-gestützte Generierung: Ein Anbieter indexiert Ihre Dokumente und beantwortet über eine API oder eine Benutzeroberfläche Fragen daraus. Sie besitzen die Dokumente, die Zugriffsregeln und die Antworten. Der Anbieter verantwortet die Embeddings, den Vektorspeicher, die Abruflogik, die Modellaufrufe und die Verfügbarkeit.
Wie unterscheidet sich RAG von Fine-Tuning?
Beim Fine-Tuning wird ein Modell mit Ihren Daten trainiert, damit es sich anders verhält. Bei RAG bleibt das Modell unverändert und erhält Ihre Dokumente zum Zeitpunkt der Antwort. Dadurch basiert die Antwort auf Quellen, die Sie prüfen und aktualisieren können. RAG eignet sich für Wissen, das sich häufig ändert; Fine-Tuning für Verhalten und Tonalität, die stabil bleiben. Viele Systeme nutzen beides für unterschiedliche Teile der Aufgabe.
Sind unsere Daten bei einem RAG-Service sicher?
Das hängt von der Konfiguration ab, und Sie sollten dies vor einer Zusage klären. Finden Sie heraus, wo Ihre Dokumente gespeichert werden, ob Ihre Daten zum Trainieren gemeinsam genutzter Modelle verwendet werden, wie lange der Anbieter sie aufbewahrt und ob der Abruf Ihr Berechtigungsmodell berücksichtigt. Eine vertrauenswürdige Konfiguration bietet strenge Berechtigungen, klare Aufbewahrungsbedingungen und eine eindeutige Antwort auf jede dieser Fragen.
Wie lange dauert die jeweilige Option?
Ein Service liefert typischerweise innerhalb von Tagen bis Wochen erste funktionierende Antworten, nachdem die Einrichtung und die Dokumentanbindung abgeschlossen sind. Ein abgegrenzter Pilot zur Eigenentwicklung dauert typischerweise Wochen, sofern die Dokumente zugänglich und der Anwendungsfall eng gefasst ist. Die Zeitpläne verlängern sich, wenn Dokumente verstreut sind, Berechtigungen unklar sind oder der Umfang weiter wächst. Ein klar abgegrenzter Pilotumfang mit einem eindeutigen Erfolgsmaßstab ist der beste Schutz gegen ein Projekt, das nie endet.
Was kostet RAG?
Das hängt vom Fragevolumen, der Größe und Änderungsrate des Dokumentbestands, den beteiligten Systemen und davon ab, ob Sie einen Service beziehen oder intern entwickeln. Genau deshalb steht ein abgegrenzter Pilot am Anfang: Er macht aus einer vagen Schätzung eine reale Zahl auf Grundlage Ihrer Dokumente und Ihres Volumens, bevor Sie sich zu etwas Größerem verpflichten.
Können wir später von einem Service zu einer Eigenentwicklung wechseln oder umgekehrt?
Ja, und die Planung dafür ist Teil der Entscheidung. Fragen Sie den Anbieter, wie Sie Ihren Index, Ihre Dokumente und Ihre Evaluierungsdaten exportieren können. Bewahren Sie Ihre Dokumente und Testfragen in jedem Fall in Ihren eigenen Systemen auf, damit das Wissen, das Sie während des Piloten aufgebaut haben, Sie begleitet. Der Pilot ist außerdem der richtige Zeitpunkt, um herauszufinden, welche Kosten ein Wechsel verursachen würde, solange die Risiken noch gering sind.
Das Fazit
RAG as a Service und eine Eigenentwicklung sind nicht einfach eine gute und eine schlechte Option. Sie sind unterschiedliche Antworten auf unterschiedliche Rahmenbedingungen: Geschwindigkeit und Fokus sprechen für einen Service, Kontrolle und Datenverarbeitung für eine Eigenentwicklung, und ein dauerhaft hohes Volumen kann das Gleichgewicht in die eine oder andere Richtung verschieben. Die falsche Vorgehensweise besteht darin, anhand des Listenpreises zu entscheiden. Der richtige Weg ist ein Pilot mit echten Dokumenten und echten Fragen, bei dem die Kosten pro Frage, die Qualität der Antworten und die Stunden gemessen werden, die Ihr Team für den Betrieb aufwendet.
Bei Ridiculous Engineering bieten wir Managed RAG an und unterstützen Teams beim Aufbau von Systemen, die sie selbst betreiben können. Wenn Sie zwischen diesen Optionen abwägen, lassen Sie uns sprechen. Mit unserem Service für KI-Entwicklung und Automatisierungkönnen wir Ihnen dabei helfen, auszuwählen, welche Dokumente Sie verwenden, zu testen, wie gut das System die richtigen Informationen findet, und die Qualität der Antworten in einem Pilotprojekt zu messen, bevor Sie eine größere Verpflichtung eingehen.