Haystack

Haystack-Observability jenseits einer grünen Pipeline

Ein beendeter Haystack-Lauf heißt: Die Teile sind gelaufen. Nicht: Der Job war ein Erfolg. Observability muss beides auf demselben Lauf zeigen.

Was gelaufen ist vs. Bedeutung

Haystack baut Abläufe aus Retrievern, Generatoren und Tools. Tracing zeigt, welche Teile gelaufen sind. Das hilft. Es ist aber nur die halbe Geschichte.

Du brauchst auch ein klares Ziel. Hat der Job gehalten, den du benannt hast? Ohne diese Frage kann ein grüner Lauf eine leere Antwort verstecken. Oder eine Antwort ohne Beleg.

Denk in Schichten auf einem Lauf. Tracing für Spans. Checks für Qualität. Kosten für Spend. Outcomes für „war der Job erledigt?“ Halte sie zusammen. Lass die letzte Schicht nicht in einem Chat oder einer Tabelle liegen.

Was das in der Praxis heißt

Stell dir einen Haystack-RAG-Lauf von Start bis Ende vor. Du gehst denselben Lauf zweimal durch. Einmal für die Teile. Einmal für den Job, den du dem Nutzer zugesagt hast.

Zuerst schaust du auf Tracing. Die Retriever liefen. Der Generator gab Text zurück. Die Spans sehen gut aus. Das sagt nur: Der Ablauf hat seine Schritte beendet.

Dann kommt die Frage zum Job. Gibt es eine brauchbare Antwort? Steht sie auf dem Kontext, den du geholt hast? Fallen die Checks durch, ist der Lauf für den Nutzer ein Fail. Auch wenn HTTP 200 da steht.

Hänge Kosten an dieselbe Lauf-ID. Tokens und Tool-Spend zählen mehr, wenn du weißt, ob das Ziel passt. Ein günstiger Fail und ein teurer Fail sind zwei Reviews. Beide brauchen das markierte Ziel.

Schreib die Regel einmal neben den Code. Jede Person soll denselben Lauf gleich werten. Das ist Haystack-Observability jenseits einer grünen Ampel.

Beispiel: falscher Erfolg

Beide Retriever können Treffer liefern. Der Generator kann HTTP 200 liefern. Die Antwort kann trotzdem leer sein. Oder ohne Beleg. Diese Lücke ist ein falscher Erfolg.

Ops traut vielleicht dem grünen Pfad. Produkt sieht trotzdem einen Fail. Ohne ein benanntes Ziel auf dem Lauf treffen sich diese beiden Sichten nie.

Treffer vom Retriever sind nicht dasselbe wie eine brauchbare Antwort. Ein fertiger Generator-Span ist nicht dasselbe wie Text mit Beleg, dem der Nutzer trauen kann.

Ein Produktziel ist eine kurze, geteilte Regel für „fertig“. Belege sind die Felder, die Pass oder Fail zeigen. Behalte beides neben den Haystack-Spans.

Dann kann ein Review fair fragen: Haben wir Geld für einen echten Erfolg ausgegeben? Oder für einen sauberen Ablauf, der den Job trotzdem verfehlt hat?

Pipeline anbinden

Nutze eine Stelle zum Anbinden. Wrappe den Ablauf. Behalte Haystacks eigenen Tracer. Hänge Sinn an die Daten, die zurückkommen.

Das Snippet unten meldet, ob eine Antwort da ist. Das ist ein einfacher Start. Später kannst du mehr Checks ergänzen. Die Wrap-Form bleibt gleich.

from witdem_sdk.integrations.haystack import instrument

pipeline = instrument(
    build_pipeline(...),
    report_result=lambda result: {
        "result": "completed" if result.get("answer", {}).get("answer") else "unresolved",
        "result_valid": bool(result.get("answer", {}).get("answer")),
        "requirements": {"non_empty_answer": bool(result.get("answer", {}).get("answer"))},
    },
)

Erfolg neben dem Code deklarieren

Lege das Produktziel im Repo ab. Dann wertet jede Person denselben Lauf mit derselben Regel.

Ein Contract benennt Artefakt und Ziel. Pass heißt: Das Antwortfeld ist da. Die Regel liegt in Git beim Ablauf. Nicht nur hinter einem Schalter im Dashboard.

version: 1
service:
  name: haystack-answer
  runtime: haystack
contracts:
  useful_answer:
    artifact:
      name: Answer
      valid:
        non_empty: $.answer
    product_goal:
      name: Non-empty answer
      achieved:
        all:
          - $.witdem.artifact_valid

Was am Lauf zählt

Ob das Ziel hält, welche Belege da sind und was der Spend war: Das sollte dieselbe Lauf-ID teilen. Behalte es neben den Spans. Ersetze Spans nicht durch einen einzelnen Score.

Wenn du einen Lauf öffnest, willst du Pfad und Outcome zusammen. So findest du einen falschen Erfolg. Ohne über Tools hinweg zu raten.

Beispiel ausführen

Starte mit dem Parallel-Retriever-Beispiel im Open-Source-Repo. Binde den Helper an. Deklariere ein Ziel. Prüfe einen Lauf von Ende zu Ende.

Lies die Haystack-Docs, wenn du die API-Form brauchst. Behalte Tracing. Ergänze die Outcome-Schicht daneben.

FAQ

Heißt ein grüner Haystack-Lauf Erfolg? Nein. Grün heißt: Die Teile sind fertig. Erfolg heißt: Das Ziel, das du benannt hast, hat für diesen Lauf gehalten.

Ersetze ich Haystacks eigenen Tracer? Nein. Behalte Tracing für Spans. Hänge Outcome-Felder daneben an denselben Lauf.

Was ist ein Produktziel für RAG? Eine kurze, geteilte Regel für „fertig“. Zum Beispiel: Antwort ist nicht leer. Oder: Antwort hat Beleg. Belege sind die Felder, die Pass oder Fail zeigen.

Wo soll die Regel liegen? Im Repo neben dem Ablauf. So nutzen Reviews eine Definition. Nicht in jedem Tool neu erfinden, was „gut“ heißt.

Weiterführend

Observability für agentische Workflows · LangGraph-Observability · LangChain-Observability · OpenAI-Agents-Observability