Hybride Suche mit lokalem Modell, Kennzahlen mit einer Definition

Zwei Suchen, eine Rangfolge

Stichwortsuche findet, was wörtlich dasteht – und verfehlt alles, was anders formuliert ist. Vektorsuche findet Bedeutung – und verfehlt manchmal die Artikelnummer, nach der jemand tatsächlich gesucht hat. Beides einzeln ist unbefriedigend, deshalb werden die Ergebnisse zu einer Rangfolge verschmolzen.

Suche  "Rahmenvertrag Kündigungsfrist Lieferant"

  Verfahren   Vektor + Stichwort, fusioniert
  Modell      nomic-embed-text  (lokal, CPU, ohne Schlüssel)

  1  vertraege/rahmen_2024.pdf     Abschnitt 4.2
  2  lakehouse.raw.vertraege       Zeile 8817
  3  wiki/beschaffung.md           Abschnitt "Fristen"

Der Index ist nur ein Index

Das ist die Stelle, an der Suchfunktionen in Datenplattformen üblicherweise die Governance aushebeln. Wenn der Vektorspeicher den Inhalt selbst hält, hat man einen zweiten Datenbestand mit eigener Zugriffskontrolle – und die zweite Kontrolle kennt die Policies der ersten nicht.

In lavalake merkt sich der Vektorindex nur, welche Spalten Schlüssel und Text sind. Der Treffer wird danach unter dem Token des Suchenden aus Trino nachgeladen. Wer eine Zeile nicht sehen darf, bekommt sie auch als Suchtreffer nicht; eine maskierte Spalte bleibt maskiert.

Ein Suchindex, der Inhalte hält, ist ein zweiter Datenbestand. Ein Suchindex, der nur zeigt, wo etwas steht, ist keiner.

Kennzahlen mit genau einer Definition

Die Semantikschicht trägt kuratierte Kennzahlen und tabellenübergreifende Semantic Views. Der Sinn ist nicht Bequemlichkeit, sondern Eindeutigkeit: „Umsatz“ ist einmal definiert, und die Dashboard-Kachel, die Suche und der KI-Agent rechnen mit derselben Definition.

Der Assistent darf Kennzahlen vorschlagen und anlegen – mit Rückfrage und Protokolleintrag. Damit lässt sich das semantische Modell aus den vorhandenen Daten heraus aufbauen, statt darauf zu warten, dass jemand Zeit für eine Definitionsrunde findet.

Abfragen und Dashboards

Neben der Suche gibt es das gewöhnliche Werkzeug: einen Datenbrowser von Katalog über Schema bis zur Tabelle, und ein SQL-Worksheet, das Trino-SQL gegen Iceberg schickt. Ergebnisse lassen sich als Kachel auf ein Dashboard legen.

Wichtig dabei: eine Kachel speichert die Abfrage, nicht das Ergebnis. Sie rechnet bei jedem Betrachter unter dessen Identität. Zwei Personen können dasselbe Dashboard öffnen und unterschiedliche Zahlen sehen – und das ist richtig so, wenn ihre Rechte unterschiedlich sind.

• Datenbrowser mit Sprung zur Herkunft je Tabelle
• SQL-Worksheet über Trino, unter Ihrer Identität
• Dashboards aus Abfragen und Kennzahlen
• Kacheln rechnen je Betrachter, nicht je Ersteller
• Inkrementelle Materialisierung für teure AbfragenIn Entwicklung
• Alerting und geplante BerichteIn Entwicklung