3줄 요약이 원문을 왜곡하는 순간
요약이 틀려서 사고가 나는 경우는 드뭅니다. 대개는 요약에서 빠진 단서가 결정적이었습니다.
요약 기능을 만들면서 확인한 것 중 하나는, 모델이 만든 요약은 틀리는 일이 별로 없다는 것입니다. 문장 단위로 보면 원문에 있는 내용이고 사실 관계도 맞습니다. 그런데도 요약본만 읽고 판단했다가 나중에 곤란해지는 일이 생깁니다.
원인은 대체로 같습니다. 요약이 틀린 게 아니라 요약에서 빠진 것이 결정적이었던 경우입니다.
사라지는 것은 대체로 정해져 있다
여러 종류의 글을 넣어 보면서 반복적으로 관찰된 패턴이 있습니다. 압축 과정에서 가장 먼저 떨어져 나가는 정보는 아래와 같습니다.
| 빠지는 것 | 왜 빠지나 | 빠지면 생기는 문제 |
|---|---|---|
| 시점·기간 한정 | 수식어라 부차적으로 보임 | "매출 30% 증가"가 언제 기준인지 사라짐 |
| 전제 조건 | 문장 중간의 종속절에 있음 | 조건이 안 맞는 상황에 결론만 적용됨 |
| 수치의 출처·표본 | 괄호 안에 있는 경우가 많음 | 근거가 약한 숫자가 사실처럼 굳어짐 |
| 반대 의견·한계 | 글의 뒷부분에 몰려 있음 | 균형 잡힌 글이 한쪽 주장으로 바뀜 |
| 예외 사례 | 분량이 짧음 | "항상 그렇다"로 읽힘 |
공통점이 보입니다. 전부 문장에서 부수적인 위치를 차지하는 정보입니다. 요약은 문장의 중심을 남기고 주변을 버리는 작업이라, 구조적으로 이것들이 먼저 사라집니다.
가장 자주 문제가 되는 건 첫 번째와 세 번째입니다. 숫자는 요약에 잘 살아남는데, 그 숫자에 붙어 있던 조건은 잘 살아남지 못합니다. 그래서 요약본에서는 숫자가 원문보다 더 확실해 보입니다.
목적에 따라 남겨야 할 것이 다르다
같은 글이라도 왜 요약하느냐에 따라 남겨야 할 부분이 달라집니다. 이걸 무시하고 만든 요약은 어느 쪽에도 잘 맞지 않습니다.
- 훑어보기용이면 결론과 전개만 있으면 됩니다. 단서는 없어도 됩니다.
- 팀 공유용이면 사람들이 이어서 물어볼 질문을 예상해 근거를 남겨야 합니다.
- 판단 근거용이면 결론보다 전제와 한계가 더 중요합니다. 결정을 뒤집을 수 있는 정보가 빠지면 요약이 아니라 왜곡입니다.
- 공부용이면 용어 정의와 구조가 남아야 합니다.
3줄 요약 해봄에서 목적을 먼저 묻는 이유가 이것입니다. 목적을 알면 무엇을 버릴지 다르게 정할 수 있습니다.
"잘려나간 것" 항목을 넣은 이유
이 도구에는 요약 아래에 요약하면서 잘려나간 것을 따로 적는 항목이 있습니다. 처음에는 부가 기능으로 넣었는데, 써 보니 이쪽이 3줄 요약보다 더 자주 쓰이는 부분이 됐습니다.
그리고 프롬프트에 한 가지 규칙을 넣었습니다. "없음"이라고 답하지 말 것입니다. 모델은 그냥 두면 "특별히 빠진 내용은 없습니다"라고 쓰는 경향이 있습니다. 편하긴 한데 사실이 아닙니다. 3줄로 줄이면서 아무것도 안 버리는 건 불가능합니다. 억지로라도 찾아내게 하면 대개 정말로 중요한 것이 하나쯤 나옵니다.
요약본을 쓸 때의 최소한의 규칙
실무에서 지키면 대부분의 사고를 막을 수 있는 규칙은 두 개입니다.
- 요약본을 근거로 결정하지 않는다. 요약은 원문을 읽을지 말지 정하는 데 씁니다. 결정은 원문을 보고 합니다.
- 요약본을 남에게 전달할 때는 원문 링크를 같이 보낸다. 요약만 전달되면 받은 사람은 그게 전부인 줄 알게 됩니다.
당연한 말 같지만 실제로는 잘 안 지켜집니다. 요약이 충분히 그럴듯하기 때문입니다. 그럴듯함이 곧 정확함은 아니라는 게 이 도구를 만들면서 가장 자주 확인한 사실이었습니다.