Attest (Telefonische Überprüfung)

Per Telefon verifizieren

Verwenden Sie diesen Skill, wenn ein Agent feststellen muss, ob gespeicherte Informationen über eine Organisation noch zutreffen, und ein Anruf bei der veröffentlichten Telefonnummer der Organisation der Weg ist, dies herauszufinden.

verify-by-phone ist ein Skill für Verifizierungsabläufe. Er tätigt genau einen offengelegten ausgehenden CALL-E-Anruf pro Datensatz, extrahiert die Antwort aus dem Transkript mit einer wörtlichen Belegspanne, gleicht sie mit einem transparenten Trefferbewertungsverfahren gegen den gespeicherten Datensatz ab und gibt entweder eine kalibrierte Konfidenz oder eine explizite Enthaltung zurück. Das Designziel ist ein Agent, der niemals eine unsichere telefonische Antwort in einen sicheren Datenbankeintrag umwandelt.

Wann verwenden

Verwenden Sie diesen Skill für:

• die Überprüfung eines Anbieterverzeichniseintrags: Ist diese Praxis real, erreichbar, nimmt neue Patienten auf, akzeptiert einen bestimmten Versicherungsplan?
• die Prüfung, ob ein gespeicherter Geschäftseintrag (Öffnungszeiten, Dienstleistungen, Verfügbarkeit) noch der Realität entspricht
• die Aktualisierung von Datensätzen, bei denen das Telefon die Quelle der Wahrheit ist und der Eintrag vermutlich veraltet ist
• Arbeitsabläufe, in denen ein „unbekanntes“ Ergebnis ehrlich aufgezeichnet werden muss, anstatt geraten zu werden
• einen Datensatz nach dem anderen, mit einer vom Menschen autorisierten Empfängerliste

Wann nicht verwenden

Verwenden Sie diesen Skill nicht, um:

• nicht offengelegte oder vorgetäuschte Anrufe zu tätigen; jeder Anruf gibt im selben Atemzug bekannt, dass es sich um einen automatisierten Assistenten handelt und warum er anruft
• Funknummern oder private Nummern anzurufen; Verifizierungsziele sind veröffentlichte geschäftliche Telefonnummern
• Marketing, Verkauf, Lead-Generierung oder sonstige Werbemaßnahmen durchzuführen
• eine Liste ohne Autorisierung pro Datensatz zu wählen
• einen gespeicherten Eintrag direkt aus einem Anrufergebnis zu überschreiben; die Ausgabe ist ein Urteil mit Nachweisen, und die Entscheidung zum Schreiben verbleibt beim Bediener
• eine Antwort zu raten, die der Befragte nicht gegeben hat; wenn der Anruf keine verwertbare Antwort liefert, ist das Ergebnis eine Enthaltung, und das ist die korrekte Ausgabe

Regeln für Einwilligung und Offenlegung

Diese sind tragend, nicht nur Textbausteine:

1. Der Anruf beginnt damit, dass die KI-Identität und der Zweck gemeinsam genannt werden, noch vor allem anderen, und dass der Anruf möglicherweise aufgezeichnet wird.
2. Wenn der Befragte Einwände gegen ein Gespräch mit einem automatisierten Anrufer erhebt, bedankt sich der Anruf und beendet das Gespräch sofort. Das Ergebnis vermerkt die Ablehnung als nicht verifizierbares Ergebnis.
3. Die Wartezeit ist begrenzt. Wenn der Befragte den Anrufer bittet zu warten, wartet dieser kurz und meldet sich dann zurück, anstatt unbegrenzt zu warten.
4. Der Agent erfindet niemals Informationen, die ihm nicht gegeben wurden, weder im Anruf noch im Ergebnis. Konkret: Eine Praxis fragt den Anrufer oft nach einem Namen, einem Geburtsdatum, einer Versicherten- oder Kreditkartennummer oder einem Grund für den Besuch. Der Agent sagt deutlich, dass er diese Informationen nicht hat, da es sich um einen Verifizierungsanruf für ein Verzeichnis und nicht um eine Terminanfrage handelt, und wiederholt dann die Frage, die er zu stellen beabsichtigte. Ein Platzhalter ist eine Erfindung.
5. Voicemail ist keine Antwort. Wenn ein Anrufbeantworter oder eine Voicemail erreicht wird, endet der Anruf sofort, ohne eine Nachricht zu hinterlassen: Eine Verzeichnistatsache kann nicht aus einer Aufzeichnung ermittelt werden, und niemand sollte eine Roboternachricht auf seinem Anschluss vorfinden.
6. Anrufe dienen der informativen Verifizierung, nicht der Werbung. Behandeln Sie jeden Anruf so, als ob er unter Berücksichtigung der Anforderungen an die Einwilligung aller Beteiligten aufgezeichnet wird.

Verifizierungsablauf

1. Kalibrieren Sie zuerst die Enthaltungsschwelle mit scripts/calibrate.py anhand von beschrifteten Szenariodaten, sodass "sicher" etwas Messbares bedeutet: Auf dem Standardniveau liegt die wahre Antwort in mindestens 90 Prozent der Fälle innerhalb des Vorhersagesatzes für zurückgehaltene Daten. Das Skript gibt einen qhat-Wert aus, den Schritt 6 benötigt. Dies läuft ohne Anmeldedaten und ohne Anrufe, kann also einmalig vor jeglichem Wählen durchgeführt werden.
2. Sammeln Sie den zu überprüfenden Datensatz: Organisationsname, veröffentlichte Telefonnummer im E.164-Format und die zu prüfenden Behauptungen (z. B. nimmt neue Patienten auf, akzeptiert einen benannten Plan).
3. Bestätigen Sie, dass der Bediener diesen speziellen Anruf an diese spezielle Nummer autorisiert.
4. Erstellen Sie die Anrufaufgabe mit scripts/place_verify_call.py. Das Skript führt standardmäßig einen Testlauf (Dry Run) durch, der die genaue Aufgabe und den Empfänger anzeigt, ohne zu wählen; übergeben Sie --live erst, wenn der Testlauf korrekt aussieht.
5. Fragen Sie das Endergebnis mit scripts/poll_result.py ab, das die vollständigen Nutzdaten in einer lokalen Datei speichert.
6. Extrahieren Sie die Antwort mit scripts/extract_answer.py --qhat aus Schritt 1. Jedes extrahierte Feld enthält die wörtliche Transkriptspanne und die Zeichenoffsets, die es stützen. Abgeschwächte Antworten ("ich glaube schon") behalten ihre Polarität mit einem gedämpften Vertrauenswert. Nicht reagierende Antworten (falsche Nummer, Ablehnung, "rufen Sie später nochmal an") werden niemals als Antworten gewertet. Die Antwort wird nur ausgegeben, wenn der kalibrierte Vorhersagesatz ein einzelner Wert ist und dieser Wert nicht "unbekannt" ist; andernfalls ist das Ergebnis eine Enthaltung. Das Weglassen von --qhat führt zu einer Enthaltung bei allem und kennzeichnet die Ausgabe als uncalibrated, da eine Schwelle ohne dahinterstehende Kalibrierung keine Garantie bietet.
7. Gleichen Sie das Ergebnis mit dem gespeicherten Datensatz mit scripts/reconcile_record.py ab: Jedes übereinstimmende Feld fügt dokumentierte Beweispunkte hinzu, jedes abweichende Feld subtrahiert sie, und das Urteil lautet verifiziert, widersprochen oder nicht verifizierbar.

Wartungshinweis

Die Skripte in diesem Skill sind eigenständige Kopien der Referenzimplementierung im Attest-Backend (backend/app im Quellrepository). Sie werden absichtlich klein gehalten, damit der Skill ohne Abhängigkeiten von diesem Repository installiert werden kann.

Diese Kopie wird erzwungen, nicht nur versprochen. tests/test_skill_parity.py im Quellrepository führt den Extraktor dieses Skills und den des Backends mit denselben Transkripten aus und schlägt fehl, wenn sie in der Antwort, in den Zeichenoffsets der zitierten Spanne oder in den Cue-Lexika selbst voneinander abweichen. Eine frühere Version dieses Hinweises bat einen Menschen, die Synchronisation manuell durchzuführen, und die Kopie driftete dennoch ab: Das Backend lernte, dem letzten Cue in einer Äußerung zu vertrauen und "kein Problem" als Zustimmung zu lesen, während dieses Skript immer noch dem ersten vertraute, sodass ein einfaches "Nein, sind wir nicht" hier zu einer Enthaltung und dort zu einer Antwort führte.

Kurzanleitung

pip install calle-ai

# 1. Kalibrieren Sie zuerst die Grenze. Gibt den qhat aus, den Schritt 5 benötigt.
python3 scripts/calibrate.py --data references/sample-scenarios.jsonl --alpha 0.1

# 2. Testlauf: Zeigt die Aufgabe und den maskierten Empfänger an, wählt nichts.
python3 scripts/place_verify_call.py \
  --org "Beispiel Beratungszentrum" \
  --phone "+15550101234" \
  --claim-accepting-new-patients yes \
  --claim-plan "Beispiel Gesundheit PPO"

# 3. Führen Sie den Anruf tatsächlich durch (erfordert CALLE_API_KEY).
python3 scripts/place_verify_call.py ... --live

# 4. Warten Sie auf die endgültigen Nutzdaten.
python3 scripts/poll_result.py --call-id call_abc123 --out result.json

# 5. Extrahieren Sie die belegbasierte Antwort, gesteuert durch die kalibrierte Schwelle.
python3 scripts/extract_answer.py --payload result.json --qhat 0.750

# 6. Gleichen Sie gegen den gespeicherten Datensatz ab.
python3 scripts/reconcile_record.py --payload result.json \
  --claim-accepting-new-patients yes --claim-plan-accepted yes

Alle Beispielnummern in diesem Skill sind reservierte fiktive Nummern. Der Testlauf-Pfad und die gebündelten Szenariodaten bedeuten, dass alles außer Schritt 3 ohne Anmeldedaten und ohne echten Anruf ausgeführt wird.

Wie die Ausgabe aussieht

extract_answer.py gibt ein JSON-Objekt pro Behauptung aus:

{
  "claim": "accepting_new_patients",
  "answer": "yes",
  "trust_score": 0.9,
  "hedged": false,
  "span": {"turn": 6, "text": "Yep.", "char_start": 0, "char_end": 3},
  "abstain": false,
  "gate": "conformal(qhat=0.750)"
}

Eine Enthaltung behält dieselbe Form mit "abstain": true, entweder weil der kalibrierte Vorhersagesatz mehr als ein Label enthielt oder weil der Extraktor keine Antwort fand ("answer": "unknown"). Das Feld gate gibt die Schwelle an, die die Entscheidung getroffen hat, und lautet uncalibrated, wenn kein --qhat angegeben wurde – der einzige Fall, in dem sich jede Behauptung unabhängig vom Gesagten enthält. reconcile_record.py fügt die Trefferbewertungsarithmetik und ein Urteil hinzu. Kein Feld erscheint jemals ohne entweder eine stützende Spanne oder eine explizite Enthaltung.

Nebenwirkungen und Stornierung

• Nebenwirkung: Genau ein ausgehender Telefonanruf pro --live-Aufruf an die vom Bediener angegebene Nummer. Nichts wiederholt sich; es gibt keinen Planer in diesem Skill.
• Kosten: Ein kostenpflichtiger CALL-E-Anruf pro Live-Durchlauf. Testläufe sind kostenlos.
• Stornierung: CALL-E bietet keine Stornierung von Anrufen, daher ist der Moment zum Stoppen vor --live. Der Standard-Testlauf existiert genau aus diesem Grund.
• Daten: Nutzdaten werden in lokale Dateien geschrieben, die der Bediener benennt. Telefonnummern werden in der Konsolenausgabe maskiert. Nichts in diesem Skill überträgt Ergebnisse an andere Stellen als die CALL-E-API selbst.

Referenzen

• references/api-notes.md: Die empirisch beobachtete CALL-E-Nutzlastform und das API-Verhalten, auf die sich dieser Skill stützt, einschließlich Fakten, die durch Tests statt durch Dokumentation entdeckt wurden.
• references/verification-protocol.md: Das vollständige Offenlegungsskript, die rechtliche Haltung für ausgehende Verifizierungsanrufe und warum die Enthaltung die zentrale Designentscheidung ist.
• references/sample-scenarios.jsonl: Beschriftete fiktive Szenariodaten, die von scripts/calibrate.py verwendet werden, sodass die Kalibrierung ohne Anmeldedaten und ohne Anrufe ausgeführt wird.