hiveo
Ein Wissensspeicher für ein ganzes Unternehmen, gebaut für einen großen deutschen Mittelständler. Gefragt wird aus dem KI-Chat, den die Leute ohnehin offen haben, und jede Antwort nennt ihre Quelle.
hiveo ist der Arbeitstitel einer Insellösung, entworfen und gebaut für einen einzigen Kunden. Zu kaufen gibt es sie nicht. Die Frage dahinter betrifft aber jede Firma: Wie organisiert ein Unternehmen sein Wissen, wenn jeder Mitarbeiter mit KI arbeitet?
Damit das im Alltag trägt, braucht es eine Suche, die auch unter zehntausenden Dokumenten die richtige Seite findet, Rechte, die vor der Suche greifen, und Quellen, die man nachprüfen kann. Warum die meisten Second Brains genau daran scheitern, steht im Essay.
Firmenwissen liegt selten als sauberer Text vor. Es steckt in Scans, Excel-Listen und PDFs mit Tabellen über zwei Seiten. Bevor etwas gefunden werden kann, muss jede Datei lesbar werden.
- LesenText aus der Datei holenWartet
- ZerlegenIn Abschnitte teilenWartet
- EinbettenFür die Suche vektorisierenWartet
PDF, Word, Excel, PowerPoint, HTML, Markdown, Text, Fotos und Scans. Ein Python-Worker liest digitale Dateien lokal mit docling und schickt Scans durch eine Texterkennung. Überschriften, die der Parser plattdrückt, werden aus ihrer Nummerierung wieder aufgebaut. Wird ein Dokument ersetzt, verschwinden seine alten Abschnitte, denn ein Abschnitt, der nicht mehr gilt, sieht trotzdem aus wie eine gute Antwort.
Eine Frage ist eine einzige Datenbankabfrage. Rechte, Vektorsuche, Volltext und Rangfolge laufen in einem Postgres-Statement. Jede Zelle hier ist ein Abschnitt aus dem Testbestand.
Bestand und Abfrage wie im Testkorpus und in search.ts. Ordner, Rechte und Rangfolgen sind ein Beispiel.
Nicht alles gehört in Vektoren. Prüffristen, Ersatzteile und Zählerstände bleiben Zeilen in Postgres, abgefragt per SQL, mit denselben Rechten wie die Dokumente.
Ein Vektorindex weiß, wovon eine Stelle handelt. Welche Prüfungen bis Jahresende fällig sind, ist eine Frage für SQL. Die Antwort darf beides verbinden: Zeilen aus query_tables und die Textstelle aus search, in einer Antwort.
Jede Person bekommt ihren eigenen Zugang. Die KI arbeitet mit genau deren Rechten. Wer nur lesen darf, kann auch über den Chat nichts anlegen, ändern oder löschen.
Drei Ebenen: Ordner- und Tabellenrechte regeln, was jemand sehen und anfassen darf, Fähigkeiten, welche Werkzeuge er benutzen darf, Plattformrollen, wer verwaltet. Löschen ist ein eigenes Werkzeug, das nur eine ausdrückliche Liste von Zeilen annimmt, und ein freies DELETE kommt an der SQL-Prüfung nie vorbei.
Jeder Aufruf landet im Protokoll: wer, welches Werkzeug, wann und mit welchem Ergebnis. Auch die abgelehnten.
Jede Änderung an der Suche läuft gegen einen festen Satz echter Fragen mit bekannten Antworten. Was die Zahlen nicht verbessert, fliegt wieder raus.
Ein Reranker sortiert die Treffer ein zweites Mal mit einem eigenen Modell, viele RAG-Anleitungen empfehlen einen. Hier kostete er 2,6 Punkte auf Platz 1, einen API-Aufruf mehr pro Frage und verbesserte nichts. Er bleibt als Option im Code und ist abgeschaltet. Das Ziel dahinter: Die Pipeline muss auch bei zehntausenden Dokumenten tragen, und ob sie das tut, zeigt nur eine Messung.
Gebaut von einer Person, zusammen mit KI. 1.144 Commits in 70 Tagen, drei von vier mit Claude als Co-Autor.
Ein TypeScript-Monorepo mit API und MCP-Server (Hono), einem Verwaltungs-Dashboard (Next.js) und einem Design-System, dazu ein Python-Worker für die Aufnahme. Eine Postgres-Datenbank mit pgvector, Volltext und 24 Tabellen, neun MCP-Werkzeuge. Jede Änderung wird vorher beschrieben, dann geprüft und automatisch getestet, bevor sie zusammengeführt wird.