어제 제 에이전트(agent)는 "이것을 확인할 수 없습니다"라는 문장을 작성했고, 그것은 진심이었습니다.

그로부터 40줄 뒤, 동일한 답변 내에서 에이전트는 검증되지 않은 내용을 열 헤더와 항목별 행이 포함된 마크다운 표(markdown table)에 넣었습니다.

저는 두 가지를 모두 읽었습니다. 그리고 표를 바탕으로 행동했습니다.

의도(intent)의 측면에서 우리 중 누구도 잘못한 것은 없었습니다. 면책 조항(disclaimer)은 정직했습니다. 표는 자신감이 넘쳤습니다. 결국 자신감이 승리했습니다.

당신도 이런 일을 저질렀습니다

이 문제를 기계의 탓으로 돌리기 전에, 저 또한 똑같은 일을 한 번 이상 스스로 저지른 적이 있습니다.

Slack 스레드에서 무언가에 대해 주의 사항(caveat)을 언급한 뒤, 그 아래에 깔끔한 요약본을 붙여넣는 일 말입니다.

모든 셀이 소수점 둘째 자리까지 우측 정렬된 스프레드시트(spreadsheet) 위에 "대략적인 수치"라고 적는 일 말입니다.

팀장에게 추정치가 유동적(soft)이라고 말한 뒤, 시작 날짜와 종료 날짜가 포함된 간트 차트(Gantt chart)에 그것을 집어넣는 일 말입니다.

방어적인 표현(hedge)은 문장에 들어가고, 답변은 구조(structure)에 들어갑니다. 그리고 구조는 매번 승리합니다. 왜냐하면 사람들이 행동하는 것은 바로 구조이기 때문입니다.

검증이 수행한 것

작업은 평범했습니다. 몇 가지 영화를 추천하고, 특정 국가의 특정 스트리밍 서비스에 해당 영화가 있는지 여부를 기록하는 것이었습니다.

에이전트는 지역별 스트리밍 카탈로그(streaming catalogs)는 순환하며, 특정 카탈로그에 대한 자신의 회상(recall)은 신뢰할 수 없다는 것을 알고 있었고 그렇게 말했습니다. 올바른 본능이었고, 글로 명확하게 기술되었습니다.

그러고 나서 에이전트는 어쨌든 추천 표를 생성했습니다.

제가 마침내 제목별로 실시간 가용성 소스(live availability source)를 대조하여 확인하도록 요청했을 때, 해당 표에 있던 8개의 제목 중 5개가 플랫폼에 전혀 없었습니다. 근접하지도 않았습니다. 최근에 삭제된 것도 아니었습니다. 단지 그날, 그 국가에 존재하지 않았을 뿐입니다.

목록에서 가장 강력한 선택지, 즉 제가 요청한 것에 가장 잘 부합한다고 설명된 항목도 그중 하나였습니다.

여기서 틀린 것보다 당신을 더 괴롭혀야 할 부분이 있습니다.

그 출력물 중 그 어떤 것도 불확실해 보이지 않았습니다. 영화에 대한 지식은 탄탄했습니다. 품질 판단도 괜찮았습니다. 모든 평점도 충분히 근접했습니다. 오직 한 가지 좁은 범주의 사실만이 부패해 있었는데, 그것은 영구적인 것처럼 느껴지면서도 매달 변하는 범주의 사실이었습니다.

확신에 찬 회상 (Confident recall)과 정확한 회상 (Correct recall)은 외관상 동일한 출력을 생성합니다. 이를 구별할 수 있는 단서는 없으며, 이는 제가 추정치를 작성할 때나 모델이 표 (Table)를 작성할 때나 마찬가지입니다.

"무언가를 검증하라"가 아닌 발견 사항

모두가 이미 무언가를 검증해야 한다는 사실을 알고 있습니다. 위에서 증명했듯이, 그러한 조언은 저를 포함하여 그 누구의 행동도 단 한 번도 변화시키지 못했습니다.

유용한 발견은 더 좁은 범위에 있습니다.

산문(Prose) 형태의 면책 조항은 구조(Structure)에 담긴 단언을 취소할 수 없습니다.

독자는 이 둘을 동일한 비중으로 받아들이지 않으며, 결코 그렇지 않았습니다. 표 (Table)는 권위 있는 형식 (Authority format)입니다. 번호가 매겨진 목록 (Numbered list), 비교 행렬 (Comparison matrix), 신뢰도 백분율 (Confidence percentage), 축이 있는 차트 (Chart with axes), 타입이 지정된 스키마 (Schema with types)도 마찬가지입니다. 이러한 형식들은 그 안에 담긴 값들이 생성된 것이 아니라 출처를 통해 가져온 것이라는 암묵적인 주장을 담고 있습니다.

검증되지 않은 콘텐츠를 이러한 컨테이너 (Container) 중 하나에 넣으면, 컨테이너가 해당 콘텐츠의 등급을 격상시킵니다. 당신의 주의 사항 (Caveat)은 부드러운 산문 형태로 그 위에 놓여 있을 뿐, 아무런 역할도 하지 못합니다.

이 문제는 인간의 출력보다 에이전트 (Agent)의 출력에서 더 중요하게 작용하는데, 이는 지루할 정도로 기계적인 이유 때문입니다. 에이전트는 구조화된 출력 (Structured output)을 끊임없이 생성합니다. 구조화된 출력이 파싱 (Parse)하기 쉽고, 렌더링 (Render)하기 쉬우며, 다음 단계로 전달하기 쉽기 때문입니다. 출력을 기계가 사용 가능하게 만드는 형식이 바로 출력을 검증된 것처럼 보이게 만드는 형식과 동일합니다.

따라서 실패의 규모는 당신의 파이프라인 (Pipeline)이 얼마나 잘 정돈되어 있는지에 비례하여 커집니다.

내가 바꾸고 싶은 것

유보적인 언어 (Hedging language)를 감사 (Audit)하는 것을 중단하십시오. 그것은 장식적일 뿐이며 모두가 대충 훑어보고 지나갑니다.

형태 (Shape)를 감사하십시오.

출력물 내의 어떤 주장들이 권위 있는 컨테이너 (Authority container) 안에 들어 있는지 물으십시오. 표, 행렬, 타입이 지정된 필드, 백분율, 헤더 행이 있는 모든 것이 대상입니다. 각각에 대해, 그 값들이 출처 (Source)에서 왔는지 아니면 회상 (Recall)에서 왔는지 물으십시오.

만약 회상에서 온 것이라면, 컨테이너를 부여해서는 안 됩니다. 대신 의구심과 동일한 부드러운 어조의 문장으로 작성해야 합니다. 그래야만 신뢰도 신호 (Confidence signal)와 인식론적 상태 (Epistemic status)가 마침내 일치하게 됩니다.

이것이 해결책의 전부입니다. 출처 (Sourcing)에 맞춰 형식을 격하시키십시오.

그 필연적인 결과는 불편하지만, 저는 그것이 옳다고 생각합니다. 만약 어떤 주장이 검증(Verification)에 드는 비용을 감수할 가치가 없다면, 그것은 표의 한 행(Table row)을 차지할 가치도 없습니다. 검증을 하거나, 아니면 모호하게 말하십시오. 아무것도 확인하지 않고 아름답게 형식을 갖추는 중간 단계의 선택이야말로, 사람들이 피해를 입게 되는 '확신에 찬 오답'을 만들어내는 원인입니다.

검증이 되돌려준 것

말할 가치가 있는 내용입니다. 왜냐하면 검증은 보통 순수한 보험(Insurance)처럼 판매되곤 하지만, 실제로는 그렇지 않기 때문입니다.

실제 검증을 수행했을 때, 회상(Recall)만으로는 전혀 만들어낼 수 없었던 무언가가 드러났습니다. 우리가 확인하던 플랫폼에서 누락되었던 제목 중 하나가, 우리 중 누구도 언급할 생각을 못 했던 서비스에서 광고와 함께 무료로 제공되고 있다는 사실이 밝혀졌습니다.

이것은 제가 거의 출시할 뻔했던 답변보다 더 나은 답변입니다. 수정된 답변이 아니라, 더 나은 답변입니다.

검증은 보통 틀리는 것을 피하기 위해 지불하는 세금(Tax)으로 프레임이 잡히곤 합니다. 하지만 실제로 검증은 명확하지 않은 정답들이 존재하는 곳이기도 합니다. 왜냐하면 실시간 소스(Live source)는 회상(Recall)이 알 수 없는 것들을 알고 있기 때문입니다.

당신의 차례

당신이 알고 있는 것보다 더 확신을 가지고 형식을 갖추었던 마지막 것은 무엇인가요?

표(Table), 차트(Chart), 추정치(Estimate), 스키마(Schema), 무엇이든 상관없습니다. 주제가 아니라 형식을 원합니다.

이것이 유용했다면

저는 성공과 정체(Freeze)를 모두 포함하여 이 과정을 공개적으로 진행하고 있으며, 주로 LinkedIn과 YouTube에서 활동합니다. 공개적으로 빌딩(Building in the open)하는 것의 진정한 버전이 당신에게 유용하다면, 그곳에 제 작업물이 있습니다. X, GitHub에서 저를 찾거나 next8n.com에서 작업물을 확인하세요.