답변 자체에 대한 검사
답변이 전송되기 전에 통과하는 검사들 — 각각이 무엇을 잡아내고, 얼마나 자주 작동하며, 왜 "자주 작동하는 검사"는 꼼꼼함이 아니라 버그인지.
검색은 모델이 무엇을 볼 수 있는지를 정합니다. 이 페이지는 모델이 다 쓰고 난 뒤의 이야기입니다. 마지막 토큰이 생성된 순간부터 답변이 누군가의 화면에 나타나기까지, 그 사이입니다.
이 단계가 존재하는 이유는 다소 불편한 관찰 하나에서 옵니다. 프롬프트에 적은 규칙은 부탁일 뿐입니다. "자료에 없는 수치를 말하지 말 것"을 매 턴 맨 앞에 적을 수는 있고, 대부분의 턴은 그것을 지킵니다. 그리고 지키지 않은 턴이 바로, 주의 깊은 독자라면 잡아냈을 그 턴입니다. 그래서 실제로 작동하는 규칙은 부탁이 아니라 완성된 문장에 대한 검사로 씁니다. 코드 안에서 돌고, 그 문장이 자료에 있거나 없거나 둘 중 하나입니다.
검사 하나의 모양
여기 있는 모든 검사는 같은 세 부분으로 이루어지며 순서가 고정되어 있습니다. 그리고 그 순서가 이것을 감당할 수 있게 만듭니다.
- 결정적 사전 검사. 방금 쓰인 답변에 대한 문자열·패턴 대조 — 모델 호출 없음, 왕복 없음. 거의 언제나 "이 모양은 없다"고 말하고 검사는 거기서 끝납니다.
- 사전 검사가 걸렸을 때만 치르는 한 번의 추출 호출. 모델에게는 자료에서 문장을 글자 그대로 옮겨 적는 일만 시킵니다. 판단하게 하지도, 결론을 내게 하지도 않습니다. "이것이 허용되는지를 말하는 문장을 모두 옮겨 적어라"는 대조 가능한 질문이지만, "이 답변이 맞느냐"는 그렇지 않습니다.
- 판정은 코드로 되돌립니다. 옮겨 적힌 문장은 자료에 한 글자도 다르지 않게 나타날 때만 인정됩니다. 이 대조가 없으면 판정자가 문장을 지어내어 옳은 답변을 뒤집을 수 있습니다 — 가정이 아니라, 이 대조가 존재하는 바로 그 이유입니다.
자주 작동하는 검사는 버그입니다. 여기 있던 검사 하나는 한때 "대문자 단어 뒤에 코드가 붙는" 형태로 답변이 어떤 등급을 언급했는지를 판정했습니다. 규제 문서에서 이 형태는 조문 인용, 통화 코드, 화학물질 등록번호, 월 이름과 겹칩니다 — 그리고 within, 예컨대 "30 영업일 이내에 신청해야 한다" 와도요. 100회 중 57회 작동했고, 그때마다 추출 호출 한 번과 완전한 재작성 한 번을 썼습니다. 그것도 이미 맞았던 답변에 대해서요. 진짜 등급 용어에 맞춰 고치니 4회로 줄었습니다. 명중률이 높은 검사는 꼼꼼한 것이 아니라 대상을 잘못 재고 있는 것이며, 그 값을 당신의 응답 시간으로 치릅니다.
각각이 잡아내는 것
모두, 나가지 말았어야 할 답변이 나갔기 때문에 존재합니다. 작동률은 저장된 실제 답변에 대해 측정했고, 의도적으로 낮게 유지합니다.
| 답변이 하는 일 | 왜 중요한가 | 작동률 |
|---|---|---|
| 자료가 무언가를 명시적으로 허용/금지한다고 말하지만 자료에 그런 문장이 없음 | "자료에 X라고 쓰여 있다"는 원문에 대한 주장이므로 글자 단위로 확인할 수 있음 | 279건 중 2건 |
| **"예, 인정됩니다"**라고 답하지만 자료는 문자 그대로 인정되지 않는다고 씀 | 이 제품이 낼 수 있는 최악의 실패입니다. 고객이 그것을 믿고 신청서를 준비했다가 반려됩니다 | 300건 중 1건 |
| 어느 검색 단락에도 없는 수치를 제시함 | 인용 표시가 붙은 숫자는 에이전트가 틀릴 수 있는 것 중 가장 설득력 있습니다 | — |
| 자료가 전부 한 관할에서 왔는데 어느 관할인지 밝히지 않고 수치를 줌 | 수수료와 기한은 시장마다 다르고, 귀속 없는 숫자는 엉뚱한 곳에 쓰입니다 | — |
| 질문이 지목한 문서가 아니라 홀로 다른 문서에서 온 단락을 인용함 | 두 문서는 거의 같은 내용을 담기 쉽고, 문구가 더 잘 맞는 쪽이 대개 틀린 쪽입니다 | 399건 중 2건 |
| 자료의 예외 조항을 인용한 다음 일반 관행으로 그것을 뒤집음 | 자료를 제대로 읽고 나서 논증으로 지워버린 경우입니다 | 109건 중 1건 |
| 답변 전체가 답이 아니라 도구 호출 그 자체 | 원시 호출 구문은 독자에게 절대 도달해서는 안 됩니다 — 오픈 모델에서 실행하기 참조 | — |
표의 대시는 누락이 아닙니다. 그 검사들은 여기 적은 측정 원칙보다 앞서 있었고 작동률을 같은 방식으로 세지 않았습니다. 숫자를 인용할 수 있어서가 아니라 실제로 돌고 있기 때문에 올려두었습니다.
걸렸을 때 일어나는 일
같은 자료를 모델 앞에 그대로 둔 채 한 번 더 쓰게 합니다. 첫 시도의 무엇이 잘못되었는지 알려주는 한 문장을 덧붙여서요. 삭제도, 사과문으로의 교체도 아닙니다.
의도한 선택입니다. 질문에 답할 자료는 대개 아직 거기에 있습니다 — 첫 시도가 그것을 지나쳤거나, 옆 행을 읽었거나, 얼버무렸을 뿐입니다. 같은 단락으로 다시 쓰면 되찾을 수 있습니다. 거절하면 되찾을 수 없습니다.
그 교정 문장에는 값을 치르고 배운 규칙이 하나 있습니다. 무엇을 내놓아야 하는지만 말하고, 무엇을 하지 말라고는 결코 말하지 않는다. 이전 판은 잘못된 형식을 세 개의 실례로 보여준 다음 그 형식을 내놓지 말라고 부탁했습니다. 모델은 그것을 또 내놓았고, 독자는 답 대신 사과를 받았습니다 — 답은 검색된 자료 안에 한 글자도 다르지 않게 들어 있었는데도요.
"틀렸다"고만 말하는 교정은 대개 아무것도 바꾸지 못합니다. 다른 문서에서 온 단락을 인용한 답변을 잡는 검사가 있습니다. 그것만 알려주자 모델은 세 번 중 세 번 똑같이 다시 답했습니다 — 자신이 맞는 문서를 쓰고 있다고 믿었기 때문입니다. 결과를 바꾼 것은 모델이 스스로 도출할 수 없는 대응 관계를 건네준 일이었습니다. 이 단락 번호들이 질문받은 그 문서의 것이고, 당신이 인용한 것은 아닙니다. 그래도 제대로 고쳐지는 것은 세 번에 한 번 정도입니다. 이 검사는 자신이 "해결"이 아니라 "개선"임을 정직하게 밝힙니다.
이 단계가 하지 않는 것
- 답변이 참인지는 검사하지 않습니다. 검사하는 것은 답변의 자료에 대한 주장이 참인지입니다. 이는 다른 문제이고, 여기서 판정할 수 있는 것은 후자뿐입니다.
- 대부분의 턴에서는 작동하지 않습니다. 설계된 대로입니다. 위의 낮은 작동률은 설계의 핵심이지 한계가 아닙니다.
- 자료가 옳은 것을 대신하지 못합니다. 질문을 결정짓는 단락이 애초에 검색되지 않았다면, 출력에 대한 어떤 검사도 그것을 만들어낼 수 없습니다. 그것은 검색 쪽의 문제이고, 거기서 해결되거나 아예 해결되지 않습니다.
- 모든 검사는 판단이 서지 않으면 통과시킵니다. 추출 호출이 실패하거나 해석할 수 없는 값을 돌려주면 답변은 쓰인 그대로 나갑니다. 백엔드가 느릴 때 답변을 막을 수 있는 검증 계층은, 막으려던 것보다 나쁜 실패입니다.
관련
- 근거 있는 답변 — 애초에 모델이 무엇을 볼 수 있었는가
- 오픈 모델에서 실행하기 — 이 단계가 출구에서 받아내는 모델 계층의 고장들
- 작성 파이프라인 — 같은 원칙을 긴 문서에 적용한 것