Agentic Ventures Wiki

phase-5-optimize

4 Min. Lesezeit

Phase 5 — Optimize

Ziel: Aus Phase-4-Daten die Top-3-Caller nehmen und pro Caller die richtigen Hebel anwenden. Nicht alle Hebel auf alle Caller — die Hebel-Matrix in caller-inventar sagt was wo passt.

Aufwand: je 1-2h pro Hebel, ueber 1-2 Wochen verteilt.

Vorbedingung: Phase 4 fertig, mind. 3 Tage AIP-Daten im Cost Explorer. Sync mit parallel-Session zu Hebel 6 (Caching) und 8 (Routing).

Nachbedingung: Mai-Trend (30 senken.

Vor-Start-Check (Sync mit Parallel-Session)

Bevor Phase 5 startet, klaeren:

  • Hat die andere Session Prompt-Caching schon eingebaut? In welche Caller?
  • Hat die andere Session Modell-Routing eingebaut? Welche Use-Cases auf Haiku?

Ergebnis pro Caller dokumentieren in caller-inventar.md Hebel-Matrix als „✅ (parallel-Session am DD.MM.)“.

Reihenfolge der Hebel danach ausrichten:

  • Wenn Caching schon drin: Hebel 4 (Tool-Desc) bringt mehr — statischer Teil wird gecached.
  • Wenn Caching noch nicht: Hebel 4 ist trotzdem ok, aber Hebel 6 (Caching) zuerst koordinieren mit anderer Session.

Hebel 4 — MCP-Tool-Description-Cutdown

Worauf: mcp-papierkram (70 Tools!), mcp-whatsapp, mcp-vf-hosted, mcp-m365, mcp-calcom.

Wie:

  1. Script templates/tool-description-audit.py gegen den jeweiligen MCP laufen lassen
  2. Top-10 teuerste Tools nach Token-Count: pruefen ob Tool ueberhaupt regelmaessig benutzt wird (CloudTrail/Caller-Logs). Nicht benutzte Tools: aus dem MCP entfernen oder mit disabled: true markieren.
  3. Beschreibungen kuerzen: 1-2 Saetze, keine Beispiele im JSON-Schema, keine description an jedem Property (nur an unklaren)
  4. Pro MCP Vorher/Nachher-Token-Count dokumentieren

Zielwert: Tool-Beschreibungen-Block insgesamt < 3000 Tokens pro MCP. Bei mcp-papierkram realistisch 5000 Tokens (durch viele Tools), das ist immer noch deutlich besser als unkontrolliert.

Wo das dokumentiert wird:

  • Pro MCP in [[../../capabilities/mcps/.md]] eine Sektion „Token-Footprint”: vorher / nachher / Datum
  • Globale Best-Practice in mcp-best-practices.md ergaenzen (Phase 6)

Hebel 5 — Open-WebUI VF System-Prompt + RAG-Tuning

Worauf: Open-WebUI VF-Pilot exklusiv.

Wie:

  1. Modelfile-System-Prompt: extrahieren, Token-Count, kuerzen — ueberfluessige Anweisungen raus, keine Re-Definition was Claude eh weiss
  2. RAG-Settings im Open-WebUI Admin-Panel:
    • Top-K von Default (oft 10) auf 4 setzen
    • Chunk-Size von 1000 auf 500 (oder 300 wenn Eval-Set OK)
    • Re-Ranking on lassen aber Cohere Rerank v3.5 ist guenstig — kein Eingriff noetig
  3. Chat-Verlaufs-Truncation: max 20 letzte Messages oder 10k Tokens
  4. Eval-Set fuer Qualitaetskontrolle: vor Aenderung 10 typische Fragen + erwartete Antworten festhalten, nach Aenderung gleicher Test. Bei Qualitaets-Drop: zurueck.

Erwarteter Effekt: 50-70% Input-Reduktion pro Open-WebUI-Call. Bei aktuellem Anteil dieses Callers (vermutlich Hauptverdaechtiger) der groesste Hebel ueberhaupt.

Hebel 6 — Prompt-Caching 1h-TTL

Status: parallel-Session.

Hier nur: verifizieren dass es eingebaut wurde. Cost-Explorer-Spalte EUC1-MP:EUC1_CacheReadInputTokens-Units muss auftauchen. Wenn nicht: nach-haken.

Hebel 7 — Embeddings-Migration zu Titan v2

Worauf: alle RAG-Pipelines die nicht echte Cross-Lingual-Suche brauchen.

Pruefung pro RAG-Pipeline:

  • Welche Sprachen sind Query + Documents? Wenn beide DE → Titan v2 ok. Wenn DE-Query gegen EN-Docs → bei Cohere bleiben.
  • Embedding-Dimension: Titan v2 = 1024/512/256, Cohere v3 = 1024. Bei Wechsel: Re-Embedding-Lauf, Vector-DB-Schema ggf anpassen.

Konkrete Kandidaten:

  • icking-rebuild: vermutlich DE-only → Titan v2
  • mcp-vf-hosted RAG (falls vorhanden): pruefen
  • Open-WebUI VF Knowledge-Base: pruefen

Aufwand: pro RAG-Pipeline ca. 1 Nachmittag (Re-Embedding-Lauf + Eval-Set).

Hebel 8 — Modell-Routing (Haiku-First + Confidence-Escalation)

Status: parallel-Session.

Hier nur: sicherstellen dass die neuen Caller in Phase 4 (z.B. mcp-vf-hosted, receptionist) auch Routing nutzen. Wenn die parallel-Session nur Open-WebUI + mcp-whatsapp betrifft, hier die anderen Caller nachziehen.

Hebel 9 — Batch-Inference fuer Async-Workloads

Worauf:

  • daily-briefing Lambda (laeuft 1x/Tag, kann auf Batch umgestellt werden)
  • Beleg-Klassifikation in der Papierkram-Pipeline (sofern existiert, sonst Phase 7-Vorbereitung)
  • Wiki-Maintenance autonomous-mode-Runs
  • Recherche-Report-Runs in intern/runs/

Wie:

  1. Caller-Code umbauen: statt bedrock-runtime:InvokeModel synchron → bedrock:CreateModelInvocationJob mit JSONL-Input in S3
  2. Lambda triggert Batch-Job, schreibt Output zurueck nach S3, dann Folge-Schritt
  3. Erwartung: 50% Rabatt, 24h Turnaround. Nicht geeignet wenn User-Wartezeit < 24h erwartet.

Pattern dokumentieren in intern/wissen/prozesse/bedrock-batch-inference.md (in Phase 6 anlegen falls Hebel 9 gemacht wurde).

Definition of Done

  • Sync mit Parallel-Session bzgl Hebel 6 + 8 dokumentiert in caller-inventar.md
  • Hebel 4 auf Top-3 MCPs angewandt, Token-Counts vorher/nachher dokumentiert
  • Hebel 5 auf Open-WebUI angewandt, Eval-Set bestanden
  • Hebel 7 fuer mind. eine RAG-Pipeline ausgefuehrt
  • Hebel 9 fuer mind. einen Async-Workload ausgefuehrt
  • Neue Cost-Explorer-Daten zeigen messbare Reduktion (mind. -40% gegenueber Mai-Trend)

Risiken

  • Hebel 4 (Tool-Description-Cutdown) kann Sonnet/Haiku verwirren, wenn Beschreibung zu knapp wird — Modell ruft das falsche Tool. Mitigation: Eval-Set pro MCP, mind. 5 Tool-Use-Test-Calls vor Production.
  • Hebel 5 (RAG-Top-K runter) kann Halbwissens-Antworten geben wenn relevante Chunks nicht in den Top-4. Mitigation: Eval-Set.
  • Hebel 7 (Embeddings-Wechsel) ist Vector-DB-Schema-Change — Roll-Back-Plan bereithalten (alte Embeddings parallel halten bis Eval ok).

Graphansicht

Backlinks