AI 챗봇은 도입보다 그다음이 어렵습니다 — 오답 관리와 답변 품질 운영

"챗봇을 열었는데 이상한 답을 합니다." 도입 후 한 달쯤 지나 가장 자주 듣는 말입니다. 구축 단계에서는 예상 질문 목록을 만들어 검증하지만, 실제 사용자는 그 목록에 없는 방식으로 묻습니다. 도입은 프로젝트고 품질은 운영이라 성격이 다릅니다.

루미브리즈가 챗봇을 넘긴 뒤 실제로 하는 일을 정리했습니다.

오답은 세 갈래로 들어옵니다

"틀린 답"을 하나로 묶으면 고칠 수가 없습니다. 원인이 다르면 대응도 다릅니다.

• 근거 없이 지어낸 답 — 검색된 문서에 답이 없는데도 그럴듯하게 문장을 만든 경우입니다. 검색 결과가 비었을 때 모른다고 답하도록 설계돼 있지 않으면 반드시 생깁니다.
• 오래된 문서를 인용한 답 — 지식베이스에 옛 안내문이 남아 있는 경우입니다. 답변 자체는 문서에 충실하므로 로그만 봐서는 정상으로 보입니다. 가장 늦게 발견되는 유형입니다.
• 권한 밖 정보를 꺼낸 답 — 사내 챗봇에서 특히 위험합니다. 검색 단계에서 걸러야 하고, 생성 단계에서 막는 방식은 신뢰할 수 없습니다.

고치려면 로그가 있어야 합니다

대화 내용만 남기면 원인을 못 찾습니다. 최소한 아래 5가지는 한 줄에 묶여 있어야 합니다.

• 사용자 질문 원문
• 검색 단계에서 실제로 뽑힌 문서 조각과 그 점수
• 답변에 인용된 문서의 식별자와 버전
• 모델이 만든 답변 전문
• 사용자 피드백(도움됨/안됨)과 재질문 여부

이 다섯 개가 함께 있으면 검색이 잘못 뽑았는지, 문서가 낡았는지, 생성이 지어냈는지가 한눈에 갈립니다. 없으면 "모델 탓"으로 끝나고 아무것도 개선되지 않습니다.

운영 지표 4가지

정확도 하나로는 관리가 안 됩니다. 저희는 아래 4개를 주 단위로 봅니다.

• 거절률 — 모른다고 답한 비율입니다. 0에 가까우면 오히려 위험 신호입니다. 지어내고 있다는 뜻일 수 있습니다.
• 인용 포함률 — 답변에 근거 문서가 붙은 비율입니다. 이 값이 낮으면 검색이 제 역할을 못 하고 있습니다.
• 재질문률 — 같은 사용자가 같은 주제를 다시 묻는 비율입니다. 답이 나갔지만 해결되지 않았다는 신호입니다.
• 사람 연결률 — 상담원으로 넘어간 비율입니다. 무조건 낮은 게 좋은 것이 아니라, 넘어가야 할 때 넘어갔는지를 봅니다.

지식베이스는 살아 있는 문서입니다

챗봇 품질의 절반은 모델이 아니라 문서에서 나옵니다. 문서가 낡으면 답도 낡습니다.

• 주 1회 답변 로그에서 "문서에 없어서 못 답한 질문"을 모아 문서 보강 목록을 만듭니다.
• 안내문·요금·운영시간처럼 자주 바뀌는 항목은 원본을 한 곳만 두고 나머지는 참조하게 합니다. 같은 정보를 여러 문서에 복사해 두면 반드시 어긋납니다.
• 문서를 고치면 임베딩을 다시 만들어야 검색에 반영됩니다. 이 단계를 빠뜨려 "고쳤는데 그대로"인 경우가 많습니다.
• 폐기한 문서는 지식베이스에서도 지웁니다. 웹에서 내렸다고 사라지지 않습니다.

사람에게 넘기는 기준을 먼저 정합니다

모든 질문에 답하려는 챗봇이 가장 위험합니다. 넘길 조건을 미리 정해 두면 오답의 상당수가 애초에 생기지 않습니다.

• 검색 점수가 기준 아래일 때 — 억지로 답하지 않고 연결합니다.
• 금액·계약·예약 변경처럼 되돌리기 어려운 요청일 때.
• 같은 주제로 2회 이상 재질문이 들어왔을 때.
• 사용자가 불만을 표시했을 때.

의료기관이라면 하나 더

병원 챗봇은 답변 품질 외에 경계가 따로 있습니다.

• 증상을 듣고 진단하거나 약을 권하는 형태로 답하지 않도록 막습니다. 안내와 진료 권유까지가 챗봇의 범위입니다.
• 환자가 대화에 개인정보를 적는 일이 실제로 생깁니다. 저장 범위와 보관 기간을 미리 정하고, 화면에도 안내합니다.
• 진료시간·휴진 같은 정보는 홈페이지·지도·챗봇이 같은 원본을 보게 합니다. 어긋나면 신뢰가 먼저 깨집니다.

도입 첫 4주에 하는 일

운영 체계를 한 번에 세우려 하면 시작을 못 합니다. 저희는 첫 4주를 이렇게 나눕니다.

• 1주차 — 듣기만 합니다. 답변을 손대지 않고 실제 질문이 어떤 말투로 들어오는지 모읍니다. 구축 때 만든 예상 질문 목록과 얼마나 다른지가 여기서 드러납니다.
• 2주차 — 못 답한 질문을 분류합니다. 문서가 없어서인지, 있는데 못 찾아서인지 나눕니다. 이 둘은 해결 방법이 정반대입니다.
• 3주차 — 문서를 채우고 다시 색인합니다. 새 문서를 쓰기 전에 이미 있는 문서를 챗봇이 찾을 수 있게 만드는 편이 효과가 빠릅니다.
• 4주차 — 넘기는 기준을 조정합니다. 1~3주 로그를 보면 사람이 받아야 했던 대화가 눈에 띕니다. 그 조건을 규칙으로 옮깁니다.

이 4주가 지나야 지표가 의미를 갖습니다. 그 전의 거절률·재질문률은 아직 학습 중인 값입니다.

운영에 드는 공수는 어느 정도인가

"자동화했는데 왜 사람이 붙나요"라는 질문을 자주 받습니다. 정직하게 말씀드리면 초기에는 붙어야 합니다. 다만 성격이 다릅니다.

• 상담을 대신 하는 일이 아니라, 오답 로그를 분류하고 문서를 고치는 일입니다.
• 안정되면 주 단위로 한두 시간 수준으로 줄어듭니다. 질문 유형이 대체로 반복되기 때문입니다.
• 대신 서비스·요금·운영시간이 바뀌는 시점에는 반드시 손이 갑니다. 이때 문서를 안 고치면 그날부터 오답이 쌓입니다.

운영 공수를 아예 없애는 방법은 없습니다. 대신 어디에 얼마나 들어가는지 예측 가능하게 만드는 것은 됩니다.

루미브리즈는 이렇게 운영합니다

저희는 챗봇을 넘기고 끝내지 않습니다. 검색된 문서 조각까지 남는 로그를 기본으로 깔고, 주 1회 오답 로그를 분류해 검색 문제인지 문서 문제인지 생성 문제인지를 나눕니다. 문서 문제로 분류된 건은 지식베이스를 고치고 임베딩을 다시 만든 뒤, 같은 질문을 다시 던져 고쳐졌는지 확인합니다. 고쳤다는 보고 대신 같은 질문의 전후 답변을 보여 드리는 방식입니다.

시작하기 전에 정리해 두면 좋은 것

• 지금 챗봇이 답해야 하는 질문 상위 20개 — 실제 상담 기록에서 뽑은 것
• 자주 바뀌는 정보의 원본이 어디에 있는지(문서·시트·홈페이지 중 무엇이 기준인지)
• 사람에게 넘겨야 하는 상황의 목록과, 넘길 담당자·시간대
• 남길 수 있는 로그의 범위 — 개인정보 정책상 저장 가능한 항목

운영 단계에서 무엇부터 손대야 할지 판단이 서지 않으시면, 루미브리즈로 현재 챗봇의 오답 사례 몇 건과 로그 화면을 보내 주십시오. 어느 갈래의 문제인지부터 분류해 드립니다.