본문으로 건너뛰기

DiDi의 Amazon Bedrock 상담 품질관리 시스템

DiDi가 Amazon Bedrock으로 상담 QA를 재구축해 의도 검증 정확도 86%와 VOC 분석 시간 단축을 달성했습니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

DiDi International Business Group은 Spanish와 Portuguese 상담 데이터를 대상으로 하던 불투명한 외부 QA 솔루션을 Amazon Bedrock 기반의 자체 시스템으로 교체했습니다. 시스템은 대화 데이터를 공통 형식으로 정규화한 뒤 의도 검증, 규정 준수 평가, Voice of Customer 분석이라는 세 파이프라인으로 분기하며, 각 호출에서 모델이 보는 정보의 범위를 정밀하게 통제합니다. 의도 검증 정확도는 38%에서 86%로 높아졌고 규정 준수 점수 정확도는 90%를 넘었으며, VOC 분석은 수작업으로 몇 시간이 걸리던 요약을 몇 분으로 줄였습니다. 핵심 구현은 현재 라벨만 먼저 검증한 뒤 실패할 때만 전체 분류 체계를 제공하는 정보 격리, 외부 설정을 조합하는 동적 프롬프트, 개별 추출·이슈 군집화·보고서 생성으로 나눈 다단계 처리입니다.

섹션별 상세

01
DiDi International Business Group은 14개 국가와 지역에서 ride-hailing, food delivery, financial services를 운영하며 Spanish와 Portuguese 상담을 대량 처리하는 과정에서 외부 QA 솔루션의 불투명성과 낮은 유연성에 부딪혔습니다. 기존 시스템은 판정 근거와 과거 결정의 감사 경로를 제공하지 못했고, 언어·사업 부문·규정 조합이 늘수록 규칙 유지와 일관성 확보가 어려워졌습니다. Amazon Bedrock은 단일 API로 여러 foundation model에 접근하고 Amazon VPC endpoints, AWS PrivateLink, encryption, AWS IAM, Amazon Bedrock Guardrails를 제공해 자체적으로 통제 가능한 구조를 마련하는 기반이 됐습니다.
02
대화 데이터는 live chat와 phone 채널에서 들어오며 phone 녹취는 speech-to-text를 거쳐 채널별 전처리를 통과합니다. 이후 두 채널의 데이터를 공통 conversation schema로 맞춘 뒤 intent, evaluation, VOC 파이프라인으로 병렬 분기하고 각 파이프라인은 구조화된 결과와 판정 근거를 반환합니다. Amazon Bedrock Guardrails는 모델 입력 전 PII를 가리고 contextual grounding checks로 근거 없는 응답을 표시하며, 결정론적 항목은 raw conversation과 코드 기반 post-validation으로 다시 확인합니다.
python
import boto3
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = ""

def build_output_schema(num_criteria):
    """Derive the JSON schema from the checklist size — adding a new compliance item requires only a config change, not a code change."""
    criteria = {
        f"criteria_{i}": {
            "type": "object",
            "properties": {
                "reasoning": {"type": "string"},
                "score": {"type": "integer"},  # 0 = pass, 1 = fail
            },
            "required": ["reasoning", "score"],
        }
        for i in range(1, num_criteria + 1)
    }
    return {
        "type": "object",
        "properties": {"scoring": {"type": "object", "properties": criteria}},
        "required": ["scoring"],
    }

def assemble_prompt(criteria_config, language, business_line):
    """Dynamic assembly: one template covers every language x business-line combination. Context lives in external config, injected at call time."""
    criteria_block = "
".join(
        f"CRITERIA_{i}:
- {c['parameter']}
- PASS: {c['pass']}
- FAIL: {c['fail']}"
        for i, c in enumerate(criteria_config, 1)
    )
    return (
        f"You are a customer service quality auditor for DiDi.
"
        f"LANGUAGE CONTEXT: the conversation is in {language}.
"
        f"BUSINESS CONTEXT: this is a {business_line} service interaction.

"
        f"SCORING CRITERIA TO EVALUATE:
{criteria_block}"
    )

def evaluate(transcript, criteria_config, language, business_line):
    system_prompt = assemble_prompt(criteria_config, language, business_line)
    schema = build_output_schema(len(criteria_config))
    response = bedrock.converse(
        modelId=MODEL_ID,
        system=[{"text": system_prompt}],
        messages=[{"role": "user", "content": [{"text": transcript}]}],
        # Tool Use with a forced tool choice constrains the model to emit
        # schema-valid JSON — every score carries its own reasoning chain.
        toolConfig={
            "tools": [{
                "toolSpec": {
                    "name": "output_result",
                    "description": "Output the structured evaluation result",
                    "inputSchema": {"json": schema},
                }
            }],
            "toolChoice": {"tool": {"name": "output_result"}},
        },
        inferenceConfig={"maxTokens": 8192, "temperature": 0.0},
    )
    for block in response["output"]["message"]["content"]:
        if "toolUse" in block:
            return block["toolUse"]["input"]

외부 설정을 조합해 언어와 사업 부문에 맞는 평가 프롬프트를 만들고, Amazon Bedrock Tool Use로 근거가 포함된 구조화 JSON을 반환받습니다.

03
의도 검증에서 전체 CR Tree와 대화를 한 번에 제공하자 모델이 모든 선택지를 비교하면서 기존 라벨보다 조금 더 세밀한 대안을 찾고도 현재 라벨을 오류로 판단하는 문제가 생겼습니다. DiDi는 contact reason 검증과 Other 라벨 분석을 분리하고, 일반 라벨에는 현재 라벨만 먼저 제공해 합리성을 판단한 뒤 실패한 경우에만 전체 CR Tree와 기존 추론을 전달하는 verify-then-classify 흐름을 적용했습니다. 그 결과 production validation의 intent verification accuracy가 38%에서 86%로 상승했고, Other 티켓은 형제 범주·전체 CR Tree·새 라벨 제안의 세 단계로 분류 체계의 공백까지 찾게 됐습니다.
04
평가 파이프라인은 언어, business line, 평가 기준과 판정 규칙을 외부 설정으로 관리하고 호출 시 하나의 프롬프트 템플릿에 동적으로 주입합니다. Amazon Bedrock Tool Use의 강제된 tool choice는 각 기준의 score와 reasoning을 포함하는 schema-valid JSON을 반환하게 하며, 모델 호출 한 번으로 다수의 compliance 항목과 business insight를 함께 산출합니다. 새 평가 항목이나 언어 또는 사업 부문을 추가할 때 코드와 프롬프트를 조합별로 복제하지 않고 설정만 바꿀 수 있고, production validation에서 compliance scoring accuracy가 90%를 넘었습니다.
05
VOC 파이프라인은 운영팀이 특정 시간대의 유사 상담 묶음을 요청할 때 개별 대화의 issue type, user sentiment, resolution outcome, root cause를 병렬로 추출합니다. 이어서 embedding model이 의미적으로 가까운 이슈 표현을 묶고 티켓 빈도로 순위를 매긴 다음, LLM이 빈도가 높은 군집을 바탕으로 executive summary, pain-point analysis, improvement recommendations를 생성합니다. Latin American 시장에서 cancellation fee 관련 불만이 급증했을 때 이 흐름은 다국어 대화의 주요 원인과 촉발 상황을 몇 분 안에 찾아냈으며, 이전에 수작업으로 몇 시간이 걸리던 요약을 단축했습니다.

이미지 분석

Live chat와 phone 데이터가 전처리와 공통 schema 변환을 거쳐 Intent, Evaluation, VOC 세 파이프라인으로 분기되는 구조도입니다.
Diagram

첫 번째 이미지는 phone 녹취가 STT를 거치고 live chat 데이터와 함께 채널별 preprocessing을 통과한 뒤 Unified Schema로 합쳐지는 흐름을 보여줍니다. 이후 Intent는 verify-then-classify와 Other 분석을, Evaluation은 compliance scoring과 BI insights를, VOC는 티켓별 추출·semantic clustering·report generation을 수행하며 Amazon Bedrock을 통해 구조화된 결과를 만듭니다.

Live chat와 phone 데이터가 전처리와 공통 schema 변환을 거쳐 Intent, Evaluation, VOC 세 파이프라인으로 분기되는 구조도입니다.

언어, 사업 부문, 평가 기준, 전처리된 대화를 동적 프롬프트로 조합해 Amazon Bedrock의 구조화된 평가 결과로 변환하는 파이프라인입니다.
Diagram

두 번째 이미지는 External Configs의 Language Context, Business Line, Evaluation Criteria와 Conversation이 Dynamic Prompt Assembly로 합쳐지는 과정을 나타냅니다. Amazon Bedrock의 Converse API와 Tool Use가 QA Compliance와 BI Insights를 reasoning trace와 함께 반환하고, compliance 결과는 규칙 기반 Programmatic Post-Validation을 추가로 통과합니다.

언어, 사업 부문, 평가 기준, 전처리된 대화를 동적 프롬프트로 조합해 Amazon Bedrock의 구조화된 평가 결과로 변환하는 파이프라인입니다.

용어 해설

Context Management
LLM 호출마다 모델에 전달하는 정보의 범위와 순서를 통제하는 방식입니다. 이 사례에서는 현재 분류만 검증할 때 전체 분류 체계를 숨기고, 오분류가 확인된 뒤에만 전체 체계를 제공해 불필요한 재분류를 줄였습니다. 프롬프트 문구보다 입력 정보의 격리가 정확도에 더 큰 영향을 주는 핵심 원리로 활용됐습니다.
Tool Use
LLM이 정해진 도구의 입력 스키마에 맞춰 구조화된 결과를 반환하도록 제한하는 기능입니다. DiDi는 Amazon Bedrock의 Tool Use와 강제된 tool choice를 사용해 각 평가 결과를 schema-valid JSON으로 받았습니다. 각 점수에 판정 근거를 함께 저장할 수 있어 후속 검증과 사람의 감사가 쉬워졌습니다.
Embedding Model
텍스트를 의미를 반영한 벡터로 변환해 문장이나 표현 사이의 유사도를 계산하는 모델입니다. VOC 파이프라인은 추출된 이슈 유형을 벡터화하고 의미적으로 가까운 표현을 묶어 동의어성 표현을 통합했습니다. 이 단계는 생성형 LLM 대신 임베딩 거리와 빈도 순위를 사용해 결과의 재현성을 높였습니다.
프로그램 기반 사후 검증(Programmatic Post-Validation)
LLM의 판정을 원문 대화와 결정론적 규칙으로 다시 확인하는 처리 단계입니다. DiDi는 상담원 메시지 안의 철자 오류와 응답 대기 시간처럼 코드로 계산할 수 있는 사실을 별도로 검증하거나 산출했습니다. 모델이 자체적으로 센 오류 수나 추정한 수치만으로 최종 점수를 확정하지 않도록 만든 안전장치입니다.

기술

  • Amazon Bedrock
  • Amazon VPC
  • AWS PrivateLink
  • AWS Identity and Access Management (IAM)
  • Amazon Bedrock Guardrails
  • Amazon Bedrock Tool Use
  • speech-to-text
  • embedding model
  • Amazon Bedrock Converse API
  • Python

활용 사례

  • 다국어 고객센터 QA
  • 상담 의도 및 contact reason 검증
  • 규정 준수 점수 산출
  • 상담원 서비스 품질 개선
  • Voice of Customer 트렌드 탐지
  • 대규모 상담 데이터의 이슈 군집화
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 09. 09.수집 2026. 09. 09.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.