DiDi 컨택센터 QA, Amazon Bedrock으로 블랙박스를 대체하다

DiDi는 의도 확인 정확도가 38%에 그치자 불투명한 품질 보증 도구를 교체했다. 새 DiDi 컨택센터 QA 시스템은 이 수치를 86%까지 끌어올린 것으로 알려졌다.

이 회사는 International Business Group을 위해 AWS와 함께 대체 시스템을 구축했다. 이 시스템은 차량 호출, 음식 배달, 금융 서비스 전반의 스페인어 및 포르투갈어 고객 지원 대화를 처리한다. 또한 규정 준수 수준을 평가하고 새롭게 부상하는 고객 불만을 찾아낸다.

이는 단순히 또 하나의 기업이 고객 지원에 대규모 언어 모델을 추가한 사례가 아니다. DiDi는 중요한 내부 통제 기능을 외부 공급업체에서 자체 팀이 점검하고 수정할 수 있는 아키텍처로 옮겼다. 따라서 핵심 경쟁 구도는 불투명한 아웃소싱 자동화와 투명한 자체 소유 AI 사이에 있다.

AWS와 DiDi는 2026년 9월 8일 컨택센터 QA 사례 연구를 통해 이 시스템을 공개했다. 대부분의 성능 수치는 DiDi의 프로덕션 검증에서 나온 것으로, 독립적인 감사를 거치지는 않았다.

그럼에도 결과는 주목할 만하다. 좁게 제한된 컨텍스트, 결정론적 검증, 구조화된 출력이 프롬프트를 반복적으로 고쳐 쓰는 것보다 더 중요할 수 있음을 보여주기 때문이다.

DiDi 컨택센터 QA 내부에서 달라진 점

DiDi는 하나의 모델을 다른 모델로 교체한 것이 아니다. 서로 다른 역할과 증거 요건을 지닌 세 개의 통제된 파이프라인으로 품질 보증을 분리했다.

첫 번째 파이프라인은 의도를 검증한다. 고객 서비스 담당자는 각 대화에 문의 사유를 지정하며, 이는 해당 사례를 DiDi의 계층형 분류 트리 안에 배치한다. 시스템은 지정된 사유가 고객이 실제로 논의한 내용과 일치하는지 확인한다.

라벨이 잘못된 것으로 보이면 파이프라인은 대체 라벨을 추천한다. 또한 기존 범주가 적절하지 않아 “Other”로 분류된 대화도 검토한다. 이러한 사례는 분류 체계 자체의 빈틈을 드러낼 수 있다.

두 번째 파이프라인은 규정 준수를 평가한다. 동일한 대화에서 운영 인사이트를 추출하면서 여러 품질 기준을 채점한다. DiDi는 프로덕션 검증 기간 중 평균 규정 준수 채점 정확도가 90%를 넘었다고 밝혔다.

세 번째 파이프라인은 Voice of Customer 데이터를 분석한다. Voice of Customer, 즉 VOC는 고객 문제, 감정, 결과, 반복되는 원인에 관한 집계된 증거를 뜻한다. DiDi는 운영팀이 전개 중인 패턴을 파악해야 할 때 이 파이프라인을 온디맨드로 활용한다.

라이브 채팅 기록과 전화 통화 녹취는 먼저 전처리 계층으로 들어간다. 통화의 음성-텍스트 변환 결과는 채팅에 사용하는 것과 같은 대화 형식으로 정규화된다. 이후 생성된 기록은 적절한 QA 파이프라인으로 이동한다.

이 공통 스키마는 중요하다. 음성과 채팅의 차이 때문에 모든 후속 분석 구성 요소가 자체 수집 로직을 구현해야 해서는 안 된다. 시스템은 채널 처리를 뒤따르는 추론 작업과 분리한다.

기업들에 따르면 DiDi의 국제 사업은 14개 국가 및 지역에서 운영된다. 지원 조직은 세 개 사업 부문에서 수천만 명의 사용자를 대상으로 스페인어와 포르투갈어 대화를 처리한다.

이 정도 규모에서는 수동 검토로 일부 상호작용만 살펴볼 수 있다. 그러나 아웃소싱 대안에도 문제가 있었다. DiDi는 이전 시스템이 과거 판단을 설명하거나 신속한 변경을 지원할 만큼 충분한 추론 근거를 제공하지 않았다고 말한다.

실패한 규정 준수 점수는 코칭, 감사, 운영 우선순위에 영향을 줄 수 있다. 잘못된 의도 라벨은 고객이 도움을 요청하는 이유에 관한 보고서를 왜곡할 수 있다. 따라서 설명되지 않는 판단은 개발자에게 단지 불편한 문제가 아니다.

대체 시스템은 각 모델 판단에 추론 체인을 연결한다. 검토자는 점수의 명시된 근거를 확인하고 원래 대화를 검토하며, 결정을 적용 가능한 규칙과 비교할 수 있다.

이러한 추적 가능성은 이 글의 핵심 긴장을 만든다. 시스템을 DiDi 내부로 가져오면 가시성과 통제력은 높아지지만, 검증, 보안, 구성, 지속적인 정확성에 대한 책임도 DiDi가 지게 된다.

DiDi는 이제 결과를 형성하는 정의를 직접 소유한다. 또한 그러한 정의가 불완전하거나 잘못됐을 때의 결과도 감당한다.

더 많은 프롬프트 튜닝보다 컨텍스트 분리가 효과적이었던 이유

보고된 가장 큰 정확도 향상은 모델에 더 많은 정보를 제공한 결과가 아니라, 적절한 순간에 더 적은 정보를 보여준 결과였다.

DiDi의 초기 의도 검증 설계는 직관적인 접근을 따랐다. 전체 문의 사유 트리를 대화 옆에 제공하고, 모델에 담당자가 선택한 라벨을 판단하도록 요청했다.

그러면 모델은 선택된 라벨을 가능한 모든 대안과 비교했다. 조금이라도 더 정확해 보이는 범주를 발견하면, 달리 합리적인 선택도 거부하는 경향을 보였다.

이 동작은 과도한 교정을 일으켰다. 최선의 라벨을 찾도록 지시받은 모델은 기존 라벨이 수용 가능한지를 묻는 모델과 다르게 행동할 수 있다. 하나의 프롬프트 안에서 이 결정을 결합하면 둘 사이의 구분이 흐려진다.

DiDi는 여러 차례의 프롬프트 튜닝으로도 문제가 해결되지 않았다고 밝혔다. 팀은 모델에 잘못된 의사결정 환경이 주어졌다는 결론을 내렸다.

재설계된 의도 파이프라인은 검증과 분류를 분리한다. 검증 단계에서 모델은 대화와 담당자의 현재 문의 사유만 받는다. 이 라벨이 해당 상호작용에 합리적으로 부합하는지를 판단한다.

전체 분류 트리는 이 단계에서 숨겨진다. 이러한 정보 격리는 모델이 더 좁은 질문에 답하기 전에 미세하게 더 나은 대안을 찾는 일을 방지한다.

검증이 실패한 경우에만 분류 단계가 열린다. 이때 모델은 첫 단계의 추론 결과와 함께 전체 분류 체계를 받는다. 다른 범주를 추천하고 신뢰도 점수와 근거를 제공한다.

DiDi는 “Other” 라벨을 별도의 3단계 프로세스로 처리한다. 시스템은 먼저 적합한 일치 항목을 찾기 위해 동일 계층의 범주를 검색한다. 로컬 분기에 답이 없으면 전체 트리를 검색한다.

어느 검색에서도 적절한 범주가 나오지 않으면 파이프라인은 분류 체계의 संभाव한 빈틈을 식별한다. 이후 대화를 부적절한 기존 범주에 억지로 넣는 대신 운영자가 라벨을 추가하도록 제안할 수 있다.

DiDi에 따르면 이 2단계 설계는 의도 검증 정확도를 38%에서 86%로 높였다. 이는 회사가 밝힌 프로덕션 검증 기준으로 48%포인트 상승이다.

이 메커니즘은 엔터프라이즈 AI 팀에 실질적인 교훈을 제시한다. 더 많은 컨텍스트가 자동으로 더 나은 컨텍스트를 의미하지는 않는다. 추가 선택지는 모델이 해결하는 것으로 보이는 작업 자체를 바꿀 수 있다.

이는 많은 엔터프라이즈 프롬프트가 효율을 위해 여러 의사결정을 결합한다는 점에서 중요하다. 하나의 요청이 모델에게 대화 분류, 결과 정당화, 정책 준수 확인, 사례 요약, 조치 권고를 모두 요구할 수 있다.

추가되는 각 목표는 지침과 증거가 서로 간섭할 기회를 하나 더 만든다. 또한 개발자가 어떤 부분의 컨텍스트가 답변을 바꿨는지 쉽게 식별할 수 없기 때문에 실패 분석도 어려워진다.

DiDi의 접근법은 대신 컨텍스트를 애플리케이션 아키텍처의 일부로 취급한다. 기존 소프트웨어가 변수와 상태에 대한 접근을 제어하듯, 팀은 각 의사결정 지점에서 어떤 정보가 보이게 할지 결정한다.

이 설계는 더 명확한 실패 경계도 만든다. 의심스러운 검증 결과는 첫 번째 단계의 문제다. 부적절한 대체 라벨은 두 번째 단계의 문제다. 누락된 범주는 분류 체계 거버넌스의 문제다.

이 결과가 다단계 시스템이 항상 단일 프롬프트보다 뛰어나다는 보편적 주장은 아니다. 추가되는 각 단계는 지연 시간, 운영 복잡성, 모니터링해야 할 구성 요소를 늘린다.

DiDi는 표본 크기, 클래스 분포, 신뢰 구간, 언어 및 사업 부문별 성능을 공개하지 않았다. 이러한 누락은 다른 컨택센터 QA 시스템과의 비교를 제한한다.

그럼에도 보고된 변화는 일반적인 엔터프라이즈 관행에 도전한다. 팀은 기대에 미치지 못하는 모델 동작에 대응할 때 지침을 늘리거나 파운데이션 모델을 바꾸는 경우가 많다. DiDi는 대신 정보 흐름을 바꿨다.

이는 더 깊은 형태의 프롬프트 엔지니어링이다. 책임을 영리한 문구에서 시스템 설계, 데이터 정의, 명시적 의사결정 경계로 옮긴다.

자체 소유 시스템이 아웃소싱 AI에 가하는 압박

DiDi가 제3자 QA 공급업체에 제기하는 가장 강력한 도전은 모델 정확도 주장이 아니다. 판단 로직이 전략적 인프라가 되었다는 주장이다.

아웃소싱 플랫폼은 구현 작업을 줄일 수 있다. 전사, 평가, 대시보드, 워크플로를 하나의 관리형 제품으로 묶을 수 있다. 구매자는 모든 구성 요소를 직접 유지 관리하지 않아도 된다.

그러나 공급업체가 판단에 도달한 방식을 공개하지 않으면 그 편의성은 제약이 된다. DiDi는 이전 솔루션이 충분한 감사 추적 없이 QA 결정을 내렸다고 말한다.

기준이 바뀌면서 이 한계는 더 심각해졌다. 차량 호출 서비스의 스페인어 지원은 금융 서비스의 포르투갈어 지원과 반드시 같은 기준을 사용하지 않는다. 새로운 정책은 또 다른 조합을 만든다.

공급업체가 통제하는 구현에서는 이러한 기준이 프로덕션에 반영되기 전에 맞춤 변경, 재학습 또는 제품 업데이트가 필요할 수 있다. 그 사이에는 이전 규칙과 새 규칙이 공존할 수 있다.

DiDi는 정책 정의를 외부 구성으로 옮겼다. 평가 파이프라인은 하나의 프롬프트 템플릿을 사용한 뒤, 각 티켓에 맞는 언어, 사업 부문, 기준 정의, 통과 규칙, 실패 규칙을 주입한다.

새 기준을 추가하기 위해 언어별 프롬프트를 모두 다시 작성할 필요는 없다. 운영자가 구성을 업데이트하면 애플리케이션은 대화를 받을 때 필요한 컨텍스트를 조합한다.

파이프라인은 한 번의 모델 호출에서 여러 규정 준수 항목을 평가한다. 또한 문제 해결 및 고객 만족도 관련 측정치를 포함한 구조화된 비즈니스 인사이트도 반환한다.

Amazon Bedrock Tool Use는 응답을 정의된 JSON 구조로 제한한다. 각 채점 항목에는 판단과 이에 수반되는 근거가 담긴다. 관련 tool-use 기능은 애플리케이션이 예상되는 도구 입력을 설명하고 결과 구조화 데이터를 처리할 수 있게 한다.

구조화된 출력은 응답 형식 문제만 해결한다. 유효한 JSON이 기본 점수가 정확하다는 보장은 아니다. 따라서 DiDi는 생성 후 결정론적 검증을 추가한다.

예를 들어 모델은 संभाव한 철자 오류를 식별할 수 있다. 애플리케이션 코드는 이후 담당자의 메시지에 있는 오류만 집계하고, 검증된 수치에 정의된 임계값을 적용한다.

시스템은 응답 대기 시간도 코드로 계산한다. 타임스탬프에서 추론하도록 모델에 요청하는 대신, 해당 값을 프롬프트에 주입한다.

이 하이브리드 패턴은 의미론적 판단을 언어 모델에, 계산 가능한 사실을 기존 소프트웨어에 맡긴다. 직접 계산으로 재현 가능한 답을 얻을 수 있는 곳에서 확률적 생성을 사용하는 일을 피한다.

이 구분은 자체 소유 접근법의 핵심이다. DiDi는 어떤 결정이 모델에 속하는지, 어떤 결정이 코드에 속하는지, 어떤 결정이 비즈니스 구성에 의존하는지를 점검할 수 있다.

이 아키텍처는 Amazon Bedrock이 공통 인터페이스를 통해 여러 파운데이션 모델을 제공하기 때문에 이를 활용한다. DiDi는 각 파이프라인을 다른 공급업체별 통합 방식으로 다시 구축하지 않고도 모델 선택을 변경할 수 있다고 밝혔다.

모델 이식성에는 여전히 한계가 있다. 모델마다 프롬프트와 스키마를 다르게 해석하므로, 모델을 변경하려면 새로운 평가가 필요하다. 공통 API는 일부 통합 작업을 줄여주지만 동작까지 상호 교환 가능하게 만들지는 않는다.

보안은 또 다른 압박 지점이다. 고객 대화에는 이름, 연락처 정보, 금융 세부 정보, 위치 데이터, 민감한 불만 사항이 포함될 수 있다. 이러한 기록을 AI 워크플로에 옮기면 거버넌스가 필요한 시스템의 범위가 확장된다.

DiDi는 이 배포 환경이 AWS PrivateLink를 통한 VPC 엔드포인트, 암호화, 세분화된 Identity and Access Management 제어를 사용한다고 밝혔다. AWS는 비공개 연결을 통해 인터넷 게이트웨이 또는 공인 IP 주소 없이 Bedrock에 연결할 수 있다고 문서화했다.

이 시스템은 모델 추론 전에 Amazon Bedrock Guardrails도 적용한다. 개인 식별 정보를 마스킹하고, 충분한 근거가 없는 답변을 표시하기 위해 컨텍스트 기반 근거성 검사를 사용한다.

AWS는 Guardrails를 민감한 정보, 금지 주제, 원치 않는 콘텐츠 등을 포함한 영역에서 프롬프트와 응답을 평가하는 정책으로 설명한다. 가드레일 제어는 구성된 정책에 따라 콘텐츠를 차단하거나 마스킹할 수 있다.

이러한 조치가 거버넌스 업무를 없애지는 않는다. DiDi는 고객 데이터에 대한 접근, 보존, 에스컬레이션, 검토, 지역별 처리 규칙을 여전히 정의해야 한다.

동일한 부담은 비즈니스 로직에도 적용된다. 투명한 시스템을 소유한다는 것은 분류 체계, 평가 기준, 검증 세트, 모니터링 프로세스를 유지해야 한다는 뜻이다. 회사는 벤더의 불투명성을 내부 책임으로 바꾼 셈이다.

따라서 타사 벤더는 양쪽에서 압박을 받는다. 관리형 제품의 편의성과 함께, 엔터프라이즈 고객이 중요한 판단을 신뢰할 수 있을 만큼의 근거, 구성 가능성, 제어 기능을 제공해야 한다.

그 대응이 전체 코드 공개일 필요는 없다. 벤더는 의사결정 추적 기록, 버전 관리되는 규칙, 평가 도구, 내보낼 수 있는 결과, 모델 출력과 결정론적 검사 간의 더 명확한 분리를 제공할 수 있다.

DiDi의 사례는 단순한 정확도 대시보드만으로는 더 이상 충분하지 않음을 시사한다. 구매자는 각 점수가 어떤 모델, 프롬프트 버전, 정책 정의, 후처리 규칙으로 생성됐는지 점점 더 알고자 한다.

이 요구 사항은 관측 가능성을 제품 기능으로 바꾼다. 또한 충분한 엔지니어링 역량과 고도로 특화된 운영 환경을 갖춘 기업에는 내부 소유 방식의 매력을 높인다.

정확도 수치가 보여주지 않는 것

보고된 개선은 의미가 있지만, 공개된 근거만으로는 이 시스템이 모든 시장, 언어, 범주 또는 변화하는 정책 전반에서 어떻게 작동하는지 입증할 수 없다.

38%와 86%의 의도 관련 수치는 DiDi의 프로덕션 검증에서 나왔다. AWS의 설명은 테스트한 대화 수나 평가자가 정확한 결과를 어떻게 정의했는지는 공개하지 않는다.

또한 스페인어와 포르투갈어별 정확도도 제공하지 않는다. 성능은 억양, 지역 어휘, 지원 채널, 사업 부문, 분류 깊이에 따라 달라질 수 있다.

클래스 균형도 중요하다. 일반적인 차량 호출 질문이 지배적인 데이터셋은 빈도가 낮은 금융 서비스 사례에서의 취약한 결과를 가리면서도 강력한 전체 점수를 낼 수 있다.

90%를 넘는 컴플라이언스 점수에도 같은 주의가 필요하다. 공개된 자료는 포함된 기준의 수, 각 기준이 동일한 가중치를 받았는지, 사람이 의견 불일치를 어떻게 해결했는지를 밝히지 않는다.

정확도는 서로 다른 오류 비용도 감출 수 있다. 철자 위반을 잘못 판단하는 것은 불편한 일이지만, 규제 대상 금융 서비스 행위와 관련된 부정확한 평가는 더 심각한 결과를 초래할 수 있다.

따라서 프로덕션 평가는 단일 평균뿐 아니라 개별 기준에 대한 정밀도와 재현율을 추적해야 한다. 또한 인간 검토자와 자동화 시스템 간의 불일치도 모니터링해야 한다.

추론 추적 기록은 검토자가 결정을 조사하는 데 도움이 되지만, 증거는 아니다. 언어 모델은 틀린 답변에 대해서도 그럴듯한 설명을 생성할 수 있다.

결정론적 검증 계층은 측정 가능한 사실에 대해서는 이 위험을 줄인다. 하지만 모든 정책 판단을 계산으로 바꿀 수는 없다. 어조, 해결 품질, 공감, 맥락적 적절성은 여전히 해석을 필요로 한다.

가드레일은 또 다른 한계를 도입한다. 민감한 정보를 필터링하고 근거성을 검사할 수 있지만, AWS 역시 기반 보호 장치가 변함에 따라 지속적인 검증을 권고한다. 구성된 제어 기능을 영구적인 보장으로 여겨서는 안 된다.

특히 이의가 제기된 점수와 고위험 기준에서는 인간의 감독이 계속 필요하다. 검토 팀에는 개별 결정과 그 기반 규칙을 모두 수정할 수 있는 이의 제기 경로가 필요하다.

공개된 설명에는 운영 측정치도 부족하다. 모델 지연 시간, 처리 비용, 재정의율, 검토자 업무량, 에스컬레이션이 필요한 대화의 비율은 보고하지 않는다.

이러한 수치는 향상된 모델 정확도가 더 나은 운영으로 이어지는지 보여줄 것이다. 정확한 시스템도 응답이 지나치게 느리거나, 빈번한 수동 수정이 필요하거나, 전체 물량에서 비용이 과도해지면 어려움을 겪을 수 있다.

다른 구현 사례와의 비교는 유용한 관점을 더한다. 금융 서비스 제공업체 Empower는 이전에 매일 수천 건의 대화 기록을 처리한 또 다른 Bedrock 기반 QA 배포 환경을 설명한 바 있다.

그 자동화 QA 시스템은 Amazon Connect Contact Lens와 Bedrock을 결합했다. Empower는 QA 적용 범위를 20배 확대하고 검토 시간을 며칠에서 몇 분으로 줄였다고 밝혔다.

두 구현을 직접 비교할 수는 없다. Empower는 AWS 컨택센터 스택에서 사전에 비식별화된 전사본을 사용한 반면, DiDi는 자체 전처리와 3개 파이프라인 아키텍처를 설명했다.

그럼에도 두 사례는 같은 경쟁 방향을 가리킨다. 기업은 더 많은 대화를 검토하고, 평가를 설명하며, 고객 문제와 운영 조치 사이의 간격을 줄이기를 원한다.

DiDi의 차별화된 기여는 실패한 설계에 대한 설명이다. 전체 분류 체계를 한 번의 호출에 넣자, 프롬프트를 반복 조정했음에도 의도 검증 성능이 저조했다.

이 실패는 단순한 벤더 성공 사례보다 이 사례를 더 유용하게 만든다. 모델 접근성만으로는 신뢰할 수 있는 품질 보증이 제공되지 않는다는 점을 보여준다.

남은 불확실성은 유지 관리와 관련된다. 분류 체계는 변하고, 고객 행동은 이동하며, 정책 문구는 진화한다. 모델 제공업체도 사용 가능한 버전과 지원 기능을 업데이트한다.

DiDi는 각 언어, 채널, 사업 부문, 고위험 기준의 대표 사례를 보존하는 버전 관리 평가 세트가 필요하다. 그렇지 않으면 한 영역의 구성 개선이 다른 영역의 성능을 조용히 떨어뜨릴 수 있다.

유사한 시스템을 구축하는 팀은 각 릴리스의 근거를 보존해야 한다. 검색 가능한 엔지니어링 지식 베이스는 생성된 설명을 사실의 근거로 취급하지 않으면서 요구 사항, 테스트 결과, 프롬프트 버전, 사고 검토를 연결할 수 있다.

이 관행은 투명성의 실질적인 약속을 뒷받침한다. 가시성은 팀이 무엇이 바뀌었는지, 왜 바뀌었는지, 새 버전이 어떻게 작동했는지를 재구성할 수 있을 때만 유용하다.

다음 시험대는 DiDi가 통제력을 확장할 수 있는지 여부다

DiDi의 아키텍처가 QA를 위한 지속 가능한 운영 체계가 될지, 아니면 공개 검증이 제한된 성공적인 배포 사례로 남을지를 결정할 신호는 세 가지다.

첫 번째 신호는 추가 언어와 사업 부문 전반의 성능이다. DiDi는 현재 적용 범위를 넘어 시스템을 확장할 계획이라고 밝혔다.

이 확장은 동적 구성이 실제로 유지 관리 작업을 제한하는지 시험하게 된다. 새로운 언어는 번역된 지침 이상의 변화를 초래한다. 지역별 표현, 문화적 기대, 전사 오류, 서로 다른 정책 요구 사항을 도입할 수 있다.

새 배포 환경 전반에서 정확도가 안정적으로 유지된다면, 이는 DiDi의 컨텍스트 관리 논지를 강화할 것이다. 큰 하락이 발생한다면 현재의 성과가 기존 스페인어 및 포르투갈어 검증 환경에 크게 의존한다는 뜻일 수 있다.

두 번째 신호는 파이프라인 간 통합이다. DiDi는 의도 검증, 컴플라이언스 점수 산정, VOC 분석을 더 깊게 연결할 계획이다.

현재 각 파이프라인은 뚜렷한 목적을 가진다. 통합은 불만 추세가 누락된 분류를 드러내고, 반복된 분류 실패가 분류 체계를 업데이트하며, 컴플라이언스 결과가 코칭에 반영되는 피드백 루프를 만들 수 있다.

오류도 확산될 수 있다. 잘못된 이슈 클러스터가 분류 체계 변경에 영향을 주고, 이는 다시 의도 검사와 경영 보고서에 영향을 미칠 수 있다.

따라서 성공적인 통합에는 데이터 계보가 필요하다. 모든 후속 권고는 이를 생성한 대화, 추출 필드, 구성 버전, 모델 출력에 대한 링크를 유지해야 한다.

세 번째 신호는 정확도를 넘어선 운영 근거다. 향후 공개에는 인간 재정의율, 거짓 양성 패턴, 처리 지연 시간, 검토 시간, 범주별 성능이 포함되어야 한다.

이러한 측정치는 초기 검증 기간 이후에도 시스템이 유용한지 보여줄 것이다. 또한 구매자가 자체 소유 아키텍처와 관리형 컨택센터 제품을 비교하는 데 도움이 된다.

VOC 분석은 가장 명확한 즉각적 시험을 제공한다. DiDi는 라틴아메리카 시장 전반에서 취소 수수료 관련 불만이 급증했다고 설명했다. 운영 담당자는 분석을 실행했고, 이 시스템은 다국어 대화를 클러스터링해 몇 분 안에 구조화된 보고서를 생성했다.

파이프라인은 각 대화에서 필드를 병렬로 추출하는 것으로 시작한다. 이러한 필드에는 이슈 유형, 감정, 결과, 가능한 근본 원인이 포함된다.

그런 다음 임베딩 모델은 이슈 레이블 간의 의미적 유사성을 측정한다. 임베딩은 관련된 의미를 서로 가깝게 배치하는 수치 표현으로, 시스템이 서로 다르게 표현된 불만을 병합할 수 있게 한다.

이 단계는 생성형 출력 대신 거리 계산과 빈도 순위를 사용한다. DiDi는 이 설계가 클러스터링을 결정론적이고 재현 가능하게 만든다고 밝혔다.

언어 모델은 보고서 생성 중 빈도가 높은 클러스터만 받는다. 더 작고 구조화된 근거 세트에서 경영진 요약을 만들고, 문제점을 식별하며, 조치를 제안한다.

이 파이프라인도 다시 정보 격리를 적용한다. 모델은 하나의 과도하게 큰 프롬프트로 수천 건의 원시 대화를 받지 않는다. 각 단계는 다음 결정에 필요한 근거를 좁힌다.

DiDi는 이 과정이 이전에는 수 시간이 걸리던 작업을 몇 분으로 줄였다고 밝혔다. 향후 보고가 운영 팀이 더 빠르게 조치했는지 또는 반복되는 고객 피해를 예방했는지를 보여준다면 이 주장은 더욱 설득력을 얻을 것이다.

속도만이 목표는 아니다. 근본 원인이 틀린 신속한 보고서는 자원을 잘못된 개입에 투입하게 할 수 있다.

가장 강력한 배포는 더 빠른 탐지와 측정 가능한 결과를 결합할 것이다. 여기에는 반복 문의 감소, 더 나은 이슈 해결, 불만 재발 감소, 정책 문제의 더 빠른 수정 등이 포함될 수 있다.

개발자에게 가장 즉각적인 교훈은 프롬프트를 다듬기 전에 모델 경계를 설계하라는 것이다. 각 호출에 필요한 근거, 스키마가 필요한 출력, 코드에서 계산해야 하는 사실을 결정해야 한다.

엔터프라이즈 구매자도 벤더에 같은 수준의 명확성을 요구해야 한다. 버전 관리되는 규칙, 감사 가능한 결정, 범주별 검증, 에스컬레이션 워크플로, 대화 데이터의 민감도를 반영하는 접근 제어를 요청해야 한다.

지식 근로자도 이 패턴이 지원 업무를 넘어 확장되므로 관심을 가져야 한다. 문서를 분류하고, 업무를 평가하거나, 반복 이슈를 요약하는 모든 시스템은 관련 없는 선택지를 보거나 양립할 수 없는 작업을 결합할 때 문제를 겪을 수 있다.

따라서 DiDi의 컨택센터 QA는 모델 성능만큼이나 조직 역량을 시험하는 일이다. 이 회사는 판단 계층 전체를 외주에 맡기는 대신, 맥락·정의·검증을 직접 책임지고 있다.

언어, 정책, 모델이 변화하는 상황에서도 이러한 책임 구조가 안정적인 결과를 낼 수 있을까? 확장 지표, 파이프라인 간 증거 추적 기록, 그리고 인간의 재정의율을 지켜봐야 한다. 이러한 신호는 투명한 엔터프라이즈 AI가 시간이 지날수록 블랙박스 방식보다 뛰어난 성과를 낼 수 있는지를 보여줄 것이다.