stcc-mcp — Telefon-Triage-Einstufung: Regeln rechnen deterministisch, 0.6B prüft nur Kriterien

Eine Anamneseaufzeichnung geht hinein, heraus kommt L1–L5-Stufe + Maßnahmenformulierung + Einzelzitate + welche Kriterien noch fehlen. Die Einstufung wird von einer deterministischen Regel-Engine berechnet (225 STCC-Protokolle / 849 Zweige / 4.168 Kriterien, werden mitgeliefert), Qwen3-0.6B beantwortet nur eine Sache: Gegeben die Aufzeichnung und ein Kriterium, yes / no / unknown.

Das Modell wählt keine Zweige, legt keine Stufe fest, erzeugt keine Maßnahmenformulierung und macht keine Tool-Calls.

⚠️ Kein Notfall-Triage-System, keine Diagnose, kein Ersatz für Ärzte. L1–L5 ist eine Maßnahmenleiter (Rettungswagen rufen / sofort Notaufnahme / heute zum Arzt / in den nächsten zwei Tagen zur Praxis / zu Hause beobachten). In Notfällen direkt 120 wählen.

In drei Schritten zum Laufen

pip install stcc-mcp                                       # 或 uvx stcc-mcp …
ollama pull hf.co/chenhaodev/stcc-checker-0.6b-GGUF:Q8_0   # 640MB 核对器
stcc-mcp doctor                                            # 自检：索引 / Ollama / 模型
stcc-mcp triage --protocol Chest_Pain.md "$(cat 记录.txt)"

Keine residenten Prozesse, kein Docker, keine Netzwerkverbindung. Die Engine ist reine Standardbibliothek, ohne Drittanbieter-Abhängigkeiten.

Beim ersten Lauf sieht man mit hoher Wahrscheinlichkeit tier: L1 + certain: false — das ist richtig

Nimmt man eine gewöhnliche Anamneseaufzeichnung, erhält man sehr wahrscheinlich die dringlichste Stufe plus eine Reihe von unresolved. Das ist kein Fehlurteil: Die Engine schließt einen Zweig nur aus, wenn alle Bedingungen darin no sind, und eine echte Anamnese fragt nicht alle Kriterien eines Zweigs ab. In einer Aufzeichnung über leichtes Fieber fragt die Pflegekraft z. B. Bewusstsein/Atmung/Nackensteifigkeit/Hautausschlag ab, aber nie nach Dehydrationszeichen (verminderte Urinausscheidung, eingesunkene Augen, verminderter Hautturgor, Durst), also kann der Zweig nicht ausgeschlossen werden und die Ausgabe bleibt an der Obergrenze seiner Stufe.

unresolved ist die Liste der „frag diese Punkte nach, dann wird es enger“. Ergänzt man die Antworten in der Aufzeichnung und führt sie erneut aus, wird unresolved monoton kürzer; aber die Stufe sinkt nur, wenn ein Zweig vollständig ausgeschlossen wird — im Test blieb bei derselben Fieberaufzeichnung nach Ergänzung der Dehydrationszeichen unresolved 8→2, die Stufe blieb jedoch bei L1, weil der verbleibende Hauptzweig (so ein Halbsatz wie 老年人或免疫低下者…脱水表现：) vom Prüfer als unknown bewertet wird. Dann sollte man den Schwellenwert-Drehregler weiter unten betätigen, nicht weiterfragen. Siehe Grenzen ①②.

Anbinden an einen Agenten (Claude Code / beliebiger MCP-Client):

pip install "stcc-mcp[mcp]" && stcc-mcp serve               # stdio MCP

Ollama unterstützt kein MCP, was für diese Form kein Problem ist: Das kleine Modell macht nie Tool-Calls, die Orchestrierungsschicht ruft Ollama (HTTP) und die Regel-Engine (im Prozess) getrennt auf, die beiden kennen sich nicht. Autonomes Tool-Calling mit 0.6B ist ein bekanntes Problemfeld; diese Architektur umgeht es konstruktionsbedingt.

Related MCP server: Quellgeist

Ausgabe

Die Abbildung von Stufe auf Aktion legt deine Orchestrierungsschicht fest; dieses Paket liefert nur Stufe und Maßnahmenformulierung.

Die Schwelle für no ist ein Drehregler

--no-threshold (Standard 0,63): P(no) ≥ τ ⇒ no, sonst wird der größere von yes/unknown genommen. Dasselbe Modell auf der Veröffentlichungsverteilung (n=3225), die gesamte Abwägungskurve:

Dieselbe Fieber-Anamneseaufzeichnung, nur τ geändert:

$ stcc-mcp triage --protocol Fever_Adult.md --no-threshold 0.63 "$(cat 记录.txt)"
  tier L1 · 拨打救护车        · unresolved 2
$ stcc-mcp triage --protocol Fever_Adult.md --no-threshold 0.40 "$(cat 记录.txt)"
  tier L3 · 2小时内接受医疗护理 · unresolved 5

τ niedriger ⇒ der Prüfer wagt es eher, Kriterien, die „gefragt und verneint“ wurden, als no zu bewerten ⇒ Zweig wird ausgeschlossen ⇒ Stufe sinkt. Das macht das Modell nicht genauer, sondern verschiebt den Arbeitspunkt auf derselben Abwägungskurve — erkauft mit steigendem Risiko von übersehenen Fällen.

false_no (sollte zutreffen, wird aber als no gewertet) ist eine harte Grenze — ein falsches no schließt den wahren Zweig aus der sicheren Konvergenz aus. Zu wenige no-Urteile verursachen nur Übertriage, das ist ein Kostendrehregler. Der Standardwert wurde auf Dev nach false_no ≤ 0,0036 gewählt (dieses Dev hat nur 495 positive Beispiele, Auflösung 0,0020, systematisch eher konservativ). Es gibt also keinen festgenagelten „optimalen Wert“, die Kurve wird komplett mitgeliefert — man wählt den Punkt nach seiner eigenen Kostenmatrix. Reproduktion: python -m scripts.threshold_sweep --model <m> --split <s> --collect --report.

🔴 Bekannte Grenzen (erst diesen Abschnitt lesen, dann entscheiden, ob man es einsetzt)

① Die Eingabe muss eine Aufzeichnung sein, die „bereits eine Runde nach Protokoll gefragt“ wurde, keine rohe Selbstdarstellung. Kurze Hauptbeschwerden haben eine unknown-Rate von 94 %; echte reichhaltige Dialoge (IMCS-21, 748 Zeichen / 40 Runden) haben immer noch 88 %. Der Grund: Die vorgeschalteten STCC-Zweige filtern nach Notfall-Rotflaggen (Verschlucken, blau werden, keine Reaktion), und natürlich entstandene Korpora enthalten diese Fälle per Definition nicht, und Ärzte fragen auch nicht danach — das ist ein Selektionseffekt, reichhaltigere Korpora helfen nicht.

② Eine echte Anamnese fragt nicht alle Kriterien eines Zweigs ab, daher bleibt die Stufe an der Obergrenze dieses Zweigs. Das ist worst_case bei korrekter Arbeit, aber die Enge der Obergrenze hängt vollständig von der Vollständigkeit der Anamnese ab.

③ Die Sicherheit von worst_case setzt voraus, dass keine falschen no erzeugt werden. Die Ausgabe ist die dringlichste Stufe, die unter den vorhandenen Beweisen nicht ausgeschlossen werden kann (ein Zweig gilt nur dann als ausgeschlossen, wenn alle Bedingungen no sind), daher ist Untertriage immer 0, und mit jedem weiteren no in den Beweisen wird es monoton enger (zwei Invarianten werden von tests/ bewacht). Bei unzureichenden Informationen degeneriert es zu „für alle den Rettungswagen rufen“ — das ist eine Designentscheidung (Untertriage 10·d² vs. Übertriage d), kein Bug.

④ Die Einstufung selbst ist Silber: Die Referenz auf Zweigebene wurde von einem starken Modell finalisiert und von Menschen geprüft, für die endgültige Schlussfolgerung fehlt noch ein Goldstandard von echten Pflegekräften.

Warum unknown ein erstklassiger Status ist

Die Semantik eines STCC-Zweigs ist: „Ist irgendeine Bedingung in diesem Zweig ja ⇒ Treffer; sind alle nein ⇒ weiter zum nächsten Zweig“. „Nicht erwähnt“ ≠ „verneint“: Ersteres muss eine Rückfrage auslösen, Letzteres darf erst den Zweig wechseln. unknown zu no zu pressen ist gleichbedeutend mit einem frei erfundenen Negativbefund und bringt die Engine in den falschen Zweig.

Kriterientexte

Die Kriterien im Index sind einzeln unabhängig umgeschriebene Versionen (5.214/5.214). Reine Schwellenwerte und einzelne medizinische Begriffe („Husten“, „Temperatur >100.4°F“) werden inhaltlich beibehalten. Die Umschreibung durchlief drei Prüfungen: formale Validierung von Zahlen/Negation/Länge/Ähnlichkeit, Oracle-Replay bitweise identisch mit dem Original, und die Metriken des nachgelagerten Checkers fallen nicht ab.

Entwicklung

uv sync
uv run pytest -q                        # 27 条回归
uv run python -m scripts.mcp_selfcheck  # oracle 回放 4,168 条判据，<1 秒

scripts/mcp_selfcheck.py ist der Treue-Selbsttest der Engine: Jedes Kriterium wird einzeln auf yes gesetzt, der Rest auf no, und es wird geprüft, welchen Zweig und welche Behandlung die Engine erreicht. Das ist keine Modellevaluierung — wenn es nicht übereinstimmt, hat die Kompilierung oder Auswertung ein Loch.

Modell

chenhaodev/stcc-checker-0.6b-GGUF (Q8_0 / Q4_K_M). Auf Kriterienebene false_no 0,0024, mediane Latenz ~250 ms, Ende-zu-Ende 1,25 s/Eintrag.

Apache-2.0.