당신의 AI 어시스턴트는 환각(Hallucination)을 일으키는 것이 아닙니다. 추측을 하고 있는 것이며, 당신이 추측하도록 요청한

Andrej Karpathy는 2023년에 이를 명확하게 말했습니다: 언어 모델(Language models)은 자신이 틀렸다는 사실을 알지 못합니다. 모델에게는 불확실성을 표시하는 내부 신호가 없습니다. 모델은 당신이 제공한 무엇이든 가장 확률이 높은 연속된 내용을 생성하며, 그 출력이 정답이든 완전히 조작된 것이든 상관없이 동일한 자신감을 가지고 수행합니다.

그것은 환각(Hallucination)이 아닙니다. 그것은 아키텍처(Architecture)가 작동하는 방식입니다.

"환각"이라는 단어는 모델이 스스로 표류했다는 것, 즉 아무런 프롬프트(Prompt) 없이 허구 속으로 헤매 들어갔다는 것을 암시합니다. 그러한 프레임(Framing)은 당신의 책임을 면제해 줍니다. 하지만 더 정확한 프레임은 그렇지 않습니다.

내부에서 실제로 일어나고 있는 일

대규모 언어 모델(Large language models)은 다음 토큰 예측기(Next-token predictors)입니다. 매 단계마다 모델은 전체 어휘(Vocabulary)에 대한 확률 분포(Probability distribution)를 생성하고 그중에서 샘플링(Sampling)합니다. 나타나는 출력은 이전의 모든 정보가 주어졌을 때 가장 가능성이 높아 보이는 시퀀스(Sequence)입니다. 모델이 대조하여 확인할 룩업 테이블(Lookup table)이나 사실 데이터베이스(Database of facts)는 없습니다. 그것은 대규모로 작동하는 패턴 완성(Pattern completion)입니다.

모델이 틀린 것을 생성할 때, 그것은 모델이 혼란을 느꼈기 때문이 아닙니다. 당신의 프롬프트로부터 구축된 확률 분포가 해당 출력을 가리켰기 때문입니다. 틀린 답이 당신이 제공한 입력값(Input)을 고려했을 때 가장 가능성 높은 답이었던 것입니다.

이러한 구분은 문제가 발생했을 때 당신이 어디를 살펴봐야 하는지를 바꾸기 때문에 중요합니다. 만약 모델이 환각을 일으킨 것이라면, 당신이 할 수 있는 일은 없습니다. 그것은 시스템의 결함입니다. 만약 당신이 모호한 프롬프트를 주었기 때문에 모델이 잘못된 추측을 한 것이라면, 그것은 당신이 해결해야 할 문제이며 지금 당장 해결할 수 있습니다.

격차는 언제나 명세(Specification)에 있습니다

저는 Datawise에서 전문적으로 AI 모델을 벤치마크(Benchmark)합니다. 우리는 수십 개의 작업에 걸쳐 구조화된 평가(Structured evaluations)를 실행합니다. 가장 일관되게 나타나는 패턴은 다음과 같습니다: 틀려 보이는 출력은 거의 항상 명세가 부족한(Underspecified) 입력에 반응한 결과라는 점입니다. 모델은 엔지니어가 질문했다고 생각한 질문이 아니라, 실제로 질문된 질문에 대해 합리적인 답변을 내놓은 것입니다.

이것들은 서로 다른 질문입니다:

• "Python에서 Postgres에 어떻게 연결하나요?" - 모델은 어딘가에서는 작동할 법한 무언가로 답변하지만, 아마 당신의 정확한 설정과는 맞지 않을 것입니다.
• "Ubuntu 24.04 환경에서, Cloudflare Tunnel 뒤에 있고, 30초 타임아웃 설정과 10개의 커넥션 풀(connection pool)을 사용하는 psycopg3를 이용해 Python에서 Postgres에 어떻게 연결하나요?" - 이제 모델은 작업할 수 있는 실제 제약 조건(constraints)을 갖게 되었습니다.

첫 번째 프롬프트에는 모델이 추측해야 하는 6가지의 암묵적인 결정 사항이 포함되어 있습니다. 두 번째 프롬프트에는 그런 것이 없습니다.

구체적인 프롬프트를 작성하는 것의 어려움은 당신이 실제로 무엇을 필요로 하는지 아는 것의 어려움과 같습니다. 만약 당신이 구체적인 프롬프트를 작성할 수 없다면, 당신은 아직 무엇이 필요한지 모르는 것입니다. 이것은 유용한 정보입니다. 즉, 프롬프트를 입력하는 것을 멈추고 생각을 시작해야 한다는 뜻입니다.

신뢰도 문제 (The confidence problem)

이것을 진정으로 까다롭게 만드는 점은, LLM(대규모 언어 모델)이 정답을 내놓을 때와 동일한 유창함과 자신감으로 오답을 생성한다는 것입니다. 문장은 권위 있게 들리고, 코드는 깔끔해 보입니다. 더듬거림도 없고, 확신을 피하는 표현(hedge)도 없으며, "여기서 빈틈을 채우고 있습니다"라고 말하는 신호도 없습니다.

이 지점에서 경험이 중요해집니다. 주니어 엔지니어는 출력을 읽고 그것이 맞스러워 보이기 때문에 신뢰합니다. 시니어 엔지니어는 출력을 읽고 질문합니다: "내가 어디에 해석의 여지를 남겨두었는가?"

프롬프트에 포함된 모든 모호한 단어는 당신 없이 모델이 내린 결정입니다. 누락된 모든 제약 조건은 확률(probability)이 개입한 지점입니다.

2차 문제: 아무것도 바꾸지 않고 재시도하기 (The second-order problem: retrying without changing anything)

출력이 틀렸을 때 가장 흔한 반응은 문구를 약간 다르게 하여 다시 제출하고 다른 결과가 나오기를 바라는 것입니다. 때로는 이것이 통할 수도 있습니다. 하지만 대부분은 통하지 않는데, 왜냐하면 문제는 문구(phrasing)가 아니라 누락된 문맥(context)이었기 때문입니다.

사양(specification)을 수정하지 않고 재시도하는 것은 로그를 확인하지 않고 서비스를 재시작하는 것과 AI 관점에서 동일합니다. 운이 좋을 수도 있겠지만, 당신은 아무것도 고친 것이 아닙니다.

실제로 해야 할 일 (What to actually do)

AI 출력 결과가 틀렸을 때, 프롬프트(Prompt)를 다시 작성하기 전에 먼저 당신의 프롬프트를 읽어보세요. 당신이 어디에서 해석의 여지(room for interpretation)를 남겨두었는지 질문하십시오. 누락된 제약 조건(Constraints)을 추가하십시오. 구현(Implementation)을 요청하기 전에 입력(Inputs), 출력(Outputs), 에러 처리(Error handling), 의존성(Dependencies), 그리고 엣지 케이스(Edge cases)에 대해 구체적으로 명시하십시오.

유용한 습관 하나: 프롬프트를 제출하기 전에, 아무런 맥락(Context) 없이 프로젝트에 합류한 신입 엔지니어의 관점에서 프롬프트를 다시 읽어보십시오. 당신이 무엇을 추측해야만 할까요? 당신이 추측해야 하는 모든 부분은 모델 또한 추측하게 될 지점입니다.

모델은 당신에게 거짓말을 하는 것이 아닙니다. 모델은 당신이 명시하지 않은 부분의 형태를 보여주고 있는 것입니다. 일단 그렇게 이해하고 나면, 해결 방법은 항상 동일합니다.

더 정교한(Tighter) 프롬프트를 작성하십시오.