Grep, Sprachserver, Vektorsuche, Hybridindex: Was ein Flask-Vergleich des Herstellers belegt – und was nicht

Vier Such-Ansätze auf Flask 3.1.3 – verglichen vom Hersteller eines der Kandidaten

Wie finden Coding-Agenten Code am besten? Ein Entwickler ließ vier Ansätze auf demselben Repository gegeneinander antreten: ripgrep als reine Textsuche, Serena mit Language Servern hinter MCP, claude-context mit Vektorsuche und Semlith als lokaler Hybridindex. Veröffentlicht hat er den Vergleich auf dev.to. Testobjekt ist Flask 3.1.3, ein leichtgewichtiges WSGI-Framework der Pallets-Organisation und eines der verbreitetsten Python-Webframeworks.

Gemessen wurde laut Autor auf einem M1 MacBook Air mit 8 GB Arbeitsspeicher. Genannt sind die Versionen ripgrep 15.2.0, Serena 2.1.0, claude-context 0.1.15 (mit Milvus 3.0.3 und Ollama samt nomic-embed-text) sowie Semlith 0.50.0.

Der Autor entwickelt Semlith selbst. Er legt diesen Interessenkonflikt offen, bittet, seine Voreingenommenheit zu berücksichtigen, und kündigt an, auch Fragen zu zeigen, die sein Tool falsch beantwortet hat. Genau dieser Teil fehlt jedoch. Der vorliegende Auszug bricht ab. Treffergenauigkeit, Token-Verbrauch, Laufzeit und die angekündigten Fehlschläge sind nicht enthalten. Belegt sind allein Einrichtung, Setup-Zeiten und die Tool-Beschreibungen. Außerdem gilt: Die Beschreibung der drei Fremdtools stammt vom Semlith-Autor, nicht aus deren Dokumentation.

30,9 Sekunden gegen 21 Minuten: Was das Setup auf Flask kostet

Die Setup-Werte des Autors liegen um Größenordnungen auseinander. ripgrep braucht keine Vorbereitung. Serena indexiert Flask in 30,9 Sekunden, Semlith in 84,3 Sekunden. Für claude-context nennt der Autor rund 21 Minuten. Die Berechnung lief auf der CPU in Docker.

Die Spanne erklärt sich aus der Architektur. ripgrep durchsucht Text ohne Index, es gibt also nichts vorzubereiten. Serena nutzt Language Server hinter MCP. Sie arbeiten symbolbasiert, und Serena kann Code auch bearbeiten. claude-context erzeugt Embeddings und legt sie in Milvus ab. Laut Autor setzt das Docker, Milvus, Ollama und npx voraus. Das Einbetten sämtlicher Code-Abschnitte ohne GPU dürfte den Zeitaufwand treiben. Die Tabelle des Autors nennt die Ursache jedoch nicht ausdrücklich. Semlith baut einen lokalen Index aus Embeddings, Keyword-Suche und Code-Graph. Laut Autor ist es nur lesend und läuft als einzelne Binärdatei.

Die Zahlen sind Messwerte eines Tool-Herstellers auf einem einzelnen, leistungsschwachen Rechner. Eine unabhängige Nachmessung liegt nicht vor. Sie zeigen die Größenordnung des Aufwands, sagen aber nichts über die Qualität der Treffer.

Was Semlith selbst über sich sagt: lokal, kostenlos, 76,8 % Top-10-Treffer

Die Dokumentation beschreibt Semlith als lokale Suche für KI-Agenten. Jede Anfrage läuft gegen einen Vektor- und einen Keyword-Index, beide Rankings werden fusioniert. Hinzu kommen ein Code-Graph aus Definitionen, Aufrufen, Imports und Re-Exports sowie ein Watcher, der gespeicherte Dateien neu einbettet. Der MCP-Server bietet in der Standardansicht acht Tools, insgesamt sechzehn. Nach Herstellerangaben braucht das Tool keine API-Keys und im Abfragebetrieb kein Netzwerk, sofern man sich nicht bei Semlith Cloud anmeldet. Mit --airgap werden ausgehende Verbindungen verweigert. Das Webportal bindet ausschließlich an 127.0.0.1. Ein Flag zum Ändern gibt es nicht.

Die lokale Variante ist kostenlos. Semlith Cloud ist die kostenpflichtige gehostete Version mit gemeinsamem Index für mehrere Rechner, Cloud-Sessions und CI.

Als Leistungsbeleg nennt der Hersteller eine Messung auf SWE-bench Verified, nur für das Retrieval. Bei 76,8 % von 500 Issues liege die vom Fix bearbeitete Datei in den Top 10 von Semlith. Bei „grep then read“ seien es 47,0 %. Es handelt sich um eine Herstellermessung, nicht um eine unabhängige.

Semlith wurde zudem für eine Claude-Code-Ressourcenliste eingereicht. Die automatische Validierung meldete, alle Prüfungen seien bestanden. Sie bestätigt jedoch nur formale Kriterien. Ein Review durch Maintainer steht laut Einreichung noch aus.

Unabhängige Studien sehen Vorteile für Index und semantische Suche – mit Einschränkungen

Eine arXiv-Studie untersucht repository-weite Code-Fragen auf dem Benchmark SWE-QA. Sie stellt semantische Suche über einen vorab gebauten Vektorindex der „Deep Agentic Search“ gegenüber. Dabei delegiert ein Planer die Erkundung per grep an einen Subagenten in isolierter Kontextumgebung. Die semantische Suche beantwortete 65,2 % der Fragen richtig, die agentische Suche 46,2 %. Jede richtige Antwort entstand zu weniger als der Hälfte der Kosten. Die Autoren werteten zudem die Fehlläufe aus: 41,8 % der Fehler der agentischen Suche traten bei der Übergabe zwischen Planer und Subagent auf. Das Design, das den Hauptagenten vor Kontextverschmutzung schützen soll, erzeugt also eine eigene Fehlerklasse.

Eine zweite arXiv-Studie testet einen strukturellen Codebase-Index in einer festen Coding-Agent-Harness mit Claude Opus 4.7, auf SWE-PolyBench Verified und SWE-bench Pro. Gegenüber derselben Harness ohne Index verbesserte der Index Lokalisierung und Lösungsrate, bei geringeren Kosten pro gelöster Aufgabe. Gegen einen agentischen Grep-Vergleich schnitt er dagegen nur ebenbürtig ab, nämlich nicht schlechter. Der Nutzen zeige sich vor allem bei Änderungen über mehrere Dateien.

„Nicht schlechter“ bedeutet nicht „deutlich besser“. Für Semlith heißt das: Der Vorsprung von 76,8 % gegenüber 47,0 % ist durch diese Studien nicht bestätigt. Sie messen andere Indizes, andere Benchmarks und andere Metriken, nämlich Resolve-Rate und Lokalisierung im Agentenlauf statt Top-10-Dateitreffer. „Grep then read“ ist außerdem nicht dasselbe wie ein iterierender agentischer Grep. Die Vergleichbarkeit ist daher gering.

Wenn grep gewinnt: LongMemEval und das Eingeständnis „nothing beats grep“

Eine Gegenposition liefert eine weitere Studie unter dem Titel „Is Grep All You Need?“. In Experiment 1 verglichen die Autoren grep und Vektorsuche auf einer Stichprobe von 116 Fragen aus LongMemEval. Sie nutzten eine eigene Harness namens Chronos sowie die herstellereigenen CLIs von Claude Code, Codex und Gemini CLI. Über Chronos und die CLIs hinweg erreichte grep im Allgemeinen höhere Genauigkeit als Vektorsuche.

Auch der Autor des Flask-Vergleichs räumt ein: Kennt der Agent den Bezeichner bereits, schlage nichts grep. Das ist die Wertung eines Entwicklers, der selbst ein Konkurrenzprodukt anbietet, kein Messergebnis.

Die Befunde widersprechen sich nicht direkt. LongMemEval prüft Gesprächsgedächtnis, SWE-QA und die Index-Studie betreffen Code-Repositories. Auch die Vergleichsanordnungen unterscheiden sich. Die SWE-QA-Studie stellt semantische Suche grep per Subagent gegenüber, nicht direktem grep im Hauptagenten. Gerade die Übergabe an den Subagenten verursachte dort die meisten Fehler. Hinzu kommen verschiedene Harnesses, Modelle und Metriken. Für die Flask-Fragen des Semlith-Autors liegen keine Vergleichszahlen vor, die sich mit diesen Studien abgleichen ließen.

Eigener A/B-Test statt Fremdzahlen: Was rag-bench misst

Für Teams, die Coding-Agenten einsetzen, folgt daraus vor allem eines: Fremdzahlen taugen als Hypothese, nicht als Entscheidungsgrundlage. Das Projekt rag-bench bietet dafür einen A/B-Benchmark. Er lässt Claude-Code-Sitzungen 105 Fragen zur Codebasis zweimal beantworten. Einmal stehen nur Grep, Glob und Read zur Verfügung, einmal zusätzlich ein Code-Intelligence-MCP-Server. Flask ist als Repository vorgesehen. Erfasst werden Genauigkeit, Tokens, Turns, Latenz und Kosten.

Genau diese Größen fehlen in den Herstellerangaben. Ein Smoke-Lauf mit wenigen Fragen verbraucht laut Projekt bereits echtes API- oder Abonnement-Kontingent, der volle Lauf entsprechend mehr. In die Abwägung gehört zudem der Einrichtungsaufwand. Wer wie bei claude-context rund 21 Minuten Indexierung auf einer CPU in Docker einplant, zahlt diese Zeit bei jedem größeren Repository und auf jedem neuen Rechner erneut.

Eine Empfehlung für ein bestimmtes Produkt lässt sich aus dem vorliegenden Material nicht ableiten. Ableitbar ist jedoch ein Verfahren, das sich am eigenen Repository selbst prüfen lässt.