화면은 옛 모델 이름을 계속 말하고 있었다

이미지를 읽고 그 내용을 구조화된 데이터로 남기는 파이프라인이 있다. 그 판독기 하나를 다른 기계로 옮겼는데, 알고 보니 데이터베이스 값 한 줄만 바꾸면 되는 일이었다 — 재배포도 필요 없었다. 워커가 작업마다 그 값을 다시 읽으므로 재시작 없이 즉시 전환됐다. 새 기계로 읽은 왕복 시간은 7~12초였고, 옛 판독기는 평균 50초 안팎이었다. 검증용 이미지 33장 전부 파싱에 성공했다. 종이 위로는 완벽한 승리였다.

그런데 지금 어떤 모델이 읽고 있는지를 보여주는 화면 머리말이 그렇게 읽지 않았다. 방금 은퇴한 판독기 이름을 계속 표시하고 있었다 — 머리말이 고정된 설정값을 가져오고 있었지, 방금 실제로 돌아간 작업을 가져오는 게 아니었기 때문이다. 결과가 이상해 보이면 사람은 엉뚱한 판독기 쪽에서 원인을 찾게 된다. 이 화면은 시스템의 의도에 대해 거짓말을 한 게 아니라 실제로 일어난 일에 대해 거짓말을 한 것이고, 그게 더 나쁜 종류의 거짓말이다 — 여전히 권위 있게 보이니까. 고친 방식은 머리말에게 “무엇으로 설정돼 있나”를 묻는 대신, 가장 최근 작업에게 “실제로 무엇이 처리했나”를 묻게 만드는 것이었다. 이 질문을 위한 작은 상태 확인 창구를 새로 만들었다.

두 판독기는 쉬운 문제에서만 일치한다

두 판독기가 실제로 함께 쓸 수 있게 되자, 같은 이미지 6장을 양쪽에 돌려 카메라 높이와 카메라 각도, 두 항목에 대한 답을 비교했다. 두 항목 다 6장 중 4장이 일치했고, 일치한 이미지들은 특별할 것 없는 평범한 구도였다. 원래 생성 지시문에서 “낮은 각도에서 찍은” 것으로 명시된 이미지 하나에서는, 한 판독기가 “낮은 위치에서 아래로 내려다봄”이라 답했고 다른 판독기는 “높은 위치에서 위로 올려다봄”이라 답했다 — 완전히 반대인데, 각자는 자기 안에서 모순이 없었다. 어느 쪽도 뚜렷하게 맞다고 할 수 없었다.

더 쓸모 있는 신호는 다른 곳에서 나왔다. 서로 다른 이미지 두 장에서, 절대 서로의 답을 볼 수 없는 두 판독기가 독립적으로 같은 결론에 도달했는데, 그 결론이 그 이미지가 애초에 그리도록 지시받은 내용과 정면으로 어긋났다 — 프롬프트에는 “정면을 보고 있다”고 명시됐는데 둘 다 “뒤돌아 서 있다”고 답했다. 서로를 모르는 두 판독기가 같은 오답에서 만나면, 그건 더 이상 판독기의 잡음처럼 보이지 않는다 — 오히려 생성기가 지시대로 만들지 않았다는 신호로 읽힌다. 판독기끼리의 불일치는 신뢰하기 힘든 항목을 가리키고, 원본 지시문과 어긋나는 지점에서의 일치는 전혀 다른 곳을 가리킨다 — 읽는 쪽이 아니라 만든 쪽을.

컨텍스트 창은 걱정보다 훨씬 여유가 있었다

별개로, 메모리를 아끼려고 컨텍스트 창 길이를 4분의 1로 줄이자는 제안이 있었는데, 논쟁 대신 실측으로 확인했다. 실제 요청 수천 건의 토큰 사용량을 전부 합산해보니, 입력과 출력을 합친 최대값이 2,500 토큰이 안 됐다 — 전체 창 길이 16,000여 토큰의 극히 일부다. 실제 이미지 두 장을 줄인 창으로 직접 돌려보니 큰 창과 항목 하나하나까지 동일한 결과가 나왔다. 다만 정직하게 남겨야 할 단서 하나 — 반복 실행에서 값 몇 개가 창 크기에 따라 살짝 흔들렸는데, 이건 창 크기 자체 때문일 수도 있고 그냥 통상적인 표본 잡음일 수도 있다. 둘을 가르려면 같은 이미지를 각 설정에서 여러 번 돌려야 하는데, 아직 안 했다.

두 이야기는 같은 결을 갖고 있다. 설정을 보여주도록 만든 화면은 그 설정이 더는 사실이 아니게 된 뒤에도 한참 동안 계속 그 설정에 대해서만 진실을 말한다. 시스템이 무엇을 하도록 지시받았는지가 아니라 실제로 무엇을 했는지를 기록에서 읽는 것 — 결과가 이상해 보일 때 물어야 할 질문은, 대개 그것뿐이다.