Graphify, OKF und RAG: Welches Kontextlayer benötigt Ihre Codebasis?
Die Benchmarks zeigen, dass Graphify in Bezug auf die Genauigkeit mit vector RAG gleichzieht. Hier wird erklärt, wie Graphify, Googles OKF und vector RAG zusammenpassen, zusammen mit Auslösern für Misserfolge und einer Entscheidungsmatrix.
Die eigene Benchmark-Datei von Graphify enthält ein Ergebnis, das in der Hype um das Projekt oft übersehen wird. Was die Genauigkeit bei der direkten Fragebeantwortung angeht, ist sie auf dem Niveau von dense vector RAG, bei der Erinnerungsfähigkeit hingegen leicht hinterher. Dennoch wird es in Entwicklerblogs als „RAG-Killer“ bezeichnet, und bereits im selben Monat integrieren Unternehmensteams es zusammen mit Googles Open Knowledge Format (OKF) in ihre KI-Programmieragenten. Warum?
Weil die verbreitete Darstellung falsch ist. Graphify und OKF konkurrieren nicht darum, RAG zu ersetzen. Beide sind spezialisierte Schichten – eine strukturell und eine narrativ –, die neben einem Vektorindex liegen, und jede von ihnen ist nur dann sinnvoll, wenn es in Ihrem System bestimmte Fehlermuster gibt. Wenn man sie als Ersatz für RAG betrachtet, verschwendet man Entwicklungsaufwand damit, Wissensgraphen und sorgfältig zusammengestellte Markdown-Pakete für Probleme zu pflegen, die man gar nicht hat.
Im Folgenden wird erläutert, welche Funktion jede Schicht hat, warum der eigentliche Vorteil von Graphify die Eingabekosten und nicht eine bessere Suchleistung sind, sowie eine Entscheidungsmatrix für Codebasen im Jahr 2026.
Was die Benchmark-Datei tatsächlich sagt
Öffnen Sie BENCHMARKS.md im Graphify-Repository – die dort aufgeführten Zahlen beinhalten nicht alle Testergebnisse.
Nehmen wir zunächst LongMemEval-S mit 50 Beispielen. Der Graph-expand-Modus von Graphify erreicht eine QA-Genauigkeit von 76 % und eine Recall-Wertung von 0,844 bei 10 Abfragen. Eine dichte Vektor-RAG-Baseline mit demselben Modell (Kimi K2.6), demselben BGE-m3-Embedder und dem gleichen Tokenbudget erreicht ebenfalls 76 % Genauigkeit, allerdings 0,848 Recall bei 10 Abfragen. Somit haben Wissensgraphen hier keinen Vorteil: Die Genauigkeit ist gleich, die Recall-Wertung etwas niedriger. Noch schlechter für die Verkaufspräsentation: Der Anbieter selbst hat das Datenset bereitgestellt und es blind validiert (90,6 % Übereinstimmung, Cohen’s Kappa 0,81), sodass kein externer Prüfer einen schlechten Testlauf ausgewählt haben kann.
Auf LOCOMO (n=300) ist das Bild ähnlich, wobei der entscheidende Faktor nun die Kosten für die Dateneingabe ist.
Graphify erreicht eine Genauigkeit von 45,3 % und kostet etwa 1,40 US-Dollar zur Verarbeitung des Datensatzes. Supermemory weist eine höhere Genauigkeit von 49,7 % auf, kostet aber 15,67 US-Dollar – das sind fast 11 Mal so viele Kosten. Somit gewinnt auch Graphify hier nicht im Wettbewerb um die Genauigkeit. Es hat Vorteile bei den Kosten und der Effizienz.
Auf beiden öffentlichen Benchmarks gilt dieses Muster weiterhin. Graphify übertrifft keine gut abgestimmte Vektor-RAG-Pipeline in Bezug auf die Suchleistung. Er erreicht dieselbe Genauigkeit wie Vektor-RAG, ist bei der Implementierung jedoch deutlich günstiger als andere Speichersysteme. Zwei Eigenschaften erklären seinen Vorteil:
- Günstige Dateneingabe, da die AST-Parsing-Verarbeitung überhaupt keine LLM-API-Aufrufe erfordert.
- Strukturelle Extraktion ohne Risiko von Halluzinationen, da die deterministische Tree-sitter-Parsing-Methodik genaue Code-Beziehungen (Aufrufe, Importe, Klassenerbe) ohne Beteiligung eines Modells ermittelt.
Für alle, die glauben, Graphify ersetze Vektordatenbanken, verändert dies die Fragestellung. Es geht nicht darum, welches Tool gewinnt, sondern um die Frage, welche Schicht welchen Kontext verwaltet und welche Fehlermöglichkeiten in Ihrer Agentenarchitektur noch ungelöst sind.
Drei Schichten statt drei Konkurrenten
Gute Architekturentscheidungen erfordern eine Trennung zwischen technischer Realität und Marketingbegriffen. Moderne Agentenkonfigurationen stützen sich auf drei unterschiedliche Kontextschichten.
┌─────────────────────────────────────────────────────────────────┐
│ AI CODING AGENT CONTEXT │
└────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ VECTOR RAG │ │ GRAPHIFY │ │ GOOGLE OKF │
│ (Unstructured) │ │ (Structure) │ │ (Narrative) │
├───────────────────┤ ├───────────────────┤ ├───────────────────┤
│ • Docs & Tickets │ │ • AST Call Graphs │ │ • Architecture │
│ • Slack Threads │ │ • Class Hierarchies│ │ • Data Schemas │
│ • Long Tail Text │ │ • Imports/Exports │ │ • Playbooks & Run │
└───────────────────┘ └───────────────────┘ └───────────────────┘
Vector RAG
Vector RAG teilt unstrukturierten Text in Token-Blöcke fester Größe auf (zum Beispiel 512 Token), embeddet sie in einen Vektorraum und gibt bei Abfragen die k-nächsten Nachbarn zurück. Es ist schnell, günstig und eignet sich gut für unabhängige, flache Dokumentationen.
Sein grundlegender Mangel ist strukturell: er vereinfacht Hierarchien. Eine Analyse von Prism Labs aus dem Jahr 2026 formuliert es wie folgt: Wenn Ursache und Wirkung nicht im selben 512-Token-Blöck vorhanden sind, hat das System keine Ahnung, dass sie miteinander verbunden sind. Bessere Embedding-Modelle können das nicht beheben, denn es liegt im Wesen der Textaufteilung in Blöcken.
Graphify
Graphify ist ein lokaler, deterministischer Engine. Er führt eine Tree-Sitter-AST-Parsing-Verarbeitung für mehr als 36 Programmiersprachen durch, darunter Python, TypeScript, Go, Rust, Java, C/C++, Swift, SQL sowie Terraform/HCL, extrahiert die Codeelemente und erstellt ein strukturelles Graph mit typisierten Kanten wie calls, imports, inherits und mixes_in.
Jede Kante trägt eine Beschriftung. EXTRACTED bedeutet, dass sie zuverlässig direkt aus dem AST gelesen wurde, während INFERRED anzeigt, dass sie aufgrund heuristischer Methoden mit geringerer Zuverlässigkeit erzeugt wurde. Darüber hinaus wendet Graphify die Leiden-Community-Detektion an, um natürliche Untersysteme voneinander zu trennen, und markiert „God Nodes“ – hochzentrale Dateien, die viele Module beeinflussen.
Durch Ausführung von /graphify . entstehen drei lokale Ergebnisse:
graph.htmlist eine interaktive Visualisierung des Graphen.GRAPH_REPORT.mdist eine schriftliche Übersicht der Subsysteme der Codebasis.graph.jsonist der maschinenlesbare, abfragbare Index.
Open Knowledge Format
Google Cloud kündigte OKF im Juni 2026 an. Es handelt sich dabei weder um einen Suchalgorithmus noch um einen Datenbankmotor. Es ist eine herstellers neutrale Markdown-Metadaten-Spezifikation. Ein Bundle ist ein Verzeichnis aus reinen UTF-8-Markdown-Dateien mit minimalem YAML-Frontmatter, wobei nur ein Feld, type, obligatorisch ist. Ein Header sieht so aus:
---
type: Architecture Concept
title: Payment Gateway Routing
description: Canonical sequence for multi-tenant payment provider dispatch.
tags: [billing, architecture]
---
Es gibt weder ein Schema-Registry noch eine aufwändige Laufzeitumgebung. Die Bundles sollen in Git gespeichert werden und mit gewöhnlichen Shell-Tools wie cat gelesen werden. Was OKF enthält, ist sorgfältig kuratierte institutionelle Memorie – von Menschen verfasst oder von Agenten erstellt –, nämlich die klare Erklärung dafür, warum Systeme so konstruiert werden, und nicht rohe Code-Symbole oder ungefilterte Chat-Protokolle.
Wie die Schichten die Arbeit aufteilen
Zusammen teilen sie die Arbeit auf: Graphify extrahiert, was der Code ist, OKF erfasst, was Ingenieure wissen, und vector RAG kümmert sich um den unstrukturierten Rest.
Von einem Tweet zu einem Repository mit 63.000 Sternen in 90 Tagen
Der Eifer, diese Tools anzunehmen, ergibt im Kontext des Zeitplans mehr Sinn, denn das gesamte Ökosystem entstand innerhalb eines einzigen 90-tägigen Zeitraums.
2026-04-01: Karpathy posts "LLM Wiki / Knowledge Compiler" concept on X
│
2026-04-03: Safi Shamsi launches Graphify on GitHub (YC S26)
│
2026-06-01: Graphify reaches 58.3K GitHub stars & 1.2M PyPI downloads
│
2026-06-12: Google Cloud releases Open Knowledge Format (OKF) spec
│
2026-07-01: Graphify ↔ OKF hybrid integration toolkit ships (71.5x token claim)
│
2026-07-05: Graphify hits ~78K stars; Level Up Coding scrutinizes "70x token" claims
Dieselbe Abfolge in Prosa:
- 1. April 2026: Andrej Karpathy teilt auf X ein Gedankenexperiment: Man platziert Forschungspapiere, Notizen zur Codebasis, Screenshote sowie Architekturdokumente in einem einzigen Ordner und durchsucht sie anschließend mithilfe einer KI, die versteht, wie sie miteinander verbunden sind, wobei LLMs als „Wissenskompilatoren“ fungieren.
- 3. April 2026: Safi Shamsi veröffentlicht Graphify auf GitHub und verwandelt diese Idee innerhalb von 48 Stunden in ein Projekt. Es wird Teil der S26-Gruppe von Y Combinator.
- 1. Juni 2026: Das Projekt erreicht 58.300 Sterne auf GitHub sowie 1,2 Millionen Downloads von PyPI.
- 12. Juni 2026: Google Cloud stellt OKF zusammen mit seiner offenen Spezifikation, Beispielpaketen (GA4 E-Commerce, Stack Overflow und Bitcoin) sowie einem Agenten vor, der Metadaten aus BigQuery extrahiert.
- 15. Juni 2026: Der Knowledge Catalog von Google Cloud verarbeitet nun OKF-Bundles nativ und leitet sie an Unternehmens-AI-Agenten weiter.
- 1. Juli 2026: Es erscheint ein Toolkit, das Graphify und OKF in beide Richtungen verbindet. Code-Graphen von Graphify werden über progressive Disclosure als OKF-Markdown-Kataloge exportiert, wodurch angeblich bis zu 71,5-mal mehr Einsparungen bei den benötigten Query-Tokens erzielt werden können im Vergleich zum Lesen von Rohdateien.
- 5. Juli 2026: Graphify nähert sich 78.000 Sternen an, und technische Publikationen wie Level Up Coding beginnen, die in den Schlagzeilen behauptete Effizienz in Frage zu stellen.
Andrus, der zu dieser Zeit der Kritik schrieb, stellte fest, dass eine Einsparung von fast 70-fach von einer Eigenschaft eines Projekts abhängt, die in fast keinen Nachveröffentlichungen offen erwähnt wird. Diese Eigenschaft ist die Korpustopologie. Der Test hinter der 70-fachen Zahl nutzte eine bestimmte Sammlung aus 52 Dateien (Karpathys öffentliche Repositorien, 5 Forschungspapiere, 4 Diagramme); bei Unternehmenscodebasen mit flachen Paketstrukturen oder riesigen Monorepos variieren die Token-Einsparungen stark.
Welche Fehler rechtfertigen den Einsatz eines der Tools?
Hype ist keine architektonische Notwendigkeit, genauso wenig wie eine vage Unzufriedenheit mit der aktuellen RAG-Einrichtung. Neue Infrastrukturen benötigen einen konkreten, beobachteten Fehlermodus als Grundlage.
Zuerst eine Realitätsprüfung
Umfragen in der Branche zeigen, dass der Anteil der Unternehmens-RAG-Einsatzmodelle, die innerhalb eines Jahres unzureichende Ergebnisse liefern oder ganz versagen, bei 72 % liegt. Die meisten dieser Fehlschläge resultieren aus mangelhafter Aufteilung der Daten in Teile, veralteten Vektorindizes oder ungeeigneten Embedding-Modellen – nicht aus dem Fehlen einer Graph-Datenbank. Ein Wissensgraph, der an ein defektes Abrufsystem angehängt wird, führt zu demselben defekten System zusätzlich zu weiteren Aufwänden bei der Verarbeitung.
┌─────────────────────────────────────────┐
│ Does your AI coding agent underperform? │
└────────────────────┬────────────────────┘
│
┌──────────────────┴──────────────────┐
▼ ▼
[ Sifting multi-file code ] [ Loss of tribal context ]
[ dependencies & calls ] [ across team silos ]
│ │
▼ ▼
Multi-Hop Reasoning Failure Knowledge Sprawl Failure
│ │
▼ ▼
TRIGGER: Add Graphify TRIGGER: Add Google OKF
(AST Structural Graph) (Curated Narrative Spec)
Auslöser eins: Fehlschläge beim mehrstufigen Schlussfolgern (Graphify hinzufügen)
Dies tritt auf, wenn eine Antwort davon abhängt, Fakten aus mehreren Dateien miteinander zu verknüpfen, die nie einen gemeinsamen Textabschnitt teilen.
Ein typisches Symptom: Das System kann Fragen wie „Was bricht in der API-Schicht, wenn sich das Schema in db/migrations/04_users.sql ändert?“ nicht beantworten.
Weil vectorbasierte RAG-Methoden jeden Textblock unabhängig einbetten, haben sie keine Kenntnis von Fremdschlüsselverweisen, Implementierungen von Schnittstellen oder Aufrufen zwischen Dateien. Bessere Anfragen oder größere Kontextfenster helfen nicht, da diese Beziehungen niemals in den Vektorraum übertragen werden.
Auslöser zwei: Verstreute, nicht dokumentierte Fachwissen (OKF hinzufügen)
Dies tritt auf, wenn wichtiger institutioneller Kontext über Slack-Kanäle, veraltete Wiki-Seiten sowie ungeschriebenes Wissen der Entwickler verteilt ist.
Das Symptom hier ist ein Agent, der syntaktisch gültigen Code erstellt, der interne architektonische Richtlinien verletzt, veraltete interne APIs aufruft oder domänenspezifische Geschäftsregeln ignoriert.
Graphify kann nicht helfen, da AST-Parser nur Quellcode lesen und keine Geschäftsabsichten extrahieren können. OKF schließt diese Lücke mit einer leichten, git-basierten Markdown-Struktur, in der Ingenieure stabile Systemkonventionen festhalten, die von Agenten zuverlässig interpretiert werden können.
Forschungen zum RAG im Rechtsbereich haben ergeben, dass herkömmliche Suchwerkzeuge bei 17 % bis 33 % der komplexen Abfragen Fehlinformationen liefern, da allein die Suche keine Logik abbilden kann, die über Dokumente hinwegreicht. Atlans Empfehlungen fassen die sinnvolle Reihenfolge zusammen: Zuerst RAG, und erst wenn die Tiefe zum Engpass wird, ein Graph.
Was jedes Tool kostet, wenn es versagt
Jede hinzugefügte Schicht bringt ihre eigenen Ausfallmöglichkeiten mit sich. Beide Projekte sind noch jung, weshalb ihre Betriebsrisiken vor der Produktivnutzung Beachtung verdienen.
Wo Graphify nachlässt
- Veraltete Snapshots. Der Graph-Index wird einmal erstellt und bleibt danach statisch. Er wird nicht aktualisiert, wenn Entwickler Dateien ändern, wodurch er ohne einen Git-pre-commit-Hook oder einen CI/CD-Schritt von dem Code abweicht. Ein veralteter Strukturgraph ist schlimmer als keiner, da der Agent zu falschen Antworten gelangt.
- Lärmende Communities in Legacy-Monolithen. In großen Java- oder C++-Anwendungen gruppiert die Leiden-Erkennung oft unverwandte Module zusammen, nur weil sie alle gemeinsame Infrastrukturen wie Logging- oder Telemetrie-Singletons verwenden.
- Halluzinationen bei der semantischen Verfeinerung. Der Kern-Code-Verarbeitungsschritt ist deterministisch, doch der optionale semantische Schritt für Dokumente, PDFs und Bilder ruft weiterhin ein LLM auf. Dadurch können aus nicht-kodischen Quellen extrahierte Beziehungen falsch sein.
- Nicht überprüfte Behauptungen. Laut dem Softwarearchitekten Saurabh Sharma hat niemand außerhalb des Projekts einen Vergleich der Graphify-Graphabfragen mit Rohdateien oder eine RAG-Baseline auf einem gemeinsamen Testdatensatz nachgestellt. Herstellernummern sollten am besten als grobe Orientierung verstanden werden.
Wo OKF nachlässt
- Keine Durchsetzung oder Validierung. Das Format lässt bewusst Schema-Register sowie strenge Regeln aus, wodurch die Qualität eines Pakets vollständig von der Person oder dem System abhängt, das die Dateien erstellt.
- Leises Verfallen. Der Kernvertrag verlangt von den Agenten, unbekannte Metadatentypen sowie gebrochene Links hinzunehmen. Das beschleunigt die Einführung, ermöglicht aber auch, dass Pakete zu unverknüpften, veralteten Dateien werden, ohne dass Fehler auftreten.
- Wartungsaufwand. Markdown-Dokumente erfordern kontinuierliche Pflege. Wenn die Entwicklungsworkflows keine Aktualisierungen von OKF zusammen mit Codeänderungen vorsehen, veraltet die narrative Schicht schnell.
Der kombinierte Pipeline in der Praxis
Bei komplexen Unternehmenscodebasen wählt die beste Einrichtung für 2026 kein einzelnes Tool. Stattdessen werden sie zu einem mehrstufigen Pipeline-Kontext zusammengefügt.
┌──────────────────────────────────────────────────────────────────┐
│ USER / AGENT QUERY: "What breaks if I modify UserService.py?" │
└─────────────────────────────────┬────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 1: OKF Progressive Disclosure Catalog │
│ Read high-level module narrative & owner specs (~2K tokens) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Targeted node identified)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 2: Graphify Structural Graph Query │
│ Traverses AST edges: calls, imports, inherits (Zero-LLM cost) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Unstructured edge cases)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 3: Vector RAG / Sparse Search │
│ Search raw Slack incident logs, GitHub issues, & PR comments │
└──────────────────────────────────────────────────────────────────┘
Schritt eins: Erstellung der strukturellen Artefakte von Graphify
Installieren Sie Graphify in einer isolierten Umgebung und führen Sie anschließend den Analyzer auf der Arbeitsumgebung aus.
# Install Graphify via uv
uv tool install graphifyy
# Register the skill with your local agent environment (Claude Code, Cursor, Codex, Gemini CLI)
graphify install
# Execute AST graph compilation inside your repository root
/graphify .
# Generated Local Artifacts:
# graph.html --> Interactive visual network representation
# GRAPH_REPORT.md --> Natural language summary of communities & god nodes
# graph.json --> Queryable AST relational graph database
Sobald dies abgeschlossen ist, kann der lokale Strukturindex direkt abgefragt werden, um Beziehungswege zu überprüfen.
# Query dependency paths between components
graphify path "UserService" "DatabasePool"
# Trace architectural blast radius before refactoring
graphify query "What components depend on AuthTokenValidator?"
Schritt zwei: Schreiben Sie sorgfältig ausgewählte Konzepte als OKF
Exportieren Sie das, was die strukturelle Analyse ergeben hat, als konformes OKF-Konzeptpaket unter .well-known/okf/ oder docs/knowledge/. Eine minimale Konzeptdatei verwendet gewöhnliche Markdown-Links, wobei diese Links direkt auf Kanten des Wissensgraphen verweisen.
---
type: Database Table Context
title: orders_fact
description: Canonical order transaction table joining billing and fulfillment streams.
resource: bigquery://production-data.commerce.orders_fact
tags: [finance, core-model]
timestamp: 2026-06-20T14:00:00Z
---
# Business Domain Summary
The `orders_fact` table serves as the primary source of truth for revenue calculations.
Modifications to columns must align with the [Customer Profile Spec](./customer_profile.md).
# Schema & Join Constraints
| Column Name | Data Type | Structural Constraint |
|---|---|---|
| `order_id` | STRING | Primary Key; joins with [billing_events](./billing_events.md) |
| `customer_id` | STRING | Foreign Key; see [customers](./customers.md) |
| `status` | STRING | Enum: `pending`, `completed`, `refunded` |
# Related Runbooks
- Incident Protocol: [/runbooks/billing-reconciliation.md](/runbooks/billing-reconciliation.md)
Der Such- und Kontextingenieur Kopp betont, dass die Verlinkungsstruktur von OKF perfekt zu GraphRAG passt, da eine Verbindung von orders_fact.md zu customers.md bereits eine Kante in einem Wissensgraphen darstellt.
Beweise aus ERPNext
Der kombinierte Ansatz wurde auf ERPNext getestet, einer Open-Source-Unternehmens-Codebasis mit über einer Million Zeilen in Python und JavaScript.
Bei den Bewertungen wurde Claude Opus 4.8 verwendet, wobei pro Aufgabe maximal 14 Schritte zulässig waren:
- Ein Basiskodierungsagent, der Vector RAG und grep nutzte, erreichte eine 70,8%-ige Abdeckung der Schlüsselinformationen.
- Der hybride Pipeline aus Graphify und OKF erreichte eine 82,0%-ige Abdeckung der Schlüsselinformationen und wies im Durchschnitt etwa 140.000 Tokens pro Abfragesitzung auf.
Ein Zuwachs von 11,2 Punkten bei einer Codebasis dieser Größe bedeutet deutlich weniger Ausführungsfehler der Agenten. Das sagt mehr über die Produktivität aus als Zahlen zur künstlichen Verringerung von Tokens.
Auswahl nach Codebasistyp
Erkennen Sie in der Matrix Ihre Codebasenumgebung sowie deren Hauptversagensmuster, um eine geeignete Architektur auszuwählen.
Kurzfassung
Graphify ist bei deterministischer struktureller Analyse ohne Kosten für LLM-APIs am stärksten. OKF bietet ein portables, git-freundliches Standardformat für Kontexte, die sowohl von Menschen als auch von Agenten erstellt werden. Vector RAG bleibt die effektivste Option für die Suche in unstrukturiertem Text. Das Stapeln von Schichten ohne klares Versagensmuster erhöht die Komplexität und verbessert die Leistung der Agenten nicht.
Definieren Sie zunächst das Problem
Bevor Graphify oder OKF in einen Entwicklungsprozess aufgenommen werden, muss entschieden werden, welches der drei Probleme tatsächlich besteht: veralteter Codekontext, Fehler bei mehrstufigen Abhängigkeiten oder fragmentiertes institutionelles Wissen.
Sowohl Tools sind nützliche Ergänzungen für einen modernen AI-Stack, und die Ergebnisse von ERPNext zeigen einen echten Wert bei komplexen Codebasen. Dennoch ist der Sprung von einem Tweet zu einem viralen Repository ein Grund für Strenge. Lesen Sie die Daten in BENCHMARKS.md direkt, testen Sie potenzielle Architekturen an Ihrem eigenen Code und erstellen Sie einen Kontextstack, der Ihren ingenieurtechnischen Anforderungen entspricht. Die Abgleichung Ihrer Einrichtung mit den Bedingungen für Monolithen, Microservices oder Monorepos in der Matrix ist ein guter Ausgangspunkt.
Verwandte Literatur
- Fortgeschrittener RAG auf Milvus: Hybrid-Suche, HyDE, Abfragen umschreiben und Neuranking — Erstellen Sie schrittweise einen Milvus-RAG-Pipeline: dichte und BM25-Vektoren, RRF-Hybridsuche, Metadatenfilter, Abfragen umschreiben, HyDE, Dekomposition sowie Neuranking mit Cross-Encoder.
- Ein nützliches lokales LLM in 30 Minuten: Programmieren, Dokumenten-FAQ und Sprachsteuerung — Erstellen Sie mit Ollama, Qwen3 und Whisper.cpp einen lokalen Programmierassistenten, ein Skript zur Suche in Notizen sowie einen Offline-Sprachmodus, zusammen mit den Regeln zur Speicherkapazität zur Auswahl der Modellgröße.