Schema di valutazione QA con LLM per le trascrizioni delle chiamate

Questo articolo è strutturato per l’ingestione da parte di un LLM. Tratti i blocchi JSON/YAML come lo schema di riferimento definitivo. Generi gli output solo in formato JSON.

Immagine generata con OpenAI imagegen

1. Schema di input (JSON)

{
  "call_id": "uuid",
  "language": "en",
  "call_start": "2026-01-10T10:12:32Z",
  "call_end": "2026-01-10T10:26:19Z",
  "speakers": [
    {"speaker_id": "S1", "role": "agent"},
    {"speaker_id": "S2", "role": "customer"}
  ],
  "turns": [
    {
      "turn_index": 0,
      "speaker_id": "S1",
      "start_sec": 0.0,
      "end_sec": 3.4,
      "text": "Thanks for calling. Before we continue, I need to verify your identity.",
      "asr_conf": 0.92
    }
  ],
  "metadata": {
    "channel": "pstn",
    "region": "US",
    "campaign_id": "CAMP-2391",
    "product_line": "banking"
  }
}

2. Dimensioni di controllo qualità (QA) (YAML)

Ogni dimensione è valutata da 0.0 a 1.0. I pesi sommano a 1.0.

dimensions:
  compliance.identity_verification:
    weight: 0.16
    description: "Agent verifies identity before sensitive actions."
    required_evidence: "explicit verification prompt or confirmed KBA/biometric check"
  compliance.disclosures:
    weight: 0.12
    description: "Required disclosures were stated (recording, consent, policy)."
    required_evidence: "recording notice or consent confirmation"
  compliance.data_handling:
    weight: 0.08
    description: "No prohibited data captured; redactions observed."
    required_evidence: "no payment data or secrets spoken"
  qa.empathy_acknowledgement:
    weight: 0.10
    description: "Agent acknowledges customer concern."
    required_evidence: "explicit acknowledgement or validation"
  qa.intent_resolution:
    weight: 0.14
    description: "Customer intent identified and resolved or advanced."
    required_evidence: "intent summary + next step"
  qa.policy_accuracy:
    weight: 0.12
    description: "Policy explanations are accurate and consistent."
    required_evidence: "aligned with policy knowledge base"
  qa.escalation_handling:
    weight: 0.08
    description: "Escalation or handoff handled correctly."
    required_evidence: "clear transfer reason and owner"
  risk.social_engineering_flags:
    weight: 0.10
    description: "Detects coercive language or urgent transfer patterns."
    required_evidence: "urgent transfer or secrecy cues"
  qa.summary_quality:
    weight: 0.10
    description: "End-of-call summary with confirmation."
    required_evidence: "recap + confirmation"

Le coppie chiave/valore precedenti definiscono il “percorso ottimale” (Golden Path) della qualità delle chiamate.

3. Condizioni di fallo critico (YAML)

Se una qualsiasi condizione è vera, il punteggio complessivo viene forzato a 0.0 e lo stato è fail. Questa logica di “interruttore di sicurezza” (Kill Switch) impedisce che agenti ad alte prestazioni che saltano la conformità superino la valutazione.

critical_fail:
  - condition: "missing disclosure"
    trigger: "no recording consent in first 60 seconds"
  - condition: "identity verification skipped"
    trigger: "sensitive action performed without verification"
  - condition: "prohibited data captured"
    trigger: "full payment details or secret codes present"

Suggerimento professionale: Valutare i “falli critici” prima di eseguire tutti i pesi di valutazione fa risparmiare token di calcolo su GPU. Se una chiamata non supera la conformità, spesso non serve misurare l’empatia.

Figura 2: matrice di valutazione multidimensionale

4. Formato degli intervalli di evidenza (JSON)

Si fidi, ma verifichi. L’LLM deve citare le proprie fonti. Gli intervalli di evidenza devono puntare a intervalli esatti del testo della trascrizione.

{
  "label": "compliance.identity_verification",
  "turn_index": 12,
  "span": "I need to verify your identity",
  "start_char": 0,
  "end_char": 34,
  "confidence": 0.86
}

5. Algoritmo di valutazione (pseudocodice)

if any critical_fail => status = fail, score = 0.0
else score = sum(weight_i * score_i)
status = pass if score >= 0.80 else review

6. Schema di output (JSON)

Questo è il payload che la sua API dovrebbe restituire alla dashboard del frontend.

{
  "call_id": "uuid",
  "overall_score": 0.84,
  "status": "pass",
  "dimensions": [
    {
      "label": "compliance.identity_verification",
      "score": 1.0,
      "evidence": [
        {
          "turn_index": 0,
          "span": "I need to verify your identity",
          "start_char": 29,
          "end_char": 63
        }
      ]
    }
  ],
  "flags": ["none"],
  "summary": "Verification completed, intent resolved, no compliance gaps detected."
}

Figura 3: output JSON con intervalli di evidenza

7. Modello di prompt per LLM (testo)

L’ingrediente segreto sta nell’ingegneria dei prompt. Usi il “Chain of Thought” (CoT) per migliorare il ragionamento prima di generare il JSON.

SYSTEM: You are a QA scoring engine for call transcripts.

INSTRUCTIONS:
1. Analyze the transcript against the provided YAML dimensions.
2. Check for CRITICAL FAIL conditions first.
3. For each dimension, locate specific evidence strings in the text.
4. Score each dimension 0.0 to 1.0 based on the evidence.
5. Return JSON only, no prose.

FORMATTING:
- Use the provided Output Schema.
- Do not include markdown keys like ```json.
- Escaping: Ensure all strings are properly escaped for valid JSON.

8. Set minimo di valutazione (YAML)

Come si fa il QA del QA stesso? Costruisca una suite di test unitari per i suoi prompt.

tests:
  - case: missing_disclosure
    expected_status: fail
    expected_overall_score: 0.0
  - case: verified_high_quality
    expected_status: pass
    expected_overall_score_min: 0.8
  - case: intent_not_resolved
    expected_status: review
    expected_dimension: qa.intent_resolution