Hybride Suche mit PostgreSQL: Wenn Schlüsselwörter nach wie vor eine Rolle spielen

Die semantische Suche ist hilfreich, wenn ein Kunde ein Problem mit anderen Worten beschreibt als in der Dokumentation. Sie kann jedoch weniger aussagekräftig sein, wenn der entscheidende Teil der Frage eine genaue Produktnummer, eine kurze Fehlermeldung oder eine Modellnummer ist.

Ein Support-System benötigt beide Arten von Belegen. Ich schätze PostgreSQL als Ausgangspunkt, da die relationalen Daten der Anwendung und die Metadaten für den Datenabruf eng beieinander bleiben können, während sich das Design für den Datenabruf noch weiterentwickelt.

Lassen Sie verschiedene Abrufpfade Kandidaten beisteuern

Bei einer dichten Vektorsuche wird gefragt, welche Textstellen im Einbettungsraum nahe beieinander liegen. Bei einer lexikalischen Suche wird gefragt, welche Textstellen gemäß den Regeln der Textverarbeitung mit den Begriffen der Suchanfrage übereinstimmen. Keine dieser Fragen ist identisch mit der Frage: „Welche Textstelle belegt die Antwort?“

Bei einer Suchanfrage, die eine bekannte SKU enthält, würde ich auch einen speziellen Pfad für die exakte Übereinstimmung in Betracht ziehen. Bei der Tokenisierung der Textsuche können Kennungen aufgeteilt oder normalisiert werden, daher sollte die exakte Produktsuche nicht vollständig von einer Suchkonfiguration in natürlicher Sprache abhängen.

In der pgvector-Dokumentation wird die Kombination der Vektorabfrage mit der PostgreSQL-Volltextsuche beschrieben und für die Zusammenführung der Ergebnisse eine Rangfusion oder ein Cross-Encoder vorgeschlagen. Ich nutze diese Verfahren als mögliche Ansätze, die es zu evaluieren gilt, anstatt davon auszugehen, dass das Hinzufügen weiterer Stufen das Ergebnis zwangsläufig verbessern muss.

Zugriffs- und Verfügbarkeitsbeschränkungen frühzeitig festlegen

Mandant, Dokumentensichtbarkeit, Veröffentlichungsstatus und der relevante Markt sind bei der Kandidatenauswahl zu berücksichtigen. Das Abrufen von Daten über alle Mandanten hinweg und das anschließende Filtern stellt sowohl ein Berechtigungsproblem als auch ein Ranking-Problem dar.

Das gleiche Problem tritt auch bei approximativen Vektorindizes auf. Wenn restriktive Filter zu wenige in Frage kommende Ergebnisse liefern, untersuche ich den Abfrageplan und das Abrufverhalten für die installierte Erweiterungsversion. Eine Erhöhung der globalen Kandidatenanzahl ist kein Ersatz für die Messung der gefilterten Arbeitslast.

Ich verwende eine Basislinie für die exakte Suche auf einem überschaubaren Evaluierungsdatensatz. Dies hilft dabei, Verluste, die durch eine ungefähre Indizierung entstehen, von Fehlern zu unterscheiden, die durch Einbettungen, die Aufteilung in Blöcke oder das Korpus selbst verursacht werden.

Ranglisten zusammenführen, ohne so zu tun, als seien die Punktzahlen gleichwertig

Ein lexikalischer Relevanzwert und ein Vektorähnlichkeitswert haben in der Regel unterschiedliche Bedeutungen und Verteilungen. Die Addition ihrer Rohwerte mit beliebigen Gewichtungen kann dazu führen, dass das Ergebnis empfindlich auf Änderungen bei einer Komponente reagiert.

Die rangbasierte Fusion bietet eine nützliche Alternative. Der folgende Pseudocode veranschaulicht das Prinzip; es handelt sich dabei nicht um eine optimierte Produktionskonfiguration:

for each ranked result list:
    for each candidate at rank r, starting at 1:
        score[candidate.id] += 1 / (rank_constant + r)

return candidates ordered by combined score

Die Rangkonstante bestimmt, wie stark die Spitzenpositionen dominieren. Ich lege sie im Rahmen einer Bewertung fest, zusammen mit der Größe des Kandidatenpools und einer eventuellen späteren Neureihenfolge. Diese Parameter sollten zusammen mit der Abrufkonfiguration versioniert werden.

Die Identität der Quelle über die gesamte Pipeline hinweg bewahren

Ein Textabschnitt sollte seine Dokument-ID, Version, seinen Abschnitt, seine Sprache und seine Zugriffsmetadaten beibehalten. Auch nach der Zusammenführung und Neugewichtung muss der Generator weiterhin wissen, woher die Informationen stammen und welche Quellversion sie repräsentieren.

Außerdem beschränke ich die Anzahl wiederholter Passagen aus einem Dokument, wenn diese nützliche Alternativen verdrängen. Das ist eine Entscheidung zugunsten der Vielfalt, die Kompromisse mit sich bringt: Manche Fragen erfordern nun einmal mehrere benachbarte Passagen. Eine starre Ein-Passage-Regel kann notwendigen Kontext weglassen.

In der Übersicht zur Volltextsuche von PostgreSQL wird erläutert, wie Dokumente und Abfragen für den Abgleich normalisiert werden. Bei einem mehrsprachigen Korpus sollte der Wahl der Sprachkonfiguration besondere Aufmerksamkeit gewidmet werden, insbesondere wenn Produktkennungen unverändert bleiben müssen.

Die Pipeline sollte nur so komplex sein, wie es die Fakten rechtfertigen

Ich vergleiche lexikalisches Retrieval, Dense Retrieval, deren Kombination sowie verschiedene Reranking-Schritte anhand derselben Fragen. Die Untersuchung umfasst beantwortbare Fälle, nicht unterstützte Fragen, exakte Identifikatoren und verschiedene Sprachen.

Ein hybrides Design rechtfertigt seine zusätzlichen Latenzzeiten und Wartungskosten, wenn es zuverlässig Beweise liefert, die einfachere Alternativen übersehen. Das nützliche Ergebnis ist eine fundiertere Antwort, nicht ein aufwendigeres Abrufdiagramm.

Aktualisiert am 25. September 2026.