Das Problem: Ein Zitat kann exakt sein und dennoch nicht taugen
Ein Retrieval-Augmented-Generation-System, kurz RAG, wird häufig danach bewertet, ob es einen relevanten Text abruft und ob seine Antwort darauf gestützt ist. Diese Kontrolle ist notwendig, reicht aber nicht aus, wenn sich der Korpus verändert. Eine Antwort kann ein Fragment aus einer aufgehobenen Richtlinie, einem ersetzten Handbuch oder einem Vertrag, der für die fragende Person nicht mehr gilt, präzise wiedergeben. Der Fehler liegt dann nicht zwingend in der Generierung, sondern im Lebenszyklus der Evidenz.
Zwei Fragen sollten getrennt werden. Die erste ist semantisch: Beantwortet das abgerufene Fragment die Anfrage? Die zweite betrifft Governance: War es für diese Anfrage und zu diesem Zeitpunkt eine autorisierte, zugängliche und gültige Quelle? Vektorähnlichkeit allein beantwortet die zweite Frage nicht. Ein alter Text kann der Frage ähnlicher sein als eine neue Revision; eine lokale Kopie kann andere Anweisungen enthalten als eine zentrale Richtlinie; und ein Fragment, das indexiert wurde, als eine Person noch Zugriff hatte, kann weiterhin erscheinen, nachdem diese Berechtigung entzogen wurde.
Die operative These ist einfach: Dateien zu einem Index hinzuzufügen, schafft noch keine wartbare Wissensbasis. Dazu braucht es eine stabile Identität für das Dokument, eine identifizierbare Revision, einen Gültigkeitszeitraum, eine Autoritätsregel, während des Retrievals angewandte Zugriffskontrollen und einen Nachweis, der jede Antwort mit den tatsächlich konsultierten Evidenzen verknüpft. Ebenso braucht es einen ausdrücklichen Rückzug: Eine Datei an der Quelle nicht mehr zu veröffentlichen, garantiert nicht, dass sie aus Indizes, Replikaten, Caches oder abgeleiteten Protokollen verschwindet.
Dieser Leitfaden behandelt den Korpus als ein sich wandelndes Aufzeichnungssystem und nicht als einen Dateiordner. Das Ziel ist nicht, fehlerfreie Antworten zu versprechen. Es geht darum, belegen zu können, warum eine Evidenz zulässig war, zu erkennen, wann sie es nicht mehr ist, und sich zu enthalten, wenn die verfügbaren Regeln nicht entscheiden lassen, welche von mehreren aktiven Quellen Vorrang haben soll.
Identität, Revision, Gültigkeit, Autorität und Zugriff trennen
Die Identität beantwortet, welches Dokumentobjekt verwaltet wird. Sie sollte stabil bleiben, auch wenn sich Titel, Speicherort oder Format ändern. So kann etwa eine Unternehmensrichtlinie ihre kanonische Kennung behalten, wenn sie von einem Office-Dokument zu einer Webseite wird. Die Revision beantwortet, welche konkrete Ausgabe den Text enthält. Eine redaktionelle Korrektur und die normative Ersetzung einer Richtlinie können unterschiedliche Revisionen erzeugen, selbst wenn die Änderung klein wirkt.
Die Gültigkeit beschreibt, wann eine Revision als Evidenz verwendet werden darf. Sie darf nicht mit dem Indexierungszeitpunkt oder dem technischen Änderungsdatum der Datei verwechselt werden. Eine heute veröffentlichte Richtlinie kann erst im nächsten Monat in Kraft treten; eine andere kann ausschließlich für historische Anfragen erhalten bleiben. Daher ist es sinnvoll, mindestens einen Beginn der Gültigkeit, gegebenenfalls ein Ende der Gültigkeit sowie einen Betriebsstatus wie Entwurf, genehmigt, aktiv, zurückgezogen oder ausnahmsweise wiederhergestellt zu speichern.
Autorität ordnet Quellen, die dasselbe Thema behandeln können. Eine genehmigte globale Richtlinie kann Vorrang vor einem lokalen Leitfaden haben, außer es besteht eine gültige Ausnahme für eine Rechtsordnung, Organisationseinheit oder ein Produkt. Diese Regel lässt sich weder aus der Formulierung noch aus Ähnlichkeit verlässlich ableiten. Sie muss ein gesteuertes Attribut mit verantwortlicher Person und einer expliziten Vorrangregel sein. Widersprechen sich zwei aktive Quellen und gibt es keine anwendbare Regel, sollte das System nicht nach Beliebtheit oder semantischer Nähe auswählen.
Die Zugriffsberechtigung ist eine weitere unabhängige Dimension. Ein Fragment enthält nicht plötzlich keine geschützten Informationen mehr, nur weil es aufgeteilt, vektorisiert oder in einem Index gespeichert wurde. Autorisierungsfilter müssen vor der Sortierung der Ergebnisse nach Relevanz angewandt und bei Änderungen an Zugriffslisten aktualisiert werden. Die Dokumentation von Suchdiensten bestätigt, dass Sicherheit auf Dokumentebene einschränken kann, welche Dokumente eines Index eine Person sehen darf, und dass Berechtigungsänderungen eine Synchronisierung der betroffenen Dokumente erfordern.
Dieses Design folgt einem grundlegenden Gedanken der Provenienz: Entitäten, Aktivitäten und Akteure zu unterscheiden. Das kanonische Dokument, seine Revision und jedes Fragment sind Entitäten; Extraktion, Segmentierung, Erstellung von Embeddings und Indexierung sind Aktivitäten; Eigentümer, Genehmigende und der Dienst, der einen Prozess ausführt, sind Akteure. Diese Beziehungen zu modellieren verpflichtet nicht zu einer bestimmten Technologie, verhindert aber, dass Nachverfolgbarkeit zu schwer abfragbaren Freitextnotizen wird.
Mindestentscheidung vor dem Abruf eines Fragments
| Dimension | Operative Frage | Behandlung bei Fehlen oder Fehler |
|---|---|---|
| Identität | Ist das Fragment mit einem kanonischen Dokument verknüpft? | Von Antworten mit Evidenz ausschließen. |
| Revision | Ist die genaue Ausgabe bekannt, die das Fragment erzeugt hat? | Ausschließen oder zur Reparatur des Korpus markieren. |
| Gültigkeit | War die Revision zum Zeitpunkt der Anfrage aktiv? | Vor der Ähnlichkeitsberechnung filtern. |
| Autorität | Gibt es eine Vorrangregel für ihren Geltungsbereich? | Konflikt eskalieren oder enthalten. |
| Zugriff | Hat die Person weiterhin Berechtigung, das Dokument zu sehen? | Fragment weder zurückgeben noch für die Generierung verwenden. |
Minimales Datenmodell für einen gesteuerten Korpus
Ein minimales Modell muss nicht alle denkbaren Metadaten erfassen, wohl aber diejenigen, mit denen sich Zulässigkeit entscheiden und Sachverhalte rekonstruieren lassen. Die Entität des kanonischen Dokuments kann eine unveränderliche Kennung, Dokumenttyp, Geltungsbereich, verantwortlichen Eigentümer, Ursprungsquelle und Klassifizierung enthalten. Die Entität Revision benötigt eine eigene Kennung, einen Fingerabdruck des empfangenen Inhalts, einen Genehmigungsstatus, Beginn und Ende der Gültigkeit, ein bekanntes Veröffentlichungsdatum sowie die Beziehung zur vorherigen oder ersetzten Revision.
Jedes abrufbare Fragment muss die Kennung des kanonischen Dokuments und der Revision, eine stabile Position oder einen Bereich innerhalb der Revision, den Fingerabdruck seines normalisierten Textes sowie die erforderlichen Filterattribute tragen. Das Embedding ist nicht das Fragment, sondern eine abgeleitete Repräsentation. Es benötigt daher eine eigene Modellkennung, Konfigurationsversion, einen Berechnungszeitpunkt und einen Verweis auf das exakte Fragment, aus dem es entstanden ist. Auch der Index ist eine operative Entität: Erfassen Sie seine Version, Partition oder Replik, Suchkonfiguration, Veröffentlichungszeitpunkt und die enthaltene Menge von Revisionen.
Fügen Sie explizite Beziehungen für ersetzt, abgeleitet von, zusammengeführt und zurückgezogen hinzu. Eine Dokumentzusammenführung ist nicht zwingend eine Eins-zu-eins-Ersetzung: Mehrere Dokumente können in einer neuen Quelle aufgehen, während für einen Teil der Informationen kein Nachfolger existiert. Diese Unterscheidung ermöglicht die Beantwortung der Fragen, ob ein Dokument zurückgezogen wurde, welcher Nachfolger existiert, sofern einer vorhanden ist, und ob eine historische Anfrage es unter spezifischen Kontrollen weiterhin finden dürfen soll.
Zeitfelder erfordern besondere Disziplin. Speichern Sie den an der Quelle beobachteten Zeitpunkt, den Genehmigungszeitpunkt, den geschäftlichen Gültigkeitszeitraum, den Extraktionszeitpunkt und den Zeitpunkt der Veröffentlichung im Index. Setzen Sie nicht voraus, dass sie austauschbar sind. Um eine Antwort zu rekonstruieren, ist wichtig zu wissen, was bekannt war und was operativ verfügbar war, zusätzlich dazu, welcher Text selbst behauptete, gültig zu sein. Wenn die Uhren mehrerer Systeme nicht synchron sind oder ein Datum aus wenig verlässlichen Metadaten stammt, dokumentieren Sie diese Unsicherheit, statt sie künstlich in Gewissheit zu verwandeln.
Entitäten und Felder, die erhalten bleiben sollten
| Entität | Mindestfelder | Zweck |
|---|---|---|
| Kanonisches Dokument | Stabile ID, Eigentümer, Geltungsbereich, Klassifizierung, Autorität | Das gesteuerte Objekt identifizieren. |
| Revision | ID, Fingerabdruck, Status, Gültigkeit, Nachfolger oder Vorgänger | Bestimmen, welche Ausgabe verwendet werden darf. |
| Fragment | ID, Revision, Bereich, Textfingerabdruck, Filtermetadaten | Nachvollziehbare Evidenz abrufen. |
| Embedding | ID, Fragment, Modell, Konfiguration, Datum | Die abgeleitete Repräsentation vom Text unterscheiden. |
| Indexveröffentlichung | ID, Konfiguration, enthaltene Menge, Veröffentlichungszeit | Die Suchumgebung rekonstruieren. |
| Antwortereignis | Anfrage, Filter, Kandidaten, Indexversion, Zeitpunkt | Verfügbare und ausgewählte Evidenz erklären. |
Änderungsabläufe: Aktualisieren ist nicht nur ein Vorgang
Die erstmalige Aufnahme beginnt mit der Validierung von Quelle, Identität, Eigentümer, Klassifizierung und Zugriffsregeln. Danach wird Inhalt extrahiert, eine Revision erstellt, segmentiert, Repräsentationen werden berechnet und eine Indexversion veröffentlicht. Die Veröffentlichung sollte aus Sicht der Anfrage atomar sein oder zumindest Zustände verhindern, in denen ein Teil einer Revision sichtbar und ein anderer nicht sichtbar ist. Sind Genehmigungen erforderlich, kann ein Entwurf technisch verarbeitet werden, ohne für Antworten zulässig zu sein.
Eine kleinere Korrektur erfordert, den neuen Fingerabdruck mit der vorherigen Revision zu vergleichen und die geänderten Segmente zu lokalisieren. Nur betroffene Fragmente neu zu berechnen kann Aufwand senken, aber nur, wenn der Segmentierungsalgorithmus korrekte Referenzen erhält. Verschiebt eine Änderung Überschriften, Nummerierungen oder Abschnitte, kann sie mehr Fragmente betreffen, als ein wörtlicher Vergleich erkennen lässt. Optimierung muss der Nachverfolgbarkeit nachgeordnet sein: Es ist besser, mehr Inhalte neu zu indexieren, als mehrdeutige Verknüpfungen zwischen einem Embedding und einem Text zu behalten.
Die Ersetzung einer Richtlinie ist ein Governance-Ereignis. Sie muss eine Nachfolgerrevision oder ein Nachfolgerdokument erzeugen, das Datum des Inkrafttretens festlegen, die Gültigkeit des Vorgängers gegebenenfalls beenden und den Rückzug auf alle abgeleiteten Artefakte übertragen. In bestimmten Indexierungssystemen können Dokumente, die an der Quelle nicht mehr vorhanden sind, eine ausdrückliche Löschaktion erfordern; eine erneute Ausführung darf daher nicht als Beleg eines vollständigen Rückzugs gelten. Die Überprüfung muss den Status von Indizes und Replikaten abfragen, nicht nur das Quellenregister.
Ein vollständiger Rückzug bewahrt, soweit die Aufbewahrungsrichtlinie dies zulässt, einen Verlauf, der für gewöhnliche Antworten nicht zulässig ist. Dieser Verlauf kann für Audits, Incident-Untersuchungen oder die Rekonstruktion einer vergangenen Antwort nötig sein. Er muss von aktiven Indizes getrennt sein sowie Zugriffskontrollen und einen definierten Zweck haben. Eine zurückgezogene Quelle wiederherzustellen, ist außergewöhnlich: Es sollte ein neues Ereignis erzeugen, die Statusänderung begründen und eine neue überprüfbare Veröffentlichung auslösen, statt die Spur des früheren Rückzugs zu löschen.
Prozess zur Ersetzung einer Quelle
- 01Die eingehende Revision, ihren Eigentümer, ihre Autorität und ihr geplantes Gültigkeitsdatum erfassen.
- 02Inhalt und Metadaten mit der gültigen Revision vergleichen; betroffene Fragmente und Nachfolgebeziehungen identifizieren.
- 03Die neue Revision gemäß dem anwendbaren Dokumentenprozess genehmigen oder ablehnen.
- 04Fragmente und Embeddings erstellen oder aktualisieren; eine identifizierbare Indexversion veröffentlichen.
- 05Die vorherige Revision zum festgelegten Datum als ersetzt oder zurückgezogen markieren und aus der Retrieval-Zulässigkeit entfernen.
- 06Gespeicherte Retrieval-Ergebnisse und Antworten invalidieren, die von der vorherigen Revision abhängen.
- 07Tests für Anfragen, Berechtigungen, Replikate und Caches ausführen; das Ergebnis der Bereitstellung aufbewahren.
Reindexierung, Caches und Duplikate: Repräsentationen konsistent halten
Selektive Reindexierung ist sinnvoll, wenn die Beziehung zwischen jeder Repräsentation und ihrer Eingabe nachweisbar ist. Berechnen Sie Unterschiede im Text und in den Metadaten. Eine Inhaltsänderung verlangt eine Überprüfung der betroffenen Fragmente und Embeddings. Eine Änderung der Gültigkeit, Autorität, Rechtsordnung oder Berechtigung verändert möglicherweise nicht den Text, wohl aber die Retrieval-Zulässigkeit; deshalb müssen Filter, Metadatenindizes und Caches aktualisiert werden. Nur Textänderungen zu behandeln, öffnet einen Weg zu falschen Antworten mit wörtlich unverändertem Inhalt.
Nicht alle Caches speichern dasselbe. Es kann Caches für das Herunterladen aus der Quelle, für verarbeitete Fragmente, für Embeddings, für Retrieval-Ergebnisse und für finale Antworten geben. Jeder benötigt einen Schlüssel, der relevante Abhängigkeiten enthält, etwa die Indexversion, die Revision der Quellen, die Identität der Person oder ihre Zugriffsgruppe, die Rechtsordnung und das Datum der Anfrage, wenn über Gültigkeit geantwortet wird. Eine Antwort ohne diese Dimensionen wiederzuverwenden, kann Inhalte offenlegen oder eine zurückgezogene Richtlinie wieder zum Leben erwecken.
Die Prinzipien von Web-Caches unterscheiden Frische, Validierung und Invalidierung und legen fest, dass Anfragen, die den Zustand einer Ressource ändern, die anwendbaren gespeicherten Repräsentationen invalidieren sollen. Im RAG-Korpus kann der konkrete Mechanismus abweichen, das Prinzip ist jedoch übertragbar: Ändert sich eine Quelle oder ihre Zulässigkeit, müssen abgeleitete Repräsentationen, die noch die alte Version ausliefern könnten, lokalisiert und entfernt oder invalidiert werden.
Semantische Duplikate benötigen eine explizite Richtlinie. Zwei Fragmente können dieselbe Regel ausdrücken und unterschiedlichen Revisionen angehören; beide zurückzugeben kann das Vertrauen des Modells künstlich erhöhen. Gruppieren Sie Kandidaten vor der Antwortgenerierung nach kanonischem Dokument oder nach Revisionsbeziehung. Die Gruppierung darf Konflikte nicht verbergen: Weichen zwei aktive und gleich autorisierte Quellen voneinander ab, muss der Konflikt als Signal erhalten bleiben, sich zu enthalten oder eine menschliche Prüfung anzufordern.
Mit Zeit, Autorität und Berechtigungen abrufen, bevor nach Ähnlichkeit sortiert wird
Die Retrieval-Anfrage sollte als Abfolge von Einschränkungen und Sortierung aufgebaut werden, nicht als Vektorsuche mit einer optionalen Prüfung danach. Bestimmen Sie zuerst den Kontext: Identität der fragenden Person, effektive Berechtigungen, Produkt, Rechtsordnung, Zielgruppe, relevantes Datum und einen möglichen Bedarf an historischen Informationen. Filtern Sie danach Revisionen und Fragmente aus, die diesen Kontext nicht erfüllen. Nur zulässige Kandidaten dürfen in die Ähnlichkeitsberechnung, die lexikalische Suche oder eine Kombination aus beiden eingehen.
Das relevante Datum erfordert eine sichtbare Produktentscheidung. Für Fragen zur gegenwärtigen Regel verwenden Sie den Zeitpunkt der Anfrage. Bei Fragen wie „Welche Richtlinie galt, als ich unterschrieben habe?“ fordern Sie ein Bezugsdatum an oder leiten es vorsichtig ab und suchen im autorisierten Verlauf. Ist das Datum unbekannt, stellen Sie eine historische Rekonstruktion nicht als aktuell dar. Es ist besser, die Angabe anzufordern, den zeitlichen Umfang der Evidenz zu zeigen oder die Antwort auf das zu begrenzen, was begründet werden kann.
Autorität kann als Bewertung umgesetzt werden, sollte aber nicht immer auf eine Zahl reduziert werden. Manche Regeln sind hart: Eine verbindliche Vorgabe für eine Rechtsordnung kann einen allgemeinen Leitfaden ausschließen. Andere können bevorzugend sein und Koexistenz zulassen. Dokumentieren Sie die Regeln, ihre Eigentümer und Ausnahmen. Das generative System sollte keine Hierarchie aus dem Tonfall der Dokumente erfinden.
Bewahren Sie vor dem Formulieren die Liste gefilterter Kandidaten, die Ausschlussgründe, die Indexkonfiguration und die letztlich verwendeten Fragmente auf. Das Protokoll muss zwischen abgerufener Evidenz und in der Antwort zitierter Evidenz unterscheiden. Es muss außerdem die Anfragezeit und die Version der Filterregeln erfassen. Ohne diese Daten kann eine spätere Untersuchung zwar das aktuelle Dokument finden, aber nicht belegen, welcher Korpus das ursprüngliche Ergebnis hervorgebracht hat.
Empfohlene Reihenfolge einer Anfrage mit Evidenz
- 01Identität, Berechtigungen und Kontext der nutzenden Person auflösen.
- 02Bezugsdatum und Geltungsbereich der Anfrage festlegen.
- 03Zurückgezogene, abgelaufene, zukünftige, nicht autorisierte oder nicht zum Geltungsbereich passende Dokumente und Revisionen ausschließen.
- 04Regeln zu Autorität, Rechtsordnung, Produkt und Zielgruppe anwenden.
- 05Nur innerhalb der zulässigen Menge suchen und sortieren.
- 06Verwandte Revisionen gruppieren und ungelöste Konflikte erkennen.
- 07Eine auf die ausgewählte Evidenz begrenzte Antwort erzeugen oder sich enthalten.
- 08Kandidaten, Ausschlüsse, Index, Regeln und Zeitpunkt der Anfrage protokollieren.
Regressionstests, Abbruchkriterien und Verantwortlichkeiten
Tests müssen das Verhalten des Systems bei Änderungen bewerten, nicht nur die Retrieval-Qualität auf einer stabilen Menge. Erstellen Sie Fälle mit einer zurückgezogenen Richtlinie, die ihrem Ersatz ähnlicher ist, einem aus einer Revision gelöschten Fragment, einer genehmigten Richtlinie mit zukünftigem Gültigkeitsdatum, einer lokalen Kopie, die einer zentralen Quelle widerspricht, und einer nach der Indexierung entzogenen Berechtigung. Jeder Fall muss erklären, welche Dokumente zulässig sind, welches bei vorhandener Autoritätsregel gewinnen soll und wann die korrekte Ausgabe Enthaltung ist.
Testen Sie außerdem die zeitliche Ausbreitung. Messen Sie die Zeitspanne zwischen der Genehmigung eines Rückzugs und dessen wirksamem Ausschluss aus relevanten Indizes, Replikaten und Caches. Es genügt nicht, nur den Hauptindex zu testen: Eine zuvor erzeugte Antwort kann in einer anderen Schicht gespeichert sein. Definieren Sie je nach Risiko der Quelle unterschiedliche Zeitziele. Eine Sicherheitsrichtlinie oder ein Dokument mit sensiblen Daten kann eine schnellere Invalidierung erfordern als ein interner redaktioneller Leitfaden.
Legen Sie klare Abbruchkriterien fest. Blockieren Sie eine Antwort, wenn die Verknüpfung zwischen Fragment und Revision fehlt, wenn Berechtigungen nicht bewertet werden können, wenn die Quelle keinen Eigentümer hat oder wenn ein aktiver Konflikt ohne Vorrangregel besteht. Zeigen Sie das Aktualisierungsdatum, wenn es zur Interpretation der Antwort beiträgt, aber verwenden Sie es nicht, um Unsicherheit zu verschleiern. Leiten Sie zur menschlichen Prüfung weiter, wenn potenziell relevante Evidenz besteht, die das System mit expliziten Regeln nicht ordnen kann.
Verantwortlichkeiten sollten getrennt sein, auch wenn in kleinen Teams eine Person mehrere Rollen übernehmen kann. Der Quelleigentümer verantwortet den Inhalt und seinen Gültigkeitszyklus. Die für Indexierung verantwortliche Person steht für Extraktion, Veröffentlichung und technische Invalidierung ein. Die genehmigende Instanz für die Gültigkeit entscheidet, wann eine Revision verwendbar ist. Die für Incidents verantwortliche Person koordiniert den dringenden Rückzug, die Bewertung einer möglichen Offenlegung und die Kommunikation. Das Produktteam definiert, wie Enthaltung ausgedrückt und wie zusätzlicher Kontext von der nutzenden Person angefordert wird.
Als nächsten Schritt sollten Sie dieses Modell in eine Liste überprüfbarer Kontrollen überführen und mit den Leitfäden des Lernbereichs zur Bewertung von Assistenten, zum Vergleich von Retrieval-Ansätzen und zur Entdeckung von Quellen verknüpfen. Die Umsetzung hängt von der Architektur ab, doch das Erfolgskriterium bleibt gleich: Für jede relevante Antwort muss das Team erklären können, welche Evidenz verwendet werden durfte, welche verwendet wurde, warum sie autorisiert war und was eine Antwort verhindert hätte.
Minimale Batterie von Regressionstests
| Fall | Erwartetes Ergebnis | Testnachweis |
|---|---|---|
| Ersetztes Dokument | Die neue Revision hat Vorrang, auch wenn die alte ähnlicher ist. | Protokoll der Filter, Kandidaten und ausgewählten Revision. |
| Zurückgezogenes Fragment | Es erscheint weder im Retrieval noch in einer gespeicherten Antwort. | Abfrage der Indizes und Prüfung der Cache-Invalidierung. |
| Zukünftige Gültigkeit | Es wird nicht für eine Frage zur aktuellen Regel verwendet. | Bezugsdatum und Ausschlussgrund. |
| Lokaler und zentraler Konflikt | Die Autoritätsregel wird angewandt oder das System enthält sich. | Ausgewertete Regel und resultierende Entscheidung. |
| Entzogene Berechtigung | Das Fragment ist für die betroffene Identität nicht mehr sichtbar. | Test mit berechtigter und nicht berechtigter Identität. |
| Historische Rekonstruktion | Die damals verfügbare Evidenzmenge wird reproduziert. | Indexversion, Uhrzeit der Anfrage und Antwortprotokoll. |
Offene Fragen
- Die genaue Darstellung von Berechtigungen, Gültigkeit und Autoritätsregeln hängt vom Dokumentenrepository, der Suchmaschine und den regulatorischen Anforderungen jeder Organisation ab.
- Eine selektive Reindexierung ist nur sicher, wenn das System nachweisen kann, welche Fragmente und Repräsentationen aus jeder Revision abgeleitet wurden; andernfalls kann es erforderlich sein, eine größere Menge neu zu indexieren.
- Die historische Rekonstruktion kann durch die Aufbewahrungsrichtlinie, die Erhaltung von Indexversionen und die Verfügbarkeit von Audit-Protokollen begrenzt sein.
- Die Dokumentationen der Anbieter beschreiben Fähigkeiten und Verhaltensweisen konkreter Produkte; sie belegen nicht, dass jede RAG-Architektur ohne eigene Implementierung und Tests dieselben Garantien bietet.
Weiter entdecken
Verwendete Quellen
Korrekturen und Transparenz
Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.
Korrektur vorschlagen