Persistente Indizes gegenüber Extraktion: Architektur für einen YouTube-MCP-Server

Ein Entwickler hat detaillierte Architektur-Notizen zum Aufbau eines YouTube-MCP-Servers veröffentlicht, der persistente lokale Indizes implementiert – im Gegensatz zum gängigen "Extrahieren-und-Vergessen"-Ansatz, der bei über 40 existierenden Servern beobachtet wurde.

Architektur-Entscheidungen

• Dreistufiges Fallback für jedes Tool: Nutzt YouTube Data API → yt-dlp → Seitenextraktion. Jede Antwort enthält ein Herkunftsfeld ({sourceTier, fallbackDepth, partial, fetchedAt, sourceNotes}), um stille Verschlechterung zu verhindern. Quota-Erschöpfung auf Stufe 1 führt zu einer abgeschwächten Antwort mit klarer Herkunft statt zu einem Fehler.
• Persistenzmodell: SQLite + sqlite-vec für lokale Vektorspeicherung in einer einzigen Datei, ohne Docker oder externe Datenbank. Embeddings bleiben über Sitzungen hinweg erhalten, sodass Wissen akkumuliert – die zehnte Abfrage zu einem indizierten Playlist ist reichhaltiger und schneller als die erste.
• Embedding-Provider-Abstraktion: Nutzt Gemini text-embedding-004 (768d) bei vorhandenem Gemini-Schlüssel, mit Fallback auf all-MiniLM-L6-v2 (384d) vollständig offline via lokaler Inferenz. Beide werden durch dieselbe Abstraktion behandelt, was semantische Suche ohne API-Schlüssel bei reduzierter Qualität oder transparente Upgrades bei Hinzufügen eines Schlüssels ermöglicht.
• Visuelle Suche als separater Index: Drei unabhängige Ebenen: Apple Vision VNGenerateImageFeatureVectorRequest für pro-Frame-Feature-Ausdrucke zur Bild-zu-Bild-Ähnlichkeit, Gemini Vision für natürliche Sprach-Szenenbeschreibungen pro Keyframe und Gemini text-embedding-004 für 768d-Embeddings über OCR-Text + Beschreibungen für Text→visuelle Suche. Gibt tatsächliche Frame-Pfade auf der Festplatte + Zeitstempel + Übereinstimmungsbegründung zurück, wirklich getrennt vom Transkript-Pipeline.
• Token-Effizienz durch strikte Ausgabeschemata: Erreicht 75–87 % kleinere Antworten als rohe YouTube-API-Ausgabe durch Entfernen von Thumbnails, eTags und Lokalisierungs-Bloat sowie Nutzung normalisierter Engagement-Verhältnisse statt Rohzahlen.

Abwägungen und Herausforderungen

• Festplattennutzung wächst mit Persistenz: Gelöst mit TTL-Caches pro Tool-Kategorie, einem mediaStoreHealth-Diagnostik-Tool und Bereinigungs-Tools pro Sammlung.
• Visuelle Indizierung ist teuer: Aufgrund von Keyframe-Extraktion + Vision + OCR + Embeddings. Wurde pro Video opt-in statt automatisch während des Imports gemacht.
• Dreistufiges Fallback erhöht Latenz bei Ausfällen früherer Stufen: Als lohnenswert für Zuverlässigkeit betrachtet, da API-Quota-Erschöpfung ein reales Produktionsproblem ist und yt-dlp/Seitenextraktion die Funktionalität aufrechterhalten.
• mcpName vs. npm-Name-Kollisionsrisiko: MCP-Registry nutzt io.github.<user>/<name> während npm flach ist. Gelöst durch explizite und unterschiedliche Benennung.
• Apple Vision bindet die Bild-zu-Bild-Ähnlichkeitsebene an macOS: Akzeptierter Kompromiss, da die Gemini-basierten Ebenen plattformübergreifend funktionieren.

Der Code ist Open Source, und der Entwickler ist offen für weitere Diskussionen zu Design-Entscheidungen, insbesondere zum Persistenz-vs.-Extraktion-Kompromiss oder zur visuellen Pipeline.