에이[인턴] Product Engineer
0.0에이아이씨엑스
인턴·신입근거: 상담원에게 자연스럽게 전환하는 AI 기반 고객 응대 제품
35일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
AICX 의 Voice AI 상담은 응답 속도·대화 흐름·상담원 전환·통화 이력·개인정보 처리가 모두 제품 경험에 얽히기 때문에, 자동 처리와 전환을 가르는 경계 케이스가 여행 예약 상담이라는 AICX 의 운영 현장에서만 현실적으로 나옵니다. 이 포트폴리오는 의도 분류·도구 호출·상담원 전환을 상태머신으로 고정하고 근거로 채점하는 기술을 보여주며, 음성 인식(STT) 자체나 실시간 통화 인프라 전문성은 주장하지 않습니다. 전사는 텍스트로 가정하고, 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
전화 상담 전사에서 예약 조회·변경·취소 같은 의도를 분류하고, 처리 가능한 문의는 예약 조회·변경 도구 호출로 끝냅니다.
예약을 특정할 수 없거나 신뢰도가 낮거나 정책 예외인 경우를 규칙으로 판정해, 자동 처리 대신 상담원에게 자연스럽게 전환합니다.
환불·변경 규정 문의는 정책 문서를 근거로 인용해 규정만 안내하고, 실제 실행은 도구 호출이나 상담원 전환으로 분리합니다.
마이리얼트립 자회사 AICX 의 Voice AI 상담 운영에서, 전화 상담 전사를 받아 의도를 분류하고 처리 가능한 문의는 예약 조회·변경 도구 호출로 끝내며 애매하거나 정책에 걸리는 문의는 상담원에게 전환하는 관리자 페이지입니다. 의도 분류·도구 호출·상담원 전환을 한 상태머신으로 묶고, 각 결정에 어떤 필드가 근거였는지(예약 번호 유무·의도 신뢰도·정책 예외)를 함께 표시합니다.
전화 상담에서 같은 예약 조회·변경 요청을 반복 처리하면서, 무엇까지 자동으로 끝내고 어디서부터 상담원에게 넘길지 기준이 사람마다 달라 들쑥날쑥하던 운영 담당자가, 의도와 전환 기준을 규칙으로 고정하고 근거와 함께 결정을 받아보고 싶은 사람입니다.
의도 분류와 도구 호출, 상담원 전환 결정을 규칙 상태머신으로 고정하고 각 결정에 근거 필드를 달면, 예약 특정 실패·저신뢰·정책 예외 같은 경우에도 자동 처리와 전환이 일관되게 갈리고 환각이 처리 결정을 통과하지 못한다는 가정입니다.
전화 상담 전사와 예약 메타 더미를 넣으면 의도를 분류하고, 예약을 특정할 수 있고 신뢰도가 높으면 예약 조회·변경 도구 호출(모의)로 끝내며, 예약 특정 실패·저신뢰·정책 예외면 상담원 전환으로 결정하고 각 결정에 근거 필드를 단 상담 결정 콘솔입니다. 전사는 실시간 음성 인식 대신 텍스트 전사를 가정합니다.
1주차 결정을 규칙 정답과 대조해 의도·전환 일치율을 보여주고, 환불·변경 답변이 인용한 정책 문서가 실제 근거와 맞는지 매칭하며, 사람 검수자가 본 표본과의 일치도를 함께 표시합니다.
로그·모니터링 화면과 SQL 집계로 자동 처리율·상담원 전환율·전환 사유 분포를 보여주고, 백엔드 서비스를 클라우드에 배포해 운영 가능한 상태로 만듭니다.
예약 특정 실패·저신뢰·정책 예외를 섞은 통화 더미를 넣으면 자동 처리와 상담원 전환이 갈리고 근거 필드가 함께 나오는 과정을 시연합니다.
규칙 정답 대비 의도 분류와 전환 결정의 일치율을 보여주며, 단 정답과 데이터를 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
일부러 만든 결측·저신뢰·정책 예외·표기 흔들림 30종을 넣어도 도구 호출 스키마가 깨지지 않고 정해진 결정으로만 떨어지는 강건성을 보여줍니다.
위 수치는 더미데이터 자가채점이며, 실제 자동 처리율과 오전환율은 AICX 실 통화 전사와 실 상담 검수자가 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 게 당연하므로, 예약 특정 실패·저신뢰·정책 예외·표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
이 포트폴리오는 상태머신·도구 호출·상담원 전환 결정 기술을 보여주며, 음성 인식(STT)이나 실시간 통화 인프라 전문성은 주장하지 않습니다.
실제 도입 때는 AICX 실 통화 전사 분포와 사내 정책 문서, 실 상담 검수 기준으로 전환 임계와 정책 규칙이 달라지므로, 의도 enum 과 정책 규칙 교체를 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
여행 고객 전화 상담 전사와 예약 메타 더미로, 예약 번호 결측·낮은 의도 신뢰도·정책 예외·예약 번호 표기 흔들림 같은 하드 케이스를 일부러 섞어 자동 처리와 상담원 전환이 규칙대로 갈리는지 확인합니다.
| call_id | transcript_excerpt | requested_action | booking_id | policy_id | customer_tier | channel_raw | intent_confidence |
|---|---|---|---|---|---|---|---|
| C-2001 | 다음 주 오사카 예약 날짜를 좀 확인하고 싶은데요 | 예약조회 | BK-77120 | — | 일반 | 전화 | 0.94 |
| C-2002 | 예약을 다음 달로 바꾸려고요, 번호는 기억이 안 나는데 | 예약변경 | — | — | 우수 | 전화 | 0.71 |
| C-2003 | 출발이 내일인데 전액 환불 되나요? 규정이 어떻게 되죠 | 환불문의 | BK-80455 | P-refund-24h | 일반 | 전화 | 0.83 |
| C-2004 | 어… 그게 저번에 말한 그거요 그거 처리됐어요? | 일반문의 | — | — | 미확인 | 전화 | 0.38 |
| C-2005 | 예약 취소하고 싶어요 환불까지요 | 예약취소 | BK-79003 | P-cancel-special | 우수 | 전화 | 0.88 |
다음 JSON Schema 에 맞는 통화 세션 행을 더 생성하세요: {"type":"object","properties":{"call_id":{"type":"string"},"transcript_excerpt":{"type":"string"},"requested_action":{"type":"string","enum":["예약조회","예약변경","예약취소","환불문의","일반문의"]},"booking_id":{"type":["string","null"]},"policy_id":{"type":["string","null"]},"customer_tier":{"type":"string","enum":["일반","우수","미확인"]},"channel_raw":{"type":"string"},"intent_confidence":{"type":["number","null"]}},"required":["call_id","transcript_excerpt","requested_action","customer_tier","channel_raw"]} 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: booking_id 를 null 로 둔 예약 특정 실패, intent_confidence 를 0.6 미만으로 둔 저신뢰 의도, policy_id 가 P-cancel-special·P-change-fee 처럼 특수 정책이라 자동 처리 범위를 벗어나는 건, customer_tier 가 미확인인 본인 확인 필요 건, transcript_excerpt 에 예약 번호가 'BK-77120' 대신 '비이케이 칠칠일이공'처럼 음차로 적힌 표기 흔들림, requested_action 이 변경과 환불처럼 둘 섞인 복합 요청. 정상 처리 건과 전환 건이 고루 섞이게 하고, 형식 깨뜨리기 시도(타입 위반) 3건은 데이터가 아니라 별도 목록으로 표시하세요.{"type":"object","properties":{"call_id":{"type":"string"},"transcript_excerpt":{"type":"string"},"requested_action":{"type":"string","enum":["예약조회","예약변경","예약취소","환불문의","일반문의"]},"booking_id":{"type":["string","null"]},"policy_id":{"type":["string","null"]},"customer_tier":{"type":"string","enum":["일반","우수","미확인"]},"channel_raw":{"type":"string"},"intent_confidence":{"type":["number","null"]}},"required":["call_id","transcript_excerpt","requested_action","customer_tier","channel_raw"]}| Python | 전사를 받아 의도 분류·상태머신·도구 호출을 묶는 백엔드 서비스를 구현합니다. |
| AI Agent / tool calling | 예약 조회·변경·취소를 정해진 도구 호출 스키마로 연결하고, 허용되지 않는 호출은 상태머신이 막습니다. |
| LLM | 전사에서 고객 의도를 분류하고 통화 요약을 만들며, 처리 결정 자체는 규칙이 정합니다. |
| RAG | 환불·변경 정책 문서를 근거로 검색해 규정 안내 답변에 인용으로 붙입니다. |
| 상태머신 | 예약 특정 여부·의도 신뢰도·정책 예외를 입력으로 자동 처리와 상담원 전환을 결정론으로 가릅니다. |
| SQL | 자동 처리율·전환율·전환 사유를 집계해 기능 성과를 분석합니다. |
| 로그·모니터링 | 결정마다 의도·근거·전환 사유를 남겨 운영 중 이상을 추적합니다. |
| 클라우드 배포 | 백엔드 서비스를 클라우드에 배포해 운영 가능한 상태로 둡니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 결정을 규칙·정책 정답과 대조해 검증합니다.
✓ pass → 여기서 멈춰도 검증된 완결입니다. 더 키우려면 3주차에서 성과 분석과 클라우드 배포를 다룹니다.
통화 한 건을 받아 의도와 처리 행동(도구 호출·답변·상담원 전환), 호출한 도구나 전환 사유, 그리고 그 결정의 근거가 된 필드를 함께 내보내 규칙 정답과 자동으로 대조할 수 있게 합니다.
{"type":"object","properties":{"call_id":{"type":"string"},"intent":{"type":"string","enum":["예약조회","예약변경","예약취소","환불문의","일반문의"]},"action":{"type":"string","enum":["도구호출","답변","상담원전환"]},"tool":{"type":["string","null"],"enum":["lookup_booking","change_booking","cancel_booking",null]},"escalate_reason":{"type":["string","null"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"value":{"type":["string","number","null"]}},"required":["field","value"]}},"hedge":{"type":["string","null"]}},"required":["call_id","intent","action","evidence"]}[
{
"call_id": "C-2001",
"intent": "예약조회",
"action": "도구호출",
"tool": "lookup_booking",
"escalate_reason": null,
"evidence": [
{
"field": "booking_id",
"value": "BK-77120"
},
{
"field": "intent_confidence",
"value": 0.94
}
],
"hedge": null
},
{
"call_id": "C-2002",
"intent": "예약변경",
"action": "상담원전환",
"tool": null,
"escalate_reason": "booking_id 가 없어 본인 확인과 예약 특정이 필요합니다.",
"evidence": [
{
"field": "booking_id",
"value": null
},
{
"field": "intent_confidence",
"value": 0.71
}
],
"hedge": "예약을 특정할 수 없어 변경 도구를 호출하지 않고 전환했습니다."
},
{
"call_id": "C-2004",
"intent": "일반문의",
"action": "상담원전환",
"tool": null,
"escalate_reason": "의도 신뢰도가 낮고(0.38) 지시 대상이 모호합니다.",
"evidence": [
{
"field": "intent_confidence",
"value": 0.38
}
],
"hedge": "저신뢰 임계값(0.6) 미만이라 자동 처리 대신 전환했습니다(합성 기준)."
},
{
"call_id": "C-2003",
"intent": "환불문의",
"action": "답변",
"tool": null,
"escalate_reason": null,
"evidence": [
{
"field": "policy_id",
"value": "P-refund-24h"
},
{
"field": "booking_id",
"value": "BK-80455"
}
],
"hedge": "정책 문서 P-refund-24h 를 인용해 규정만 안내하고 환불 실행은 하지 않습니다."
},
{
"call_id": "C-2005",
"intent": "예약취소",
"action": "상담원전환",
"tool": null,
"escalate_reason": "특수 정책(P-cancel-special) 적용 건이라 자동 취소 범위를 벗어납니다.",
"evidence": [
{
"field": "policy_id",
"value": "P-cancel-special"
}
],
"hedge": "정책상 예외 건은 상담원 전환으로 고정했습니다."
}
][자동 검증] 1. action 이 규칙 정답(예약 특정 실패나 intent_confidence 0.6 미만이면 상담원전환, 특수 policy_id 면 상담원전환, 그 외 정상 건이면 도구호출)과 일치하는지 대조합니다. 2. action 이 도구호출이면 tool 이 채워지고 의도와 맞는지, 상담원전환이면 escalate_reason 이 있는지 확인합니다. 3. evidence 의 field 와 value 가 입력 통화의 실제 값과 같은지 확인해 근거 없는 결정을 거릅니다. [수동 검증] 1. 복합 요청(변경과 환불이 섞인 건)에서 어떤 의도를 앞세웠는지 hedge 설명이 운영 기준과 맞는지 사람이 봅니다. 2. 정책 인용 답변의 문구가 규정과 어긋나지 않는지 상담 운영자가 spot check 합니다.
근거: 상담원에게 자연스럽게 전환하는 AI 기반 고객 응대 제품