환각

언어 모델을 제품에 붙인 팀들이 처음 부딪힌 것은 답이 틀린다는 사실이 아니라 틀린 답이 맞는 답과 똑같이 생겼다는 점이었습니다. 문장은 매끄럽고 형식도 반듯한데 안에 적힌 사실만 없었습니다.

그래서 초기에는 이것을 버그처럼 다뤘습니다. 재현 절차를 적고 원인이 된 코드 줄을 찾아 고치는 순서입니다. 그런데 같은 질문을 다시 넣으면 다른 답이 나왔고, 그 답도 틀렸지만 틀린 방식이 달랐습니다. 고칠 줄이 없었습니다.

페이지덱에서도 그랬습니다. 회의록을 세 줄로 요약해 주는 기능이 나온 적 없는 결정을 적어 놓았고, 태오가 같은 회의록을 다시 넣자 다른 사람이 그 결정을 내린 것으로 나왔습니다. 코드가 잘못 동작한 것이 아니라 모델이 설계대로 동작한 결과라 결함과 다른 이름이 필요했습니다.

대규모 언어 모델은 앞에 놓인 말에 이어질 가능성이 가장 높은 말을 하나씩 고르는 방식으로 문장을 만듭니다. 사실을 어딘가에서 찾아와 옮기는 것이 아닙니다.

모델 안에는 사실을 적어 둔 표가 없고 많은 텍스트를 읽으며 남은 경향만 있습니다. "작년 매출은" 다음에 숫자가 온다는 것은 알지만 그 숫자가 무엇인지는 모르고 그 자리에 들어갈 법한 값을 고릅니다. 모른다는 상태가 없으니 빈칸을 비우지 못하고 가장 그럴듯한 말로 채웁니다. 말투도 내용이 맞는지와 따로 정해져, 학습한 문서가 단정적이라 모델도 단정적으로 씁니다.

환각이 나오는 자리는 네 군데로 갈립니다.

1. 모델이 본 적 없는 것을 물었을 때입니다. 사내 규정이나 지난주에 바뀐 요금제처럼 학습 때 읽지 못한 내용은 통째로 지어냅니다.
2. 자료가 잘려 나갔을 때입니다. 컨텍스트 윈도는 모델이 한 번에 볼 수 있는 입력의 최대 길이라, 이를 넘는 문서는 잘라 넣어야 하고 모델은 잘린 부분을 없는 것으로 칩니다. 200쪽짜리 계약서를 넣고 위약금 조항을 물었더니 없다는 답이 돌아오는 사고가 그것입니다.
3. 붙여 준 자료가 엉뚱할 때입니다. RAG는 사내 자료에서 관련 대목을 찾아 붙여 주고 모델이 그것만 보고 답하게 하는 방식인데, 붙은 대목이 상관없는 문서면 모델은 그것을 근거 삼아 답을 만듭니다.
4. 질문이 틀린 전제를 깔고 있을 때입니다. 있지도 않은 제도를 두고 "작년에 도입한 연차 이월 제도 설명해 줘" 라고 물으면 모델은 전제를 의심하지 않고 설명을 씁니다.

넷은 처방이 서로 다릅니다. 앞의 둘은 무엇을 보여 줄지의 문제이고 뒤의 둘은 무엇을 믿을지의 문제라, 뭉뚱그려 환각이 심하다고만 말하면 어느 쪽도 손대지 못합니다.

이 말은 언어 모델을 붙인 기능을 기획하거나 검수하는 자리에서 나옵니다. 기획에서는 틀린 답이 나오면 무슨 일이 생기는지 따지는 데 쓰고, 검수에서는 얼마나 자주 나는지 세는 데 씁니다.

같은 제품 안에서도 기능마다 무게가 다릅니다. 회의록 요약이 결정 하나를 지어내면 그 자리에 없던 사람이 그것을 사실로 알게 되고, 고객 문의 답변이 환불 규정을 지어내면 그것이 회사의 약속이 됩니다. 초안을 써 주는 기능은 사람이 어차피 고치므로 덜 위험합니다. 그래서 먼저 묻는 것은 정확도가 몇 퍼센트인가가 아니라 틀렸을 때 누가 무엇을 잃는가입니다.

막는 방법은 네 층입니다.

1. 근거를 붙여 답하게 합니다. 관련 대목을 찾아 넣어 주면 모델이 기억 대신 눈앞의 글을 읽고 답합니다.
2. 지시문을 손봅니다. 프롬프트 엔지니어링은 모델에게 줄 지시문을 설계하는 일인데, 근거에 없는 내용은 쓰지 말라는 문장이 가장 싼 수단입니다.
3. 출력을 검사합니다. 가드레일은 답이 넘으면 안 되는 선을 코드로 걸어 두는 장치로, 답변의 문장이 근거 문서에 있는지 대조해 없으면 내보내지 않는 식입니다.
4. 사람을 세웁니다. 사람 개입은 중요한 판단에 사람의 확인 단계를 두는 설계로, 고객에게 나갈 답변을 상담원이 보고 보내게 하는 식입니다.

나아졌는지는 평가셋이 답합니다. 질문과 기대하는 답을 짝지어 둔 묶음을 지시문을 바꿀 때마다 다시 돌려 틀린 답의 비율을 견줍니다. 에이전트처럼 검색하고 확인하고 다시 검색하는 구성에서는 셈이 더 급합니다. 두 번째 단계에서 지어낸 사실이 세 번째 단계의 입력이 되어 뒤가 전부 그 위에 쌓입니다.

"이 답변 환각 같은데요. 근거 문서에 그런 조항 없어요."

답변에 적힌 내용이 붙여 준 자료에 없다는 지적입니다. 모델이 빈자리를 채웠다는 뜻입니다.

"환각률 재 봤어요? 전보다 나아졌다는 근거가 있어야 배포하죠."

지시문을 고쳤으니 평가셋을 다시 돌려 수치로 견주자는 요구입니다.

"이건 환각 나면 고객한테 바로 나가니까 사람이 한 번 보고 보내는 걸로 하죠."

틀린 답의 대가가 커서 확인 단계를 끼우자는 제안입니다.

페이지덱이 회의록 요약 기능을 열기 전에 지현과 태오가 스무 건을 손으로 읽었습니다. 세 건에 나온 적 없는 결정이 들어 있었고, 태오가 원문에 없는 내용은 쓰지 말라고 지시문에 적자 한 건으로 줄었습니다.

남은 한 건을 두고 태오는 더 손보면 없앨 수 있다고 봤고 지현은 드러나게 하자고 했습니다. 요약문의 각 줄 옆에 회의록의 어느 대목에서 나온 말인지를 달아 두면 근거가 빈 줄이 먼저 눈에 띕니다. 두 가지를 같이 넣고 열었습니다.

모델이 좋아지면 언젠가 없어질 문제로 보는 경우가 가장 많습니다. 새 모델이 나올 때마다 비율이 실제로 줄고 있으니 그렇게 보이기 쉽습니다. 하지만 줄어드는 것과 없어지는 것은 다릅니다. 다음 말을 확률로 고르는 방식이 유지되는 한 모르는 자리를 비워 두는 기능은 생기지 않습니다. 없어질 것으로 보고 기다린 팀은 근거를 보여 주는 화면도 틀린 답을 세는 묶음도 없이 기능을 엽니다.

지시문 한 줄로 막을 수 있다고 보는 것도 흔합니다. 모르면 모른다고 답하라고 적어 두면 모델이 그러겠다고 대답하니 해결된 것처럼 보입니다. 그 문장이 비율을 낮추는 것은 맞지만 0으로 만들지는 못합니다. 모델은 자기가 모른다는 사실을 모르기 때문입니다. 이 줄만 믿고 다른 층을 빼면, 아홉 번은 모른다던 기능이 열 번째에 지어낸 답을 똑같이 자신 있게 내놓습니다.