길고 무질서한 컨텍스트를 모델에 붙여넣고 질문 하나를 던지면, 모델은 내용을 훑어만 봅니다. 이는 게으름 때문이 아니라, 측정 가능한 현상입니다. 긴 컨텍스트 (Long-context) 모델들은 U자형 정확도 곡선을 보여줍니다. 즉, 정보가 입력값의 맨 처음이나 맨 끝에 있을 때는 정보를 가장 잘 활용하지만, 동일한 사실이 중간에 위치할 때는 눈에 띄게 성능이 저하됩니다. 어텐션 (Attention)은 초두 효과 (Pracimacy)와 최신 효과 (Recency)에 의해 지배됩니다. 따라서 방대한 채팅 스레드 중간에 묻혀 있는 결정 사항은 모델이 가장 취약한 지점이며, 가장자리에 있는 더 큰 방해 요소가 대신 선택될 수 있습니다. Thread of Thought (Zhou et al., 2023)는 입력을 단축하지 않고도 이 문제를 해결하며, 저는 이를 증명하기 위해 라이브 데모를 제작했습니다. 사용자가 숨겨진 사실을 어디로 드래그하든 이를 찾아내는 실제 청크별 관련성 점수 계산기 (per-chunk relevance scorer), 날짜 추출기 (date extractor), 그리고 최종성 탐지기 (finality detector)를 직접 확인할 수 있습니다.

Chain-of-thought는 잘못된 단계를 수정한다

가장 명백한 업그레이드는 "단계별로 생각해보자"입니다. 이는 실제로 도움이 되지만, CoT (Chain-of-thought)는 추론 (reasoning) 단계를 나누는 것이지, 읽기 (reading) 단계를 나누는 것이 아닙니다. 컨텍스트는 여전히 단 한 번의 패스 (pass) 동안 나눌 수 없는 하나의 덩어리로 소비되므로, 모델이 훑어 지나친 사실은 추론 과정에 전혀 진입하지 못합니다. 불완전한 그림을 바탕으로 아름답게 추론할 수는 있지만, 결과는 여전히 틀릴 수 있습니다. ThoT의 통찰은 수정이 읽기 단계에서 이루어져야 한다는 것입니다:

// CoT: 더 나은 추론, 하지만 덩어리를 한 번에 읽는 방식은 동일함
llm(context + question + "Let's think step by step.");
// 모델이 훑어 지나간 중간 컨텍스트의 사실은 논리에 도달하지 못함.

전체 기술은 단 한 줄의 제로샷 (zero-shot) 문장이다

나를 놀라게 한 점은 ThoT가 얼마나 저렴한가 하는 것입니다. 리트리버 (retriever)도, 두 번째 모델도, 추가적인 API 호출도 필요 없습니다. 프롬프트에 추가되는 단 한 문장이면 충분합니다:

const THOT = "Walk me through this context in manageable parts " +
             "step by step, summarizing and analyzing as we go.";
llm(`Context: """${context}"""
Question: ${question}
${THOT}`);

그 한 줄의 코드는 모델의 동작 방식을 "훑어보고 답하기"에서 "분할, 요약, 그 다음 답하기"로 재구성합니다. 이것이 바로 논문에서 제시한 정확한 제로샷 프롬프트 (zero-shot prompt)이며, 기존의 어떤 프롬프트에도 거의 비용 없이 결합할 수 있다는 점 때문에 매우 매력적입니다.

각 부분을 분할하고 요약하며, 실행 중인 스레드(running thread)를 유지하기

개념적으로 ThoT는 세 가지 작업을 수행합니다. 먼저 긴 컨텍스트 (context)를 메시지, 단락 또는 윈도우 (window) 단위로 관리 가능한 부분으로 나눕니다. 이렇게 하면 각 부분이 개별적인 패스 (pass)에서 충분한 주의 (attention)를 받을 수 있을 만큼 작아지므로, 모든 세그먼트 (segment)가 읽히는 대상이 되는 짧은 순간 동안 정보가 "중간"에서 유실되는 일이 발생하지 않습니다. 각 부분에 대해 모델은 짧은 요약을 작성하고 질문과의 관련성을 판단합니다. 즉, 이것이 핵심 사실인지, 더 이상 유효하지 않은 세부 사항인지, 아니면 노이즈 (noise)인지를 판별합니다. 그런 다음 이러한 요약들은 **실행 중인 스레드 (running thread)**로 축적됩니다. 이는 압축되고 순서가 정렬된 외부화된 메모리 (externalized memory)로, 숨겨진 사실은 이제 명시적이며 방해 요소들은 이미 라벨링 (labeling)되어 있습니다.

let thread = [];
for (const p of parts) thread.push(summarize(p));   // 각 부분별 핵심 내용
const answer = synthesize(thread, question);        // 스레드를 통한 답변 생성

최종 답변은 가공되지 않은 덩어리 (raw blob)가 아니라 해당 스레드로부터 합성 (synthesize)됩니다. 스레드가 이미 결정적인 사실을 분리하고 노이즈를 낮추었기 때문에, 합성 과정은 짧고 정확합니다.

작동 원리 — 균등한 주의 (attention)와 기록된 메모리

두 가지 메커니즘이 결합되며, 데모를 통해 두 방식 모두를 확인할 수 있습니다. 데모에서는 일곱 개의 메시지로 구성된 지저분한 스레드 속에 하나의 실제 결정 사항인 "출시일을 4월 9일로 확정합니다. 이것으로 끝입니다"라는 내용이 방해되는 날짜들(원래 목표였던 3월 14일, 관련 없는 5월 2일 전사 회의, 여전히 3월 14일로 표시된 오래된 문서) 사이에 숨겨져 있습니다. 원샷 리더(one-shot reader)는 위치 주의 가중치(positional attention weight, 양 끝단은 높고 중앙은 낮은 방식)에 얕은 표면적 관련성(shallow surface relevance)을 곱하여 사용하므로, 가장자리에 위치한 날짜가 포함된 청크(chunk)를 무작정 잡아냅니다. 반면 Thread of Thought (ThoT)를 활성화하면, 모든 청크를 균등한 주의(equal attention)를 기울여 훑으며 각 핵심 사항(takeaway)을 기록하고, 오직 최종(final) 결정으로 표시된 청크만을 합성합니다. 이 결정 사항을 시작, 중간, 또는 끝으로 옮겨보더라도 원샷 답변은 위치를 따라 변하지만, ThoT 답변은 4월 9일에 고정되어 있습니다. 세그멘테이션(Segmenting, 분할)은 U자형 주의 곡선을 평탄하게 만들며, 각 핵심 사항을 스레드에 기록함으로써 답변이 나오기 전까지 읽은 내용이 소실(decaying)되지 않도록 유지합니다. 이들이 결합되어 읽기 작업의 위치 불변성(position-invariant)을 만들어냅니다.

언제 사용할 것인가

복잡하게 얽힌 채팅 기록, 다중 문서 질의응답 (multi-document QA), 방해 요소가 가득한 검색 결과물 (retrieval dumps), 건더기 찾기 (needle-in-a-haystack) 작업처럼 큰 입력값 안에 사실이 묻혀 있을 수 있는 모든 경우에 ThoT를 사용하세요. 이는 검색 파이프라인 (retrieval pipeline)보다 저렴합니다. 인덱스(index) 없이 단 하나의 프롬프트만 사용하면 되기 때문입니다. 또한 검색된 구절들을 ThoT로 훑게 함으로써, 검색된 내용 _내부_에서 발생하는 "중간에서 길을 잃는 (lost in the middle)" 현상을 방지하는 방식으로 결합하여 사용할 수도 있습니다. CoT (Chain of Thought)와 비교했을 때, 이들은 깔끔하게 계층적으로 쌓입니다. CoT는 추론(reasoning)을 분할하고, ThoT는 읽기(reading)를 분할합니다. 아무것도 묻혀 있지 않고 길을 잃을 '중간'조차 없는 짧고 깔끔한 프롬프트라면 이 방식을 건너뛰어도 좋습니다.

스위치를 켜고 숨겨진 결정 사항을 이리저리 옮겨보며 두 답변이 어떻게 갈라지는지 확인해 보세요:
https://dev48v.infy.uk/prompt/day45-thread-of-thought.html