StateBench 분석: 긴 문서를 읽은 AI는 왜 최종 상태를 틀릴까

회의가 끝난 뒤 AI에게 “최종 주문 수량만 정리해 줘”라고 부탁했다고 하자. 회의록 전체가 입력 한도 안에 들어갔고, 각 숫자가 적힌 문장도 정확히 인용했다. 그런데 결론은 틀렸다. 이 경우 문맥 창을 더 넓히거나 검색 결과를 더 붙이는 것이 먼저일까?

답에 필요한 사건을 이미 모두 넣었다면, 다음 질문은 그 사건을 어떤 순서와 의미로 적용했는가다. “A를 8개로 바꾼다”는 덮어쓰기이고, “A에 3개를 더한다”는 누적이다. “B를 지금 A와 같은 수량으로 맞춘다”는 A의 당시 값을 알아야 하는 참조다. 똑같이 짧은 문장이지만 계산에 필요한 이력은 다르다.

Ai2는 2026년 11월 3일 이 차이를 다루는 StateBench를 소개했다. 논문 v1의 제출일은 11월 2일이다. 새로운 챗봇 서비스가 아니라, 긴 입력에서 변하는 상태를 얼마나 잘 따라가는지 평가하는 합성 데이터·연구다. 이 글은 11월 5일 확인한 자료와 자체 구성 사례를 연결한다. 언어모델의 응답 정확도를 직접 측정하지는 않았다. 공식 발표, 논문 v1

마지막 문장을 찾으면 되는 일과 이력을 따라야 하는 일

StateBench는 상태 추적 문제를 네 단계로 구분한다. 아래 왼쪽은 연구의 분류이고, 오른쪽은 차이를 이해하기 위한 자체 업무 비유다. 일반 업무 전체를 수학적으로 분류했다는 뜻은 아니다. 연구진의 단계 설명

연구의 단계	필요한 정보	업무에서 생각해 볼 비유
r-trivial	처음 정해진 값	변경하지 않는 문서 식별자
aperiodic	나중에 다시 지정된 값	납품 장소를 부산에서 대전으로 변경
soluble	자기 상태에 적용한 변화	보유 수량에 추가·차감 적용
general finite	다른 상태와 연결된 변화	두 담당 업무를 서로 교환하거나 당시 수량을 복사

연구의 유한한 숫자 범위에서는 자기 증가 연산이 모듈러 방식으로 돌아간다. 예컨대 0부터 9까지의 값이라면 8에 3을 더한 결과가 1로 순환하는 식이다. 실제 재고가 11개가 되는 업무 계산과 같지 않다. 또한 복사 지시 하나가 있다는 이유만으로 그 업무가 가장 어려운 수학적 문제와 동등해지는 것도 아니다. 가져올 것은 난이도 이름보다, 업데이트가 무엇을 읽는지 나누는 관점이다. 논문 §4의 생성 방식

이 관점에서 문서 길이만으로 평가 묶음을 만들면 중요한 차이를 놓친다. 100쪽 중 한 번 지정된 코드를 찾는 질문은 매우 긴 검색 문제일 수 있다. 반면 짧은 기록 안에서 서로의 값을 여러 번 바꾸는 질문은 모든 문장을 찾아도 중간 상태를 놓치면 틀린다. 후자는 인용의 정확성만으로 정답을 확인하기 어렵다.

연구가 보여준 차이는 어떤 조건에서 나온 것인가

연구진은 같은 원본 업데이트열에서 더 단순한 문제들을 파생했다. 변수 수와 업데이트 위치 같은 조건을 맞춰, 길이가 아니라 연산 종류가 달라질 때를 비교하려는 설계다. 직접학습에서는 무작위로 초기화한 275M 모델들을 최대 256개 대입으로 학습하고, 더 긴 대입열에서 평가했다. 이 설정에서 Gated DeltaNet과 혼합 구조는 일부 단계의 길이 일반화에서 강점을 보였다. 논문 §4·§5

이 결과와 이미 사전학습된 모델을 가져와 푼 결과는 나누어 읽어야 한다. 후자에서는 구조만으로 기대한 능력이 그대로 나오지 않았고, 같은 상태 문제라도 코드·스프레드시트 등 표현 형식에 따라 결과가 달라졌다. 프런티어 모델 평가에서도 긴 자기 참조·일반 유한 상태 문제에서 정확도가 떨어졌다. 연구진의 실험 결과이며 우리 회사의 문서 처리 실패율은 아니다. 논문 §6

필자의 해석은 “순환형 모델로 바꾸면 해결된다”가 아니다. 어떤 구조가 해당 규칙을 학습할 수 있다는 것, 공개 모델이 그 능력을 습득했다는 것, 우리 자료에서 제대로 작동한다는 것은 서로 다른 확인 대상이다. 모델을 고를 때는 구조 이름보다 실제 업무의 업데이트 유형과 입력 형식을 맞춘 결과가 필요하다.

연구는 변수 수가 고정된 유한 상태를 다루며, 대화 중 새로운 사람과 대상이 계속 생기는 경우까지 같은 틀로 해결하지 않는다. 이론적 결과에도 구조·정밀도 등의 조건이 있다. 이를 “Transformer는 상태를 전혀 기억하지 못한다”는 주장으로 확대하면 원문 범위를 벗어난다. 논문 §7의 한계

회의록 사례: A가 나중에 바뀌어도 B는 함께 바뀌지 않는다

다음은 두 전시 부스의 물품 수량을 조정하는 가상 회의 기록이다. 문장을 나열한 순서대로 변경이 확정되며, 취소·조건부 승인·동시 수정은 없다고 가정한다. 실제 고객 자료나 모델의 답변이 아니다.

초기 확정 수량: A 부스 10개, B 부스 20개.
E1. A 부스에 3개를 더한다.
E2. B 부스를 지금 A 부스와 같은 수량으로 맞춘다.
E3. A 부스 수량을 8개로 바꾼다.
E4. B 부스에 2개를 더한다.
질문: 최종 A와 B 수량은 각각 몇 개인가?

사건 적용 뒤	A	B	이때 필요한 해석
초기	10	20	시작 상태
E1	13	20	A의 기존 값에 3을 더함
E2	13	13	그 시점의 A 값을 B에 복사
E3	8	13	A만 덮어씀
E4	8	15	B의 기존 값에 2를 더함

정답은 A 8개, B 15개다. E2는 “앞으로 항상 B를 A와 동기화하라”는 규칙이 아니다. A가 나중에 8개가 되어도 E2에서 복사한 13은 B에 남는다. StateBench 코드도 참조 대입을 그 시점의 값 복사로 정의하며 지속적인 별칭 연결과 구분한다. 고정 커밋의 복사 의미

이 예제에서 “B에 2개를 더한다”는 마지막 문장만 가져오면 시작값이 없다. E2를 함께 찾아도 E1과 초기 상태가 빠지면 복사할 13을 계산할 수 없다. 따라서 필요한 근거는 B가 직접 언급된 문장들의 집합보다 넓다. 이 사례에 한해서는 최종값으로 이어지는 의존 관계를 따라 입력을 구성해야 한다.

반대로 E3는 A의 앞선 수량을 덮어쓴다. A의 최종값만 묻는다면 E1을 몰라도 8을 알 수 있다. 같은 회의록이라도 질문이 A만인지, B인지, 둘 다인지에 따라 필요한 이력이 달라진다. 이것이 모든 문장을 똑같이 요약하는 방식으로는 남기기 어려운 정보다.

같은 기록을 조금씩 바꿔 다음 조사 대상을 좁힌다

아래 기대값은 자체 산술로 확인했다. 각 행을 모델에 넣어 비교하는 실험은 아직 하지 않았다. 사건·중간 상태·기대값 JSON을 내려받아 자체 평가의 출발점으로 쓸 수 있다. StateBench 공식 데이터나 재현 코드가 아니며, 한국어를 자동으로 해석하는 도구도 아니다.

바꾼 조건	기대하는 최종 A / B	비교할 질문
원래 기록	8 / 15	기준 입력을 처리하는가
E2를 “B를 13개로 바꾼다”로 풀어 씀	8 / 15	다른 항목의 당시 값을 찾는 참조가 영향을 주는가
E1을 제거	8 / 12	앞선 사건의 변화가 B까지 반영되는가
E3를 E2보다 먼저 적용	8 / 10	사건 순서를 구별하는가
끝에 수량과 무관한 회의 장소 메모 추가	8 / 15	의미 없는 추가 문장에 답이 흔들리는가

원래 입력은 틀리고 13을 직접 써 준 입력만 맞는다면 참조 해석이나 중간 상태 유지가 다음 점검 대상이다. 그러나 한 쌍의 답만으로 원인을 확정할 수는 없다. 표현 난이도와 생성의 변동성도 함께 바뀔 수 있기 때문이다. 숫자와 부스 이름을 바꾼 여러 사례에서 같은 차이가 나타나는지 확인한다.

한 단계 더 나아가 같은 사건열을 문장형과 행별 표로 표현해 볼 수 있다. 사건의 순서·의미·정답은 그대로 두고 표현만 바꾼다. 표에서만 잘 맞는다면 그 입력 방식이 업무에 맞는지 시험할 이유가 생긴다. 이것은 특정 형식의 보편적 우위를 증명하는 실험이 아니라 우리 처리 경로를 선택하는 비교다.

평가 전에 정할 항목은 다음처럼 간단히 남길 수 있다.

원본 기록 버전 / 질문 대상 / 사건의 적용 순서:
모델 식별자와 확인일 / 생성 설정 / 반복 횟수:
입력 형식 / 해당 모델 토크나이저의 입력 길이:
전체 사건 수 / 정답에 영향을 주는 사건 / 불명확한 문장:
A 일치 여부 / B 일치 여부 / 전체 상태 일치 여부:
출력 파싱 실패 / 첫 불일치 사건 / 근거 문장:
다음 변경: 입력 정리, 참조 해석, 계산 분리, 또는 모델 비교

필드별 일치와 전체 상태 일치는 따로 본다. A를 맞추고 B를 틀린 답을 “절반 성공”으로 셀 수는 있지만, 두 부스의 발주서를 함께 확정해야 하는 업무에서는 완료된 건이 아니다. 파싱 실패를 분모에서 빼거나, 어려운 참조 사례를 쉬운 값 찾기 사례에 섞어 평균만 내면 도입 판단이 달라질 수 있다.

실무에서는 해석과 상태 계산을 어디서 나눌까

규칙이 명확한 반복 업무라면 모델에게 매번 최종 숫자까지 추론시키는 대신, 원문에서 사건을 읽는 단계와 사건을 적용하는 단계를 분리하는 설계를 비교할 수 있다. 이 사례의 E2를 대상=B, 연산=copy, 원본=A, 순서=2로 확인한 뒤 계산기가 그 시점의 상태를 적용하는 방식이다. 위 산술 확인도 이렇게 이미 해석된 사건만 사용했다.

분리하면 잘못된 최종값을 추적하기 쉬워진다. E2를 “항상 동기화”로 읽었다면 해석 단계의 오류이고, 올바른 복사 사건을 받고도 B가 E3에서 바뀌었다면 적용 로직의 오류다. 중간 상태를 남기면 두 경우를 구별할 수 있다. 다만 모델의 사건 추출이 틀리면 정확한 계산기도 틀린 입력을 충실하게 적용한다.

실제 회의에는 “가능하면 3개 추가”, “아까 변경은 보류”, “A와 동일하게 유지”처럼 예제의 가정을 깨는 문장이 있다. 조건이 충족됐는지, 무엇을 취소했는지, 일회성 복사인지 지속 규칙인지 확인되지 않으면 확정 사건으로 바꾸지 않는다. 현재값과 함께 미확정 사항을 남기는 편이 근거 없는 숫자로 발주를 진행하는 것보다 낫다.

모든 문서에 별도 계산기가 필요한 것은 아니다. 짧은 일회성 요약이고 담당자가 원문을 대조할 수 있다면 직접 읽고 검토하는 흐름이 더 단순할 수 있다. 반복되는 수량·담당자 변경을 다른 시스템에 자동 반영할 때, 사건의 의미와 순서가 충분히 정의된 경우부터 분리를 검토한다. 이 설계의 비용 절감이나 정확도 향상은 이번 글에서 측정하지 않았다.

StateBench를 직접 평가할 때는 발표와 현재 데이터를 구분한다

공식 자료를 확인하면서 실제로 달랐던 부분이 있다. 논문은 여섯 표현 형식을 설명하지만, 11월 5일 확인한 데이터 카드에는 다섯 formatter가 나열되어 있다. 코드 README는 현재 구성에서 RULER를 제외했으며 예전 구성을 v1-with-ruler 등으로 보존한다고 설명한다. 따라서 현재 main을 내려받았다는 말만으로 논문의 입력을 그대로 재현했다고 할 수 없다. 고정 코드 README, 고정 데이터 카드

논문의 soluble은 공개 데이터의 solvable, general finite는 코드의 periodic 이름과 연결해 읽어야 한다. 현재 모듈러 숫자 formatter는 증가 연산을 표현하지만 모든 표현 형식이 그 연산을 지원하지는 않는다. 같은 출발 사건을 짝지어 비교하려면 README가 제시하는 source_example_id·source_instance_id도 확인할 대상이다. 고정 코드의 생성 계약

데이터의 토큰 구간도 모든 모델의 입력 길이가 아니다. 카드는 Olmo 계열 토크나이저로 prefix 길이를 나눈다고 명시한다. 다른 모델로 평가한다면 실제 전송한 입력을 그 모델 기준으로 다시 세고, 잘림 여부와 생성 여유를 별도로 남겨야 한다. 문서 개정·데이터 revision·표현 형식·길이 측정법을 함께 고정하는 것이 점수 비교의 출발점이다. 데이터 카드의 길이 구간 설명

당장 팀에서 시작할 일은 긴 문서 전체의 점수를 하나 더 만드는 것보다 작다. 실제로 틀리면 곤란한 최종 상태 질문 하나를 고르고, 그 답에 영향을 주는 사건을 확인한 뒤, 위처럼 참조·순서·표현을 바꾼 대조 입력을 만든다. 값 찾기는 잘하지만 변경 적용이 약한 경우를 분리해야 다음 모델이나 처리 구조를 고를 근거가 생긴다.

근거가 애초에 입력에서 빠졌다면 긴 문맥과 RAG의 오류 진단부터, 평가자의 질문 방식에 따라 판정이 달라진다면 AI 신규성 심사 연구의 평가 조건에서 이어 읽을 수 있다. 이 사례를 다시 평가할 때는 상단 저장 기능을, 후속 연구는 AI 시스템 모음과 RSS를 이용할 수 있다.