LLM의 환각, 기획 단계에서 정해둘 것들

 

ChatGPT를 쓰다 보면 그럴듯하지만 사실이 아닌 답을 만나는 순간이 반드시 옵니다.
없는 논문을 실제 있는 것처럼 인용하거나, 존재하지 않는 기능을 자신 있게 설명하는 식이에요.
흔히 이런 현상을 환각(hallucination)이라고 부릅니다.
개인이 대화창에서 쓸 때는 "확인해보면 되지" 하고 넘어갈 수 있지만, 서비스 안에 넣는다면 이야기가 달라집니다.
이 글에서는 제가 공부하면서 "개발에 들어가기 전에 기획이 먼저 정해둬야 한다"고 느낀 것들을, 예약 안내 챗봇을 가정해서 정리해봅니다.

 

환각이 있다는 사실 자체보다, 어디에서 그것이 문제가 되는지를 구분하는 게 먼저라고 생각했습니다.
모델이 지어낸 말이 "무해한 틀림"인지, 사용자의 돈이나 시간에 영향을 주는 "해로운 틀림"인지가 다르기 때문이에요.

예약 안내 챗봇을 예로 들어보겠습니다.
"이 업장은 몇 시에 문을 열어요?"라는 질문에 잘못된 시간을 알려주면, 고객이 헛걸음을 합니다.
"취소하면 환불되나요?"라는 질문에 존재하지 않는 환불 규정을 말해버리면, 업장과 고객 사이에 분쟁이 생길 수 있어요.
반면 "이 서비스 이름은 무슨 뜻이에요?" 같은 질문에서의 틀림은 영향이 훨씬 작습니다.

그래서 기획 단계에서 챗봇이 받을 질문을 미리 쭉 모은 뒤, 틀렸을 때의 피해 정도로 한 번 나눠보는 작업을 해볼 만합니다.
예를 들어 영업시간, 가격, 취소 규정, 예약 가능 여부는 틀리면 피해가 큰 쪽이고, 일반적인 이용 방법 안내는 상대적으로 작은 쪽입니다.
피해가 큰 질문일수록 모델이 기억에서 꺼낸 답을 그대로 말하게 하면 안 된다는 방향이 여기서 정해집니다.

 

환각을 줄이는 기본 방향은 모델이 아는 척하지 않게 만드는 것입니다.
제가 공부한 범위에서는 두 가지가 중요해 보였어요.

 

첫째는 답의 근거를 서비스가 가진 자료로 제한하는 것입니다.
업장이 등록한 영업시간, 정책 문서, 자주 묻는 질문 같은 자료를 모델에게 함께 넘겨주고 "이 자료에 있는 내용으로만 답하라"고 지시하는 방식이에요.
이 구조를 문서 검색과 생성을 붙이는 방식이라고 하는데, 이 부분은 다른 글에서 따로 공부한 걸 정리하고 있습니다.

둘째는 자료에 없는 질문일 때 답변을 거절하는 문구를 미리 정해두는 것입니다.
예를 들면 "제가 가진 정보로는 정확히 안내드리기 어려워요, 업장에 직접 문의해 주세요"처럼요.
이 문장을 기획자가 정하지 않으면 모델이 그때그때 만들어내고, 어떤 날은 정중하지만 어떤 날은 엉뚱한 말이 나옵니다.

거절만큼 중요한 것이 되묻기입니다.
"내일 예약돼요?"라는 질문에는 어떤 서비스인지, 몇 시쯤인지 정보가 부족하죠.
이럴 때 추측해서 답하는 대신 "어떤 서비스를 원하시는지 알려주시겠어요?"라고 확인 질문을 하도록 설계하면, 틀린 답이 나올 여지가 줄어듭니다.

 

답변에 근거를 같이 보여주는 것도 좋은 장치입니다.
"영업시간은 오전 10시부터입니다 (업장 정보 기준)"처럼 어디에서 가져온 정보인지 한 줄 덧붙이면, 사용자가 신뢰 수준을 스스로 판단할 수 있어요.
출처를 눌렀을 때 원문 정책 화면으로 이동하게 하면 더 좋고요.
다만 출처 표시가 있다고 해서 모델이 그 문서를 정확히 읽었다는 보장은 없다는 점은 기억해둬야 합니다.
링크는 있는데 요약이 틀린 경우도 있을 수 있어서, 이 부분은 평가 과정에서 따로 확인해야 하는 항목으로 남겨두었습니다.

위험도에 따라 사람 확인을 넣는 것도 기획이 정해야 할 결정입니다.
저는 대략 세 단계로 나눠 생각해보고 있어요.
낮은 위험은 챗봇이 바로 답하고, 중간 위험은 자료를 근거로 답하되 출처를 붙이며, 높은 위험은 챗봇이 답을 확정하지 않고 업장 담당자에게 넘기는 구조입니다.
환불이나 분쟁에 가까운 질문이 높은 위험에 해당하는 예시입니다.
이때 "사람에게 넘기는" 경로가 실제로 존재해야 하고, 담당자가 바로 못 볼 때의 안내 문구까지 설계해야 해요.
넘길 사람이 없는데 넘긴다고만 말하는 챗봇은, 환각보다 더 나쁜 경험을 줄 수 있습니다.

한 가지 더 신경 쓴 것은 사용자에게 한계를 미리 알리는 일입니다.
챗봇 첫 화면에 "AI가 안내하는 서비스라 정확하지 않을 수 있어요, 중요한 내용은 업장에 확인해 주세요" 같은 문구를 짧게 두는 거예요.
이 한 줄이 환각을 막아주지는 않지만, 사용자의 기대치를 현실에 맞추는 데는 도움이 된다고 생각합니다.

 

환각은 한 번 잘 나오는 것을 보고 안심할 수 있는 종류가 아니라서, 기획 단계에서 테스트 질문 목록을 같이 만들어두면 좋겠다고 생각했습니다.
질문을 크게 세 묶음으로 나눠볼 수 있습니다.
자료에 답이 분명히 있는 질문, 자료에 답이 없는 질문, 자료와 약간 어긋나는 함정 질문입니다.
"일요일에도 하나요?"처럼 자료에 일요일 이야기가 없을 때, 모델이 평일 정보를 바탕으로 짐작해서 답하는지 보는 식이에요.
이 목록이 있으면 모델이나 지시문이 바뀔 때마다 같은 질문으로 다시 돌려볼 수 있어서, 변화를 감으로 판단하지 않게 됩니다.

 

환각을 완전히 없앨 수는 없다고 보는 쪽이 현실적인 것 같습니다.
그래서 "환각이 없는 모델을 기다린다"보다 "환각이 나와도 피해가 작도록 설계한다"가 기획자가 할 수 있는 일에 더 가깝다고 느꼈어요.
아직 답을 못 찾은 질문도 있습니다.

거절을 너무 자주 하면 챗봇이 쓸모없다고 느껴질 텐데, 그 균형점은 어떻게 잡을지.

테넌트마다 자료의 품질이 다를 때, 자료 자체가 틀려 있으면 누구의 책임으로 볼지.
이 부분은 더 공부하고 직접 작은 예시를 만들어 보면서 이어가보겠습니다.