Dokumentensuche über einen Korpus im Überblick: Indexierungs-Pipeline, Berechtigungen und Reindexierung

Ziel

Suche über einen Korpus, der in einem führenden System liegt, mit Ergebnissen, die Berechtigungen respektieren, und einem Index, der der Quelle nie um mehr als eine festgelegte Grenze hinterherhinkt.

Voraussetzungen

Eine Definition eines Dokuments (id, title, body, metadata, owner, visibility, updated_at), die beteiligten Sprachen, und eine vom Produkt akzeptierte Aktualitätsgrenze.

Schritte

1. Randbedingungen: Die Quelle bleibt massgeblich, und der Index ist abgeleitet und neu erstellbar; ein Nutzer darf nie einen Ausschnitt eines Dokuments sehen, das er nicht öffnen kann; Abfragen bei jedem Tastenanschlag sind eine Produktentscheidung, kein Standardfall.
2. Komponenten: ein Indexer, gespeist von Änderungsereignissen (einer Outbox) oder durch Polling von updated_at; ein Index-Speicher, zunächst der eigene Volltextindex der Datenbank, dann eine dedizierte Engine, sobald Ranking-Funktionen oder Skalierung es verlangen; ein Abfragedienst, der Eingaben parst, Berechtigungsfilter anwendet, rankt und hervorhebt; ein Abgleicher, der Quelle und Index vergleicht.
3. Datenmodell: search_doc(doc_id, version, text fields, acl_keys[], updated_at, indexed_at); die ACL-Schlüssel (owner id, group ids, public) sind indexierte Felder, sodass die Filterung innerhalb der Engine stattfindet statt erst nach dem Ranking. In PostgreSQL hält die Dokumentation fest, dass GIN-Indizes der bevorzugte Indextyp für die Volltextsuche sind, mit einem Eintrag pro Lexem und einer komprimierten Liste von Fundstellen.
4. Index-Verwaltung: den Index versionieren (docs_v3) und nach einem vollständigen Neuaufbau einen Alias umschalten; den Indexer idempotent halten (Upsert nach doc_id, ältere Versionen als die indexierte ignorieren); Löschungen als explizite Ereignisse behandeln, nie durch Abwesenheit.
5. Ranking: mit der Standardrelevanz der Engine plus einer Titelgewichtung und einem Aktualitätsterm beginnen; Abfrage, Ergebnis-IDs und Klickposition protokollieren, damit eine spätere Ranking-Änderung anhand des Logs beurteilt werden kann.
6. Fehlermodi: verpasste Änderungsereignisse (der Abgleicher vergleicht Anzahlen und maximales updated_at pro Bereich und reindexiert die Differenz); nicht propagierte Berechtigungsänderungen (ACL-Bearbeitungen als Dokumentaktualisierungen behandeln); sehr lange oder wildcard-lastige Abfragen (Länge deckeln, führende Wildcards verbieten); Reindexierung unter Last (drosseln, von einer Replika lesen); Ausschnitte, die Felder offenlegen, die das sichtbare Dokument verbirgt (nur indexieren, was gezeigt werden darf).
7. Messen: Index-Verzögerung (updated_at der Quelle minus indexed_at), Abfragelatenz, Anteil ergebnisloser Abfragen, Anteil der Abfragen mit einem Klick unter den Top-Ergebnissen, vom Abgleicher gefundene Drift, Dauer einer vollständigen Reindexierung.
8. Nicht zuerst: semantische oder Vektorsuche, Synonyme und Rechtschreibkorrektur, personalisiertes Ranking, Autovervollständigung, sprachübergreifende Suche.

Erwartetes Ergebnis

Ein in der Quelle bearbeitetes Dokument erscheint innerhalb der Aktualitätsgrenze, verschwindet, wenn es gelöscht oder verborgen wird, und ein Neuaufbau von Grund auf ist eine Routineoperation statt eines Vorfalls.

Grenzen und Prüfbasis

Vorgeschlagenes Design, keine Messungen. Die Relevanzqualität wird nicht behandelt, ausser dass genug protokolliert wird, um sie später bewerten zu können; die Aktualitätsgrenze ist eine Produktvorgabe, keine Eigenschaft des Designs.