Eine souveräne Alternative zu AnythingLLM

AnythingLLM kann viel, und kann es gut

AnythingLLM ist eines der besseren Ergebnisse der Self-Hosting-Welle in der KI. Es ist eine All-in-One-Anwendung von Mintplex-Labs, die du auf eigener Hardware betreibst: per Docker, auf Bare Metal, auf einer Cloud-VM oder als Ein-Klick-Desktop-App für Mac, Windows und Linux. Du verbindest ein Modell, lädst Dokumente hoch und erhältst eine private, ChatGPT-artige Oberfläche über deine eigenen Dateien. Es ist MIT-lizenziert und macht in der Nutzung wirklich Freude.

Seine Stärken sind echt. Du organisierst Dokumente in Workspaces, jeder mit seinem eigenen, isolierten Satz an Dateien. So können sich ein Rechtsteam und ein Marketingteam eine Instanz teilen, ohne das Material des jeweils anderen zu sehen. Es lässt sich mit nahezu jedem Modell verbinden: OpenAI, Anthropic, Google Gemini, Mistral und Groq auf der API-Seite oder Ollama, LM Studio und LocalAI, wenn alles lokal laufen soll. Es bietet Agenten, die im Web surfen und Tools aufrufen können, einen No-Code-Agent-Builder, Mehrbenutzer-Steuerung und eine Developer-API. Wenn du einen ausgereiften Team-Hub für den Chat mit einem großen, gemischten Dokumentenberg suchst, ist AnythingLLM eine starke, ehrliche Wahl.

Das ist also nicht der übliche Cloud-vs-Lokal-Vergleich. AnythingLLM ist bereits selbstgehostet. Der interessante Unterschied ist architektonisch: wie jedes Tool deine Dokumente in etwas verwandelt, aus dem ein Modell antworten kann, und was das über die Zeit kostet.

Die Vektordatenbank-Steuer

Wenn du ein Dokument in einen AnythingLLM-Workspace einfügst, wird es „gespeichert und eingebettet". Im Hintergrund wird der Text in Abschnitte zerlegt, durch ein Embedding-Modell geschickt und als Vektoren in einer Vektordatenbank abgelegt: standardmäßig LanceDB, oder Pinecone, Chroma, Weaviate, Qdrant, Milvus, PGVector und weitere, wenn du skalierst. Bei der Abfrage wird auch deine Frage eingebettet, und das System ruft die Abschnitte ab, deren Vektoren ihr am nächsten liegen. Das ist klassisches RAG, und es funktioniert.

Es bringt aber Kosten mit sich, die man leicht unterschätzt, bis man damit lebt:

• Du betreibst den Vektorspeicher. Das ist ein weiterer zustandsbehafteter Dienst, den du betreiben, sichern, schützen und am Leben halten musst. Der bequeme Standard (LanceDB) ist auf einem Laptop in Ordnung; eine ernsthafte Mehrbenutzer-Installation bedeutet meist, einen eigenständigen Vektordatenbank-Server aufzusetzen und zu pflegen.
• Der Index driftet von den Dokumenten weg. Die Embeddings sind eine abgeleitete Kopie deiner Dateien. Ändert sich ein Dokument (ein Vertrag bekommt eine neue Klausel, eine Spezifikation wird überarbeitet), musst du es neu einbetten. Vergisst du es, antwortet das Modell selbstbewusst aus der veralteten Version. Der Index ist eine zweite Wahrheitsquelle, die du nun synchron halten musst.
• Neu-Einbetten ist wiederkehrende Arbeit. Wechselst du das Embedding-Modell, änderst die Chunk-Einstellungen oder aktualisierst die App, müssen deine vorhandenen Vektoren womöglich neu aufgebaut werden. Der Aufwand ist nicht einmalig; er kehrt jedes Mal wieder, wenn sich die Eingaben bewegen.
• Retrieval ist konstruktionsbedingt unscharf. Die Nächste-Nachbarn-Suche liefert das semantisch Ähnliche: hervorragend für „finde mir irgendetwas zu X" und schwach für „wie lautet die exakte Zahl in Zeile 12". Schafft es der richtige Abschnitt nicht in die Top-k, sieht ihn das Modell nie, und du erfährst selten, dass er übersehen wurde.

Nichts davon macht AnythingLLM schlecht. Es ist der inhärente Preis des Ansatzes aus Embeddings plus Vektordatenbank. Über diesen Kompromiss haben wir ausführlicher in RAG ohne Vektordatenbank geschrieben.

Wie pdf2okf es anders angeht

pdf2okf geht von einer anderen Prämisse aus: Halte das Wissen als lesbaren Text und überspringe die Vektorschicht ganz.

Es wandelt jedes PDF in ein OKF-kompatibles Wissens-Bundle um: strukturierte Markdown-Konzeptdateien gemäß Googles Open Knowledge Format (Googles offener Standard; pdf2okf ist damit kompatibel, hat ihn aber nicht erfunden). Extrahiert werden sowohl die Konzepte als auch die Abbildungen aus dem PDF. Es gibt keinen Embedding-Schritt und keinen Index zu hosten: Stattdessen durchsucht ein Agent die Markdown-Konzeptdateien direkt per grep. Weil nichts Abgeleitetes synchron gehalten werden muss, ersetzt du bei einer Dokumentänderung einfach die Datei: kein Neu-Einbetten, keine veralteten Vektoren, nichts neu aufzubauen. Der Unterschied zwischen OKF und einer Vektordatenbank ist der Kern davon.

Das ändert in der Praxis einiges:

• Der Workspace ist portabel. Ein OKFZ-Bundle sind einfach Dateien. Du baust es einmal, versionierst es in Git, verschiebst es zwischen Maschinen oder gibst es einem Kollegen, ohne separaten Index nebenher, weil es keinen gibt.
• Antworten können deterministisch und belegt sein. Braucht eine Frage eine exakte Zahl, zählt Code sie und das Modell meldet das Ergebnis, statt zu hoffen, dass der richtige Abschnitt aus einer Top-k-Suche auftaucht. Jede Antwort verweist auf ihre Quelle und ist damit prüfbar.
• Es läuft dort, wo deine Daten sind. Alles funktioniert als On-Device-KI über ein lokales Modell oder per eigenem Schlüssel (BYOK), wenn du lieber eine API ansprichst, die du kontrollierst. Nichts muss deine Maschine verlassen.

Wenn dir vor allem der Kein-Upload-Aspekt wichtig ist, findest du dieselbe Logik auf Consumer-Tools angewandt in der lokalen ChatPDF-Alternative.

Wann wofür entscheiden

Das ist kein Fall, in dem ein Tool alles gewinnt, und es wäre unredlich, das zu behaupten.

Wähle AnythingLLM, wenn du einen großen, heterogenen Korpus hast (Tausende gemischte Dokumente, Web-Quellen, Codebasen) und über all das eine breite semantische Suche aus einer einzigen, ausgereiften Team-Oberfläche willst. Seine Mehrbenutzer-Steuerung, der Agent-Builder und die riesige Liste an Modell- und Vektordatenbank-Backends machen es zu einem hervorragenden All-in-One-Wissens-Hub. Für „frag alles über alles" ist Vektor-Retrieval genau das richtige Werkzeug.

Wähle pdf2okf, wenn deine Dokumente abgegrenzt und strukturiert sind und die Antworten exakt, belegt und portabel sein müssen: Verträge, Geschäftsberichte, technische Spezifikationen, regulatorische PDFs. Wenn eine falsche Zahl schlimmer ist als keine Antwort, schlägt deterministisches Zählen das unscharfe Retrieval, und ein portables Bundle ohne zu pflegenden Index schlägt einen Vektorspeicher, den du synchron halten musst.

Beide können deine Daten auf eigener Hardware behalten. Die eigentliche Frage ist, was das Wissen sein soll: ein durchsuchbarer Vektorindex oder ein portabler, prüfbarer Satz von Dateien. pdf2okf ist in der privaten Build-Phase, also trag dich in die Warteliste ein, wenn die zweite Beschreibung zu deinen Dokumenten passt.