평소 제 포스트들보다 기술적인 내용은 적습니다. 설치할 것도, 비용을 지불할 것도 없으며, 코드, 스프레드시트, 연구 또는 글쓰기를 위해 AI 어시스턴트를 사용하는 경우 모두 동일하게 작동합니다.

제가 설명하고자 하는 문제의 형태는 다음과 같습니다. 여러분도 이런 경험이 있는지 확인해 보세요.

당신은 어시스턴트에게 결과물을 만들어내는 무언가를 요청합니다. 어시스턴트는 이를 수행합니다. 숫자, 요약, 상태, 답변이 돌아옵니다. 그럴듯합니다. 왜 그렇게 되었는지 물으면, 그것을 완벽하게 설명해 주는 명확하고 자신감 넘치는 설명을 듣게 됩니다. 그래서 당신은 그것을 믿고, 기록하고, 그 결과를 바탕으로 다음 세 가지 결정을 내립니다.

일주일 후, 당신은 그 모든 것이 틀렸다는 사실을 알게 됩니다. 명백한 방식으로 틀린 것이 아닙니다. 도구가 당신이 묻지 않은 것을 측정했거나, 빈 파일을 읽었거나, 당신의 머릿속에 있는 질문과는 약간 다른 질문에 답했기 때문에 틀린 것입니다.

여기서 어떤 일이 일어나지 않았는지 주목하세요. 아무것도 발명되지 않았습니다. 가짜 인용(fake citation)도, 지어낸 사실(made-up fact)도 없었습니다. 사람들이 "환각 (hallucination)"이라고 말할 때 의미하는 실패 사례들도 아니었습니다. 이 실패는 구조적인 것이었습니다. 답이 틀릴 가능성이 여전히 남아 있는 동안, 답이 무엇이어야 하는지에 대해 아무도 확언하지 않았던 것입니다.

습관

어시스턴트가 결과물을 생성하는 작업을 실행하기 전에, 다음 두 가지 질문에 답하게 만드세요.

1. 결과가 무엇일 것이라고 예상하며, 그 이유는 무엇인가요?

2. 만약 이것이 잘못되었다면, 어떻게 알 수 있나요?

이것이 기술의 전부입니다. 작업이 끝난 후 한 단락의 설명을 듣는 대신, 작업 전에 두 문장을 듣는 것입니다. 이는 무료 티어 (free tier)에서도 작동합니다. 어떤 모델에서도 작동합니다. 단 몇 초밖에 걸리지 않습니다.

첫 번째 질문이 효과적인 이유

이것은 "더 깊이 생각하기"에 관한 것도 아니고, 동기 부여를 위한 속임수도 아닙니다. 이것은 어시스턴트가 해결하고 있는 문제의 종류를 바꾸는 것입니다.

이미 본 결과를 설명하는 것은 개방형 작업 (open-ended task)입니다. 어떤 결과에든 들어맞는 이야기는 무수히 많으며, 언어 모델 (language model)은 그중 하나를 찾아내는 데 매우 탁월합니다. 이것은 결함이 아니라, 모델이 그렇게 만들어진 목적 그 자체입니다. 문제는 유창한 설명이 그 결과가 옳은지 여부에 대해 아무것도 알려주지 않는다는 점입니다. 결과가 맞든 틀리든 설명은 똑같이 읽힙니다.

보지 못한 결과를 예측하는 것은 폐쇄형 작업 (closed task)입니다. 어시스턴트가 당신의 데이터, 파일, 요청에 대해 믿고 있는 모든 것은 틀릴 수도 있는 단 하나의 진술로 수렴되어야 합니다. 그리고 실제 출력이 예측과 다를 때, 사후에 조작할 수 없는 신호를 얻게 됩니다. 왜냐하면 예측은 이미 화면에 놓여 있기 때문입니다.

예상치와 실제치 사이의 그 간극이 바로 제품의 핵심입니다. 이는 생성 비용이 저렴하면서도 사후에는 결코 속일 수 없습니다.

보너스 효과도 있는데, 이것이 바로 이 방식을 적용했을 때 결과가 더 안정적으로 느껴지는 이유입니다. 먼저 예측하는 것은 데이터가 도착하기 전에 성공의 기준을 고정합니다. 실행할 때마다 발생하는 대부분의 흔들림은 모델이 마음을 바꾸는 것이 아니라, 나타난 결과에 맞춰 기준이 조용히 움직이는 것입니다.

과학계에는 이를 부르는 이름과 이를 둘러싼 전체 체계가 있습니다. 바로 사전 등록 (pre-registration)입니다. AI를 위해 누군가 이를 발명할 필요는 없었습니다. 우리는 단지 이를 적용하는 것을 잊었을 뿐입니다.

두 번째 질문이 더 중요한 이유

나는 이것을 비싼 대가를 치르고 배웠습니다.

나는 특정 날짜를 기준으로 어떤 문서가 사실인지와 같은, 시간에 민감한 질문에 답하기 위한 시스템을 가지고 있었습니다. 성능이 좋지 않았습니다. 나는 이 작업이 진정으로 어렵기 때문에 성능이 낮을 것이라고 예측했습니다. 예측은 결과와 일치했습니다. 나는 고개를 끄덕이며 수치를 적고 다음으로 넘어갔습니다.

예측은 맞았지만, 측정은 가치가 없었습니다.

420개의 문서 중 그 어떤 문서에도 날짜가 붙어 있지 않았습니다. 단 하나도 없었습니다. 시스템은 시간에 대한 정보가 전혀 없는 자료를 사용하여 시간에 관한 질문을 받고 있었던 것입니다. 정확히 동일한 문서들을 사용하여 이 문제를 해결하자, 점수는 0.19에서 0.98로 올라갔습니다.

저는 이 수치를 다룰 때 주의하고 싶습니다. 왜냐하면 이 수치는 그것을 만들어낸 사람을 포함하여 사람들이 잘못 인용하기 쉬운 종류의 수치이기 때문입니다. 이것은 개선(improvement)이 아닙니다. 아무것도 더 똑똑해지지 않았습니다. 고장 난 계측기를 수리했을 때 외부에서 보이는 모습이 바로 이와 같으며, 만약 제가 이것을 승리라고 발표했다면 저는 정확한 산술을 담은 거짓말을 하고 있었던 셈이 될 것입니다.

여기에 일반적인 규칙이 있으며, 이는 거의 모든 사람이 건너뛰는 부분입니다:

답을 예측하는 것만으로는 질문이 결코 던져지지 않았음을 알려주지 않습니다. 만약 설정(setup)이 잘못되었다면, 당신의 예측과 결과는 같은 방향으로 틀릴 수 있으며, 서로 완벽하게 일치할 수 있고, 그 어떤 것도 확인해주지 못합니다.

이것이 바로 두 번째 질문이 존재하는 이유입니다. "이것이 고장 났다면 어떻게 알 수 있는가?"라는 질문은 어시스턴트(assistant)로부터 다른 것을 끌어냅니다. 즉, 답에 대한 추측이 아니라, 답이 무엇으로 밝혀지든 상관없이 반드시 참이어야 하는 메커니즘(machinery)에 대한 진술을 요구하는 것입니다.

• 기대치(Expectation): "점수가 낮을 것입니다. 이것은 어려운 문제입니다."
• 고장 확인(Broken-check): "만약 문서에 날짜가 없다면, 질문 자체가 던져지지 않은 것입니다."

첫 번째는 맞았지만 저에게 아무것도 가르쳐주지 않았습니다. 두 번째 방식이었다면 첫날에 바로 문제를 파악했을 것입니다.

완료(Done)는 증명(Proved)과 같지 않다

그 두 번째 질문은 제가 이제 일주일에 여러 번 소리 내어 말하는 원칙으로 일반화되었습니다.

어떤 작업이 성공했다고 보고할 때, 당신이 배운 것은 '작업이 성공했다고 보고되었다'는 사실뿐입니다. 당신은 파일이 작성되었는지, 그 파일에 내용이 들어 있는지, 숫자가 당신이 요청한 날짜를 포함하고 있는지, 또는 당신이 요청한 확인 절차가 실제로 수행되었는지는 배우지 못했습니다.

제가 가장 좋아하는 예시는 작고 어리석은 것입니다. 예전에 저는 제 작업물에서 특정 종류의 실수를 잡아내기 위해 규칙 검사기 (rule-checker)를 작성한 적이 있습니다. 그것은 몇 주 동안 아무 문제 없이 작동했습니다. 그것이 문제없이 작동했던 이유는 설정 불일치 (settings mismatch) 때문에 제가 중요하게 생각했던 규칙이 한 번도 활성화되지 않았기 때문입니다. 그 검사기는 구조적으로 아무것도 찾아낼 수 없는 상태였습니다. 아무것도 고장 나지 않았고, 오류도 없었으며, 모든 것이 초록색(정상)이었지만, 그 초록색은 아무런 의미도 없었습니다.

그 문제를 해결하기 위해 제가 처음으로 작성한 테스트는 설정 파일 (settings file)을 확인하기 위해 설정 파일을 읽는 것이었습니다. 그 테스트는 통과했습니다. 두 번의 별도 검토 과정에서도 그 테스트는 그냥 지나쳐 버렸습니다. 마침내 무언가를 잡아낸 방법은 의도적으로 잘못된 예시를 대상으로 검사기를 실행하고, 그것이 불평(경고)하는 것을 지켜보는 것이었습니다.

그러니, 상태 (status)가 아니라 결과물 (output)을 요구하세요. 행 (rows)을 보여달라고 하세요. 파일을 보여달라고 하세요. 하나라도 잡아내는 모습을 보여달라고 하세요.

당신에게 경고를 주어야 하는 것이라면, 한 번은 반드시 경고하게 만드세요

같은 아이디어지만, 좀 더 유용한 방향으로 적용해 봅시다.

당신이 한 번도 본 적 없는 안전망 (safety net)이 무언가를 잡아내지 못한다면, 그것은 안전망이 아닙니다. 그것은 안전망의 형태를 한 추측일 뿐입니다. 이는 코드보다 훨씬 더 많은 것에 적용됩니다. 숫자가 범위를 벗어났을 때 이메일을 보내기로 되어 있는 알림 (alert), 잘못된 행을 잡아내기로 되어 있는 필터 (filter), 잘못된 내보내기 (export)를 중단하기로 되어 있는 체크 (check) 등이 모두 마찬가지입니다.

그러니 의도적으로 테스트하세요. 의도적으로 잘못된 것을 한 번 입력해 보고, 그것이 작동(fire)하는지 지켜보세요.

저는 제가 몇 달 동안 유지 관리해 온 시스템 전체에 대해 이 연습을 수행했습니다. 그 결과, 어떤 상황에서도 절대 울릴 수 없었던 12개의 경고를 찾아냈습니다. 그중 하나는 누군가 알아차리기 전까지 약 두 달 동안 비용이 조용히 계속 발생했던 원인이었습니다. 그 12개 모두 저를 포함한 누군가에 의해 읽히고 승인된 것들이었습니다. 그것들을 읽는 방식은 결코 효과가 없었을 것입니다. 왜냐하면 그것들이 정확하게 읽혔기 때문입니다. 바로 그 점이 그것들을 위험하게 만듭니다.

제가 올바르게 깨닫기 전에 틀렸던 두 가지가 있으며, 이는 일반화될 수 있습니다:

의도적으로 망가뜨리는 것은 실제로 무엇을 망가뜨렸는지만을 증명할 뿐입니다. 저는 한때 두 개의 체크(check)가 올바른 순서로 수행되는지 "확인"하기 위해, 그중 하나를 완전히 삭제해 버린 적이 있습니다. 그것이 증명한 것은 단지 체크가 존재한다는 사실뿐이었습니다. 제가 실제로 신경 썼던 부분인 순서(ordering)는 여전히 테스트되지 않은 채로 남았습니다.

통과할 수 없는 체크는 실패할 수 없는 체크만큼이나 쓸모가 없습니다. 저는 다섯 번 연속으로, 이미 검증된 입력값(known-good input)에 대해서조차 결과가 녹색(pass)으로 나오지 않는 상황을 겪었습니다. 그리고 각각의 사례는 이전 사례를 수정하는 과정에서 도입되었습니다. 정상적인 케이스와 비정상적인 케이스에서 동일한 동작을 보인다는 것은, 어느 방향으로든 아무것도 측정하지 못하고 있다는 뜻입니다.

기억하지 말고, 찾아보세요

위의 모든 것보다 더 저렴한 방법이 하나 더 있습니다. 어시스턴트가 확인 가능한 사실이 필요할 때, 직접 가서 확인하게 만드세요. 자신만만하게 내놓는 틀린 값은 솔직하게 비어 있는 값(blank)보다 더 나쁩니다. 비어 있는 값은 정직하며 후속 처리가 가능하지만, 틀린 값은 하류(downstream)의 모든 과정에 소리 없이 스며들기 때문입니다.

그리고 제가 받아들이기까지 부끄러울 정도로 오랜 시간이 걸렸던 부분은 이것입니다: "거기에 없다"는 것 자체가 완전한 답변입니다. 그것을 정보처럼 보이도록 무언가로 개선할 필요는 없습니다.

지금 바로 붙여넣을 수 있는 버전

이 모든 내용은 다섯 줄로 압축됩니다. 어시스턴트의 지침 파일(instructions file), 저장된 프롬프트(saved prompt), 프로젝트 설정, 혹은 사용 중인 도구가 고정 규칙(standing rules)을 보관하는 곳 어디든 넣어두세요:

- 결과를 생성하는 무언가를 실행하기 전에: 무엇을 기대하는지, 그리고 그 이유를 한두 문장으로 말하세요. 그 다음 실행하세요.
- 또한 이것이 잘못되었을 때 내가 어떻게 알 수 있는지 말하고, 그것을 먼저 확인하세요.
...

만약 다섯 줄이 너무 많다면, 두 번째 줄만이라도 남겨두세요. 그것이 가장 많은 비용을 스스로 회수(paid for itself)한 문장입니다.

이것이 도움이 된다는 것을 실제로 증명할 수 있나요?

제가 원하는 방식으로는 할 수 없습니다. 이것이 허구의 사실(invented facts)을 덜 만들어낸다는 것을 보여드릴 수는 없습니다. 왜냐하면 저는 그런 실험을 수행하지 않았으며, 제가 가지고 있지 않은 결과를 주장할 생각도 없기 때문입니다.

하지만 정말로 고통스러운 것은 그게 아닙니다. 진짜 고통스러운 것은 처음부터 틀린 답변을 바탕으로 무언가를 구축하느라 보낸 일주일입니다. 그리고 그것은 여러분이 이번 달에 직접, 무료로 측정할 수 있는 것입니다.

기록을 남기세요. 결과가 틀린 것으로 드러나서 무언가를 철회하거나, 작업을 폐기하거나, 결정을 재검토해야 할 때마다 표시를 하세요. 한 줄의 기록, 날짜, 그리고 무엇이 틀렸는지에 대한 한 문장이면 충분합니다.

현재 업무를 수행하면서 2주 동안 그렇게 해보세요. 그다음 두 가지 질문을 추가하여 2주 더 진행하세요.

여러분은 어시스턴트가 얼마나 자주 맞는 것처럼 들리는지를 세는 것이 아닙니다. 어시스턴트가 거의 항상 맞는 것처럼 들리는 것은 여러분에게 아무런 정보도 주지 못합니다. 여러분은 어시스턴트가 무언가를 구축할 수 있을 만큼 충분히 오랫동안 '맞는 상태를 유지했는지'를 세는 것입니다. 그것이 여러분의 실제 시간과 직결되는 수치이며, 벤치마크 점수와 달리 여러분의 것이고, 여러분의 업무에 특화되어 있으며, 누구도 반박할 수 없습니다.

저의 솔직한 입장은 이렇습니다. 저는 설득력 있다고 느끼는 메커니즘을 가지고 있으며, 아무도 사전에 아무것도 확언하지 않았던 상황에서 재앙이 집중적으로 발생하는 사고 로그(incident log)를 가지고 있습니다. 그것이 증거입니다. 이것은 측정(measurement)은 아니며, 만약 제가 이것을 측정인 것처럼 꾸민다면 이 글이 반대하는 바로 그 행동을 하는 셈이 될 것입니다.

도움이 되지 않는 경우

세 가지 한계가 있습니다. 남이 말하게 두느니 제가 직접 말하겠습니다.

확인 가능한 무언가가 필요합니다. 관찰 가능한 결과가 없다면, "결과를 예측하라"는 명령은 다음에 올 무엇이든 치켜세우는, 자신감 있게 들리는 서문에 불과하게 됩니다. 틀렸다고 말할 수 있는 대상이 없다면, 그 과정을 건너뛰세요.

자신감 있는 예측은 여러분을 그 방향으로 끌어당길 수 있습니다. 미리 숫자를 입 밖으로 내뱉으면, 사람뿐만 아니라 모델에게도 그 결과가 예측과 일치하도록 읽어야 한다는 압박이 가해집니다. 해결책은 결론이 아니라 **관찰 가능한 것(observable)**을 예측하는 것입니다. "이것은 내 이론을 확인해 줄 것이다"라고 말하는 것보다 "대략 400개의 행이 있어야 하며, 모두 6월 이후의 날짜여야 한다"라고 말하는 것이 훨씬 덜 유도적입니다.

이는 속도를 약간 늦춥니다. 작업당 몇 초 정도의 시간이 소요됩니다. 하지만 모델이 무언가 잘못된 것을 잡아내는 첫 번째 순간에 그 시간을 보상받게 될 것이며, 예측 결과가 실제 결과 바로 옆에 배치되어 서로 일치하지 않는 모습을 보여주기 때문에 언제 그런 일이 발생하는지 정확히 알 수 있을 것입니다.

만약 이 다섯 가지 라인을 시도해 보신다면, 어떤 것들이 제 자리를 찾고 어떤 것들이 단순한 카고 컬트 (cargo cult)인지 알려주시면 좋겠습니다. 적어도 그중 하나는 카고 컬트일 것이라고 상당히 확신합니다.