LangChain · Beta

LangChain-Observability jenseits einer grünen Chain

Ein beendetes LangChain-Invoke heißt: das Runnable hat geantwortet. Nicht: der Job war ein Erfolg. Observability muss beides auf demselben Lauf zeigen.

Was gelaufen ist vs. Bedeutung

LangChain-Chains setzen Runnables, Prompts, Modelle und Parser zusammen. Callbacks und Tracer zeigen, welche Schritte 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 eine grüne Chain 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 nur in einem Chat oder einer Tabelle liegen.

Was das in der Praxis heißt

Stell dir ein LangChain-Invoke von Start bis Ende vor. Du gehst denselben Lauf zweimal durch. Einmal für die Chain. Einmal für den Job, den du dem Nutzer zugesagt hast.

Zuerst schaust du auf Tracing. Der Prompt lief. Das Modell lieferte Tokens. Der Parser war fertig. Die Spans sehen gut aus. Das sagt nur: Die Chain hat ihren Pfad beendet.

Dann kommt die Frage zum Job. Gibt es eine brauchbare Antwort? Steht sie auf dem Kontext, den du dem Modell gabst? Fallen die Checks durch, ist der Lauf für den Nutzer ein Fail. Auch wenn der HTTP-Status gesund wirkt.

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 LangChain-Observability jenseits einer grünen Ampel.

Beispiel: falscher Erfolg

Prompt, Modell und Parser können fertig werden. Das Invoke 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.

Ein fertiger Modell-Span ist nicht dasselbe wie eine brauchbare Antwort. Ein sauberer Parser beweist nicht Text, 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 LangChain-Spans.

Dann kann ein Review fair fragen: Haben wir Geld für einen echten Erfolg ausgegeben? Oder für eine saubere Chain, die den Job trotzdem verfehlt hat?

Runnable anbinden

Nutze eine Stelle zum Anbinden. Wrappe die Chain. Behalte LangChains Callbacks und 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.langchain import instrument

chain = instrument(
    build_chain(),
    report_result=lambda answer: {
        "result": "completed" if answer else "unresolved",
        "result_valid": bool(answer),
        "requirements": {"non_empty_answer": bool(answer)},
        "metrics": {"answer_characters": len(str(answer))},
    },
)
print(chain.invoke("What is observability?"))

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. Das Lehr-YAML darunter zeigt die Form lesbar. Das live OSS-Beispiel nutzt Contract v2 mit einer gemeinsamen useful-answer-Regel — dieselbe Idee, neben dem Chain-Code statt nur im Dashboard.

version: 1
service:
  name: langchain-answer
  runtime: langchain
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 LangChain-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 runnable-pipeline-Beispiel im Open-Source-Repo. Binde den Helper an. Deklariere ein Ziel. Prüfe einen Lauf von Ende zu Ende.

Lies die LangChain-Docs, wenn du die API-Form brauchst. Behalte Tracing. Ergänze die Outcome-Schicht daneben. Die Integration ist Beta. Die Wrap-Form bleibt. Details können noch enger werden.

FAQ

Heißt ein grünes LangChain-Invoke Erfolg? Nein. Grün heißt: Runnables sind fertig. Erfolg heißt: Das Ziel, das du benannt hast, hat für diesen Lauf gehalten.

Ersetze ich LangChain-Callbacks oder Tracer? Nein. Behalte natives Tracing für Spans. Hänge Outcome-Felder daneben an denselben Lauf. Sie arbeiten zusammen.

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

Ist die LangChain-Integration stabil? Sie ist Beta. Der Wrap und die Idee „Ziel auf dem Lauf“ bleiben. APIs können noch enger werden, während Beispiele reifen.

Weiterführend

Observability für agentische Workflows · Haystack · LangGraph · OpenAI Agents