Oft nicht. Für einen Ordner mit Verträgen, Berichten oder E‑Mails findet ein KI‑Agent mit einem Volltext‑Suchwerkzeug die richtigen Dateien, liest nur die passenden Passagen und zitiert sie, und der Index läuft lokal ohne Einbettungsmodell und ohne Vektor‑Store. GroupDocs.Search.Mcp stellt Claude Desktop, Claude Code, Cursor oder Copilot dieses Werkzeug in einem Docker‑Befehl zur Verfügung:

Indexiere den Vertragsordner, dann sag mir, welche Verträge eine Kündigungsstrafe erwähnen und zitiere die Klausel.

Die schrittweise Version mit Konfiguration und Fehlersuche befindet sich in der Dokumentation: Wie man Dokumente mit KI‑Agenten mithilfe von MCP durchsucht.

Warum greifen alle zuerst zu Einbettungen?

Weil „retrieval‑augmented generation“ als Rezept aufkam: Dokumente in Stücke aufteilen, jedes Stück einbetten, die Vektoren speichern, die Frage einbetten, die nächsten Stücke nehmen und in die Eingabe einfügen. Es funktioniert, und für Fragen, die nichts mit den Dokumenten zu tun haben, ist es das richtige Werkzeug. Aber es ist eine Pipeline mit einem aufzurufenden Einbettungsmodell, einem Store, der betrieben werden muss, einer anzupassenden Chunk‑Aufteilung und einem erneuten Einbettungs‑Job jedes Mal, wenn sich die Dokumente ändern. Für „welche meiner 300 Verträge eine Kündigungsstrafe erwähnen“ liefert diese Maschine eine Antwort, die ein Suchindex direkt beantworten kann.

Die Evidenz hat die Intuition eingeholt. Eine im späten Jahr 2025 auf arXiv veröffentlichte Studie (Keyword search is all you need) gab einem Agenten nichts als Stichwort‑ und Regex‑Suche über einen Ordner und verglich ihn mit einer Standard‑RAG‑Pipeline: über 90 % der RAG‑Ergebnisse, ohne Vektor‑Datenbank, und besser geeignet für Sammlungen, die sich häufig ändern. Coding‑Agenten hatten das Muster bereits in der Praxis gezeigt: Sie suchen mit grep, verfeinern und suchen erneut.

Was macht der Agent stattdessen?

Drei Aufrufe. GroupDocs.Search.Mcp stellt acht Werkzeuge bereit; die Schleife benötigt drei davon:

user              agent                         Search MCP server
 |  "Which contracts mention a termination penalty?"           |
 |---------------->|                                           |
 |                 |-- add_to_index ------------------------->|  reads the
 |                 |   {"documentsPath":"contracts",           |  files once,
 |                 |    "indexName":"contracts"}               |  stores text
 |                 |<- "5 document(s) added, 5 in the index" --|
 |                 |-- search ------------------------------->|
 |                 |   {"query":"termination AND penalty"}     |
 |                 |<- {"documentsFound":3, "documents":[ ... |  which files
 |                 |-- get_text_fragments ------------------->|
 |                 |   {"query":"\"termination penalty\""}     |
 |                 |<- === contracts/acme-...-agreement.pdf ===|  the passages
 |<- "Two contracts carry one: Acme (3 monthly fees, 12.3),    |
 |    Globex (50% of the remaining fees). Initech excludes it."|

add_to_index liest die Dateien einmal und speichert den Text in einem benannten Index auf der Festplatte. search gibt die passenden Dateien als JSON mit Auftretens‑Zahlen zurück. get_text_fragments liefert jede Übereinstimmung mit ein paar Wörtern Kontext, sodass der Agent die Klausel zitiert, anstatt den gesamten Vertrag zu laden.

Hier ist, was der Server in unserem Test tatsächlich zurückgab, gegen fünf synthetische Verträge:

-> search {"query":"termination AND penalty","indexName":"contracts"}
<- documentsFound 3: acme-master-services-agreement.pdf,
   globex-consulting-agreement.docx, initech-nda.docx

-> get_text_fragments {"query":"\"termination penalty\"",...}
<- === contracts/acme-master-services-agreement.pdf (1 occurrence(s)) ===
     …a termination penalty of three monthly fees applies, payable
     within 30…
   === contracts/globex-consulting-agreement.docx (1 occurrence(s)) ===
     …Early termination penalty: the Client pays 50 percent of the fees…

Beachte den dritten Vertrag. Das Initech‑NDA stimmte mit termination AND penalty überein, weil es sagt „there is no fee and no penalty associated with termination“. Die Passage ist das, was einen Treffer von einer Erwähnung unterscheidet, und ein Agent, der die Passagen liest, sagt das. Das ist Grounding: jede Behauptung in der Antwort verweist auf eine Datei und einen Satz, den man öffnen kann.

Wo hat jeder Ansatz Vorteile?

Einbettungs‑Pipeline                       Agentische Volltextsuche
-------------------------------------    -------------------------------------
aufteilen, einbetten, in einem Vektor‑Store speichern    add_to_index: ein lokaler Volltext‑Index
Frage einbetten, Top‑k‑Stücke nehmen    agent searches, refines, searches again
Stücke in die Eingabe einfügen         get_text_fragments: zitierte Passagen
erneut einbetten, wenn Dokumente sich ändern    update_index liest Änderungen erneut ein
benötigt ein Einbettungsmodell und einen Store    keine Modellaufrufe, kein Netzwerk zur Laufzeit
trifft Bedeutung; Ranking ist undurchsichtig    trifft Wörter; jeder Treffer ist erklärbar

Volltextsuche verliert, wenn Frage und Dokument keine gemeinsamen Wörter haben: „which contracts are risky for us?“ hat kein Stichwort. Sie gewinnt, wenn der Wortschatz geteilt wird, was die meisten Fragen beschreibt, die Menschen zu ihren eigenen Dokumenten stellen: ein Klauselname, ein Produkt, ein Kunde, eine Rechnungsnummer, ein Datumsbereich. Wenn eine Abfrage nichts trifft, versucht der Agent renewal OR renews oder eine unscharfe Übereinstimmung, wie es ein Mensch tun würde. Der Server hilft: eine nicht zitierte Zwei‑Wort‑Abfrage trifft nichts in GroupDocs.Search, und das leere Ergebnis enthält einen hint, der dem Agenten sagt, die Phrase zu zitieren.

Welches Werkzeug für welche Frage?

Der Benutzer fragt Der Agent ruft auf
“Diesen Ordner indexieren” add_to_index
“Welche Dateien erwähnen X?” search
“Was sagt es über X?” get_text_fragments
“Dateien geändert, aktualisieren” update_index
“Den Entwurfsordner vergessen” remove_from_index
“Was ist im Index?” get_index_info
“Einen separaten Index starten” create_index
“Warum nur 10 Ergebnisse?” get_license_status

Der Index versteht 82 Formate, darunter PDF, Office, OpenDocument, HTML und E‑Mail‑Archive (PST, OST, MSG, EML) mit deren Anhängen.

Wie führt man es aus?

claude mcp add groupdocs-search -- docker run --rm -i \
  -v /path/to/documents:/data ghcr.io/groupdocs-search/search-net-mcp:latest

Cursor, Claude Desktop, VS Code mit GitHub Copilot und die anderen Clients verwenden denselben Container in ihrer eigenen Konfigurationsdatei: In KI‑Clients registrieren. Unter Linux füge --user "$(id -u):$(id -g)" hinzu, damit der Container seinen Index in deinen Ordner schreiben kann. Der Server läuft mit der GroupDocs.Search‑Engine 26.10, deren neues Indexformat die Indizes kleiner macht und den Speicherverbrauch etwa halbiert (release notes).

Ehrliche Grenzen

  • Im Evaluierungsmodus enthält ein Index höchstens 100 Dokumente und eine Suche liefert höchstens 10 Ergebnisse; jede Antwort weist darauf hin. Rufe zuerst get_license_status auf.
  • Es ist Volltextsuche, keine semantische Suche: Sie stimmt Wörter, nicht Bedeutungen, ab.
  • Kein OCR: gescannte PDFs ohne Textebene werden nur nach ihren Dateieigenschaften indexiert.
  • Es wird nur als Docker‑Image bereitgestellt (das gepackte Werkzeug überschreitet das Größenlimit von NuGet).

Häufig gestellte Fragen

Kann Claude meine lokalen Dokumente durchsuchen, ohne sie hochzuladen?
Ja. Der Server läuft in einem Container auf Ihrem Rechner und liest den von Ihnen gemounteten Ordner; nur die Passagen, die der Agent zitiert, erreichen das Modell.

Ist das RAG?
Es ist retrieval‑augmented, aber agentisch: Das Modell entscheidet, was gesucht wird und wann genug gefunden ist, wobei ein Volltext‑Index anstelle von Einbettungen verwendet wird.

Was passiert, wenn sich meine Dokumente ändern?
Bitten Sie den Agenten, zu aktualisieren. update_index liest nur die geänderten, hinzugefügten und gelöschten Dateien erneut ein.

Weiterführende Informationen