[arXiv 2606.31435] CDR-Bench: 순서 민감 데이터 정제 레시피를 얼마나 충실히 실행하는가

CDR-Bench: Evaluating Faithful Execution of Compositional, Order-Sensitive Data Refinement Recipes

https://arxiv.org/abs/2606.31435

Yuchen Huang, Xiang Li, Zhenqing Ling, Sijia Li, Qianli Shen, Daoyuan Chen, Yi R. (May) Fung, Yaliang Li | HKUST, NUS, Tongyi Lab, Alibaba Group | arXiv:2606.31435 | 2026년 6월

---

데이터 정제는 LLM 응용에서 조용하지만 매우 중요한 병목이다. 웹 문서를 긁어 오면 광고 문구, 중복 줄, LaTeX 잔여 기호, 개인정보, 검색용 청크를 망치는 잡음이 섞인다. 실제 파이프라인은 이런 원문에 하나의 편집 명령만 적용하지 않는다. 보통 여러 operator를 정해진 순서로 연결하고, 어느 단계에서는 텍스트를 고치며, 어느 단계에서는 필터 조건에 따라 샘플 전체를 버린다. CDR-Bench는 바로 이 지점을 정면으로 묻는다. 최신 LLM은 그럴듯한 정제 결과를 만들 수는 있지만, 사용자가 지정한 여러 단계 레시피를 실제 연산 순서대로 충실히 실행하고 있는가.

논문의 답은 꽤 냉정하다. CDR-Bench는 Data-Juicer 기반의 29개 연산과 Web Refinement, LaTeX Refinement, RAG Preparation, Privacy Redaction 네 도메인에서 3,462개 과제를 구성한다. 금 표준은 LLM judge가 판단한 선호도 대신 결정적 프로그램 실행 결과로 정해진다. 그래서 모델 출력이 보기에는 자연스러워도, 레시피 중 한 단계가 빠졌거나 필터가 적용될 시점이 어긋나면 성공으로 보지 않는다. 실험은 atomic 연산 성공률과 조합 레시피 성공률 사이에 큰 틈이 있으며, 특히 순서가 바뀌면 결과가 달라지는 Order-M과 Order-F에서 group-level 성공률이 급격히 낮아진다는 점을 보여 준다.

1. 서론: 데이터 정제 레시피 실행을 별도 능력으로 보기

1.1 왜 단일 편집 성능만으로는 부족한가

LLM을 데이터 준비에 쓰는 방식은 크게 두 갈래로 나뉜다. 하나는 모델에게 코드를 쓰게 하거나 도구를 호출하게 해서 표, 로그, 문서 컬렉션을 처리하는 방식이다. 다른 하나는 모델 자체에게 원문과 자연어 지시를 주고 정제된 텍스트를 직접 내게 하는 방식이다. 전자는 실제 시스템에 가깝지만 coding, tool use, environment interaction, schema 이해가 한꺼번에 섞인다. 후자는 모델의 언어 이해와 편집 능력을 직접 보지만, 기존 benchmark는 대개 단일 instruction editing 또는 isolated detection에 머물렀다. CDR-Bench가 겨냥하는 틈은 이 둘 사이에 있다. 코드를 작성하지 않아도, 텍스트 정제 레시피는 여러 operator가 시간 순서대로 이어지는 절차적 문제다.

예를 들어 “HTML 태그를 제거하고, 너무 짧은 줄을 버리고, 개인정보를 마스킹한 뒤, 검색 인덱싱에 맞게 문단을 나누라”는 요청은 한 문장처럼 보이지만 사실상 실행 그래프다. 앞 단계의 출력이 다음 단계의 입력이 되며, 중간 필터가 DROP을 결정하면 뒤 단계는 더 이상 실행되지 않아야 한다. 모델이 마지막 결과만 보기 좋게 재작성하면 사용자는 그럴듯한 성공으로 착각할 수 있다. 그러나 데이터 파이프라인 관점에서는 이것이 위험하다. 정제 결과가 결정적으로 재현되지 않고, 개인정보가 남거나, 검색 청크 품질이 흔들리며, 평가 시점에는 어디서 오류가 났는지 추적하기 어렵다.

논문은 이 문제를 procedural faithfulness라는 축으로 묶는다. 여기서 faithfulness는 답변이 출처에 충실하다는 RAG식 의미가 아니다. 주어진 recipe의 연산 순서, 중간 상태, KEEP/DROP 판단, 출력 스키마를 실제로 따른다는 뜻이다. 이 능력은 single editing accuracy와 다르다. 한 operator를 잘 수행하는 모델도 여러 operator를 연결하면 오류가 누적될 수 있고, 특히 필터가 포함되면 “그럴듯한 clean text를 계속 만든다”는 습관이 오히려 실패가 된다.

1.2 CDR-Bench가 던지는 핵심 질문

이 질문은 최근 LLM 평가에서 흔히 쓰는 “모델이 정답을 말했는가”보다 더 좁고 더 엄격하다. CDR-Bench의 recipe는 사람이 읽을 수 있는 지시문으로 verbalize되지만, 내부적으로는 실행 가능한 operator sequence다. 따라서 모델이 “의도를 이해했다”고 주장하려면, 최종 결과가 자연스러운 수준을 넘어 각 operator가 요구한 표면 변화와 판단을 모두 만족해야 한다. 특히 filter가 들어가는 순간에는 텍스트 생성 능력보다 상태 전이와 중단 판단이 핵심이 된다. 이 관점은 데이터 정제 업무를 LLM generation task의 하위 문제가 아닌 작은 workflow execution task로 재분류한다.

CDR-Bench의 핵심 질문은 세 가지다. 첫째, 모델은 atomic mapper와 atomic filter를 얼마나 잘 수행하는가. 둘째, 순서가 결과에 크게 영향을 주지 않는 조합 recipe에서도 여러 연산을 빠짐없이 적용할 수 있는가. 셋째, 같은 operator 집합이라도 순서가 바뀌면 결과가 달라지는 상황에서, 모델은 instruction에 적힌 순서를 따라 서로 다른 reference를 만들어낼 수 있는가. 논문은 이 질문을 Atomic-M, Atomic-F, Agnostic-M, Order-M, Order-F라는 트랙으로 분리한다.

이 구분은 단순한 난이도 단계가 아니다. Atomic-M은 텍스트를 고치는 mapper 연산을 본다. Atomic-F는 KEEP/DROP을 결정하는 filter 연산을 본다. Agnostic-M은 mapper 여러 개를 조합하되 순서가 결과에 결정적이지 않은 경우를 본다. Order-M은 mapper 순서 자체가 output을 바꾸는 경우다. Order-F는 mapper 사이 어느 위치에 filter가 삽입되는지에 따라 DROP 시점과 최종 결과가 달라지는 경우다. 따라서 Order-F는 가장 데이터 파이프라인다운 실패를 드러낸다. 모델은 정제도 해야 하고, 필터 조건도 적용해야 하며, DROP이 나오면 그 자리에서 멈춰야 한다.

길이별 분석을 표로만 보면 평균값 하나에 묻히는 현상이 있다. CDR-Bench는 bucket distribution을 함께 제시해, 긴 recipe가 소수의 예외인지 실제 평가에서 의미 있는 비중을 갖는지 확인하게 한다. 이는 benchmark 설계상 중요하다. 너무 긴 recipe만 모아두면 실패가 과장되고, 너무 짧은 recipe만 쓰면 절차적 병목이 보이지 않는다. 논문은 두 위험을 피하기 위해 family anchor와 materialized variant를 나눠 구성하고, 길이별 분포를 별도로 보고한다.

2. 배경 및 관련 연구: 데이터 중심 에이전트 평가의 빈칸

2.1 데이터 정제 benchmark가 놓치기 쉬운 절차성

최근 데이터 중심 에이전트 benchmark는 SQL/Python 코드 생성, 데이터 분석 workflow, 다중 데이터 소스 통합, cleaning report 작성 등을 포함하는 방향으로 확장됐다. 이런 benchmark는 실제 업무에 가깝지만 실패 원인을 분리하기 어렵다. 모델이 틀렸을 때 코드 생성이 문제인지, tool invocation이 문제인지, schema grounding이 문제인지, 단순한 text refinement가 문제인지가 한꺼번에 섞인다. CDR-Bench는 이 복잡도를 일부러 줄인다. code와 tool을 평가 대상에서 빼고, 자연어 recipe를 받은 LLM이 text state를 직접 갱신하는 능력만 본다.

반대로 instruction-driven text editing 연구는 correction, simplification, polishing, localized edit처럼 모델의 편집 능력을 세밀하게 다룬다. 하지만 대부분은 입력과 instruction을 주면 하나의 output을 내는 static mapping이다. 실제 데이터 정제 레시피처럼 “이 연산 뒤에 저 연산을 적용하고, 중간 상태에서 조건을 다시 평가한다”는 시간적 의존성은 약하다. CDR-Bench는 두 흐름 사이에서 text editing을 pipeline execution으로 다시 정의한다. 모델이 마지막 목표 상태를 대충 떠올리는지, 실제 operator 경로를 따라가는지를 분리하려는 시도다.

이 배경 때문에 논문은 “데이터 정제”를 단순한 문체 개선 과제로 보지 않는다. 크롤링 텍스트의 boilerplate 제거, LaTeX artifact cleanup, 개인정보 마스킹, RAG chunk preparation은 모두 표면 문자열이 downstream 시스템과 직접 연결되는 작업이다. 사람이 읽기에 자연스러운 paraphrase가 검색 인덱스에는 불리할 수 있고, 의미가 비슷한 redaction도 privacy policy에는 실패일 수 있다. 따라서 CDR-Bench는 semantic preference보다 operator contract를 우선한다. 이 선택은 점수를 낮게 만들지만, 데이터 파이프라인의 실제 리스크와는 더 잘 맞는다.

2.2 이전 위키 맥락과의 연결

이전에 정리했던 [[concepts/long-horizon-agent-benchmarking]]이나 [[concepts/benchmark-integrity-auditing]] 맥락과 비교하면, CDR-Bench는 agent가 웹 환경을 돌아다니는 장기 행동을 직접 다루지는 않는다. 대신 장기 행동 평가에서 반복해서 나타나는 “최종 성공처럼 보이지만 실제 절차가 어긋난다”는 문제를 텍스트 정제 레벨로 끌어내린다. tool 사용과 환경 상호작용을 제거했기 때문에 현실성은 줄어들지만, 순서 민감성이라는 한 변수를 더 깨끗하게 관찰할 수 있다.

또 하나의 연결점은 benchmark exploitability다. 많은 benchmark는 최종 답이 맞으면 중간 경로를 묻지 않는다. 모델은 shortcut을 찾거나, 표면 패턴을 맞추거나, 평가자가 관대하게 보는 출력을 만들어 점수를 얻을 수 있다. CDR-Bench는 결정적 gold와 exact matching을 사용해 이런 여지를 줄인다. 물론 exact matching은 지나치게 엄격할 수 있지만, 개인정보 마스킹, RAG chunk cleanup, benchmark preprocessing처럼 감사 가능한 문자열 변환이 필요한 곳에서는 그 엄격함 자체가 목적이다.

관련 평가 흐름	주요 초점	CDR-Bench와의 차이
데이터 중심 에이전트 benchmark	코드 생성, 도구 호출, 다중 데이터 소스 통합, 보고서 작성	실제성은 높지만 실패 원인이 여러 능력에 섞인다.
Instruction-driven text editing	단일 지시 기반 수정, 교정, 단순화, polishing	절차적 중간 상태와 operator 순서 의존성이 약하다.
콘텐츠 curation task	PII 탐지, hallucination correction, semantic tagging	개별 detection/correction에 집중하며 compositional recipe 실행은 제한적이다.
CDR-Bench	자연어로 verbalize된 데이터 정제 recipe의 결정적 실행	code/tool을 제거하고 composition, order, KEEP/DROP 판단을 직접 평가한다.

3. 방법론: CDR-Bench가 레시피 충실성을 측정하는 방식

3.1 문제 정식화와 출력 스키마

논문은 recipe를 순서가 있는 operator 열로 둔다. 간단히 쓰면 $r=(o_1,\ldots,o_T)$이고, 입력 텍스트 $x$에 대해 결정적 실행기는 $G(x,r)=(s^\star,x^\star)$를 만든다. 여기서 $s^\star$는 KEEP 또는 DROP 상태이고, $x^\star$는 정제된 텍스트다. 모델은 자연어 request $q$와 원문 $x$를 받고 $M(x,q)=(\hat{s},\hat{x})$를 출력한다. 평가는 status와 clean_text를 각각 gold와 비교한다. status가 틀리면 필터 판단 실패이고, clean_text가 다르면 mapper 실행, 순서 추적, formatting 중 하나가 어긋난 것이다.

중요한 설계는 request가 operator 이름 그대로 주어지는 내부 DSL 형식보다 사용자 친화적 자연어로 verbalize된다는 점이다. 같은 recipe도 direct command, imperative checklist, application context 같은 여러 style로 표현된다. 모델이 특정 문장 템플릿에만 적응하지 못하도록 하기 위해서다. 다만 gold는 자연어 판단이 아닌 Data-Juicer operator replay에서 나온다. 즉 benchmark는 “지시문을 얼마나 잘 이해했는가”와 “그 지시문이 가리키는 deterministic program을 얼마나 정확히 실행했는가”를 함께 본다.

출력 스키마가 status와 clean_text로 고정되어 있다는 점도 실무적으로 중요하다. 실제 데이터 pipeline에 모델을 붙이려면 자유로운 설명문보다 machine-readable contract가 필요하다. CDR-Bench는 모델이 정제된 텍스트만 잘 쓰는지 보지 않고, 그 결과가 KEEP인지 DROP인지도 동시에 요구한다. 특히 filter가 들어간 레시피에서는 status decision이 pipeline control flow가 된다. 모델이 clean_text를 그럴듯하게 만들었더라도 status가 틀리면 실행 흐름 전체가 잘못된 것이다.

Figure 1: 원문 문서를 여러 연산으로 정제하고 최종 KEEP/DROP 판단과 정제 텍스트를 함께 내는 CDR-Bench의 기본 문제 설정

Figure 1은 CDR-Bench가 일반적인 instruction editing과 어떻게 다른지 압축해서 보여 준다. 입력은 원문 하나와 자연어 요청 하나처럼 보이지만, 내부 reference는 여러 operator를 순서대로 실행해 만들어진다. 모델은 최종 status와 clean_text를 함께 내야 하므로, 텍스트를 예쁘게 고치는 능력과 중간 판단을 정확히 반영하는 능력이 동시에 요구된다. 이 그림이 중요한 이유는 benchmark가 좋은 문장 생성보다 절차 실행의 재현성을 평가한다는 점을 초반부터 분명히 하기 때문이다.

3.2 세 가지 조합 난이도: Atomic, Agnostic, Order-Sensitive

Atomic 단계는 단일 operator를 본다. mapper는 텍스트 변환이고, filter는 status 판단이다. Agnostic-M은 여러 mapper를 연결하지만 순서를 바꿔도 결과가 크게 달라지지 않는 집합을 사용한다. 이 경우 모델은 여러 연산을 빠뜨리지 않고 모두 적용하는지가 핵심이다. Order-M은 같은 mapper 집합의 순열이 서로 다른 결과를 낳는 경우를 유지한다. 여기서는 모델이 결과 목표만 떠올리면 실패한다. 지시문에 적힌 순서를 따라 관계나 formatting을 바꿔야 한다.

Order-F는 filter의 위치를 front, mid, end로 삽입해 만든다. filter가 앞에 있으면 원문 상태에서 DROP이 결정될 수 있고, 중간에 있으면 일부 mapper 실행 뒤 상태에서 조건을 다시 봐야 하며, 끝에 있으면 모든 변환 뒤 상태를 평가해야 한다. 논문은 각 family에서 적어도 두 variant가 서로 다른 output을 만들 때만 order-sensitive group으로 유지한다. 이 설계 덕분에 order가 평가 점수에 실제로 영향을 준다. 단순히 instruction에 순서 단어가 있다는 이유로 어려운 척하지 않고, 실행 순서가 gold 자체를 바꾸는 경우만 남긴다.

recipe mining 단계에서 논문이 신경 쓰는 것은 빈도와 다양성의 균형이다. 실제로 자주 등장하는 operator 조합만 쓰면 benchmark는 현실적인 분포를 얻지만, 특정 도메인이나 특정 cleanup 패턴에 치우칠 수 있다. 반대로 사람이 흥미로운 조합만 임의로 고르면 coverage가 떨어진다. 그래서 논문은 support threshold, anchor selection, exact signature assignment를 거쳐 family를 만든다. 이 절차는 데이터 정제 workflow에서 흔한 조합을 유지하면서도, order-sensitive variant를 만들 수 있는 충분한 구조적 다양성을 확보하려는 장치다.

Figure 2: 네 개 데이터 정제 도메인, 원자 연산, order-agnostic 조합, order-sensitive 조합을 한 벤치마크로 묶는 전체 설계

Figure 2는 benchmark가 어떤 축으로 구성되는지 보여 준다. 왼쪽에는 Privacy Redaction, Web Refinement, LaTeX Refinement, RAG Preparation 네 도메인이 있고, 가운데에는 Data-Juicer 기반 operator와 recipe mining 절차가 있으며, 오른쪽에는 Atomic, Agnostic-M, Order-M, Order-F 평가 트랙이 배치된다. 이 구조 덕분에 논문은 모델 A가 전체적으로 낮다는 평면적 결론을 넘어, 어떤 종류의 조합성과 순서성이 병목인지 분해해서 보고할 수 있다.

3.3 평가 지표: RS, RG, OCS

논문은 세 가지 지표를 쓴다. Recipe Success는 모델 output이 gold와 정확히 맞는지를 본다. RS@3은 세 가지 prompt style 중 하나라도 맞으면 성공으로 친다. Refinement Gain은 완전 성공은 아니어도 모델 출력이 원문보다 reference에 얼마나 가까워졌는지 보는 보조 지표다. 이 지표는 모델이 절차를 완전히 지키지 못하더라도 부분적으로 정제 방향을 따라갔는지를 보여 준다. Order-Consistent Success는 order-sensitive group의 모든 ordering variant를 함께 맞춰야 성공이다. 그래서 OCS는 단일 instance RS보다 훨씬 엄격하다.

이 세 지표의 조합이 논문의 해석을 강하게 만든다. 모델의 RS가 낮고 RG가 비교적 유지된다면, 모델이 완전히 엉뚱한 답을 내기보다 그럴듯하게 정제하면서 레시피 충실성에서 벗어난다는 뜻이다. OCS가 낮으면 같은 operator 집합의 서로 다른 순서를 분리하지 못한다는 뜻이다. 실제 데이터 파이프라인에서는 이 차이가 치명적이다. 잘 정돈된 것처럼 보이는 데이터셋이 내부 규칙을 위반하면 downstream training이나 retrieval 품질 문제가 나중에 나타나기 때문이다.

지표	계산 관점	무엇을 말해 주는가
RS@3	세 verbalization style 중 하나라도 deterministic gold와 일치하면 성공	recipe 단위의 완전 실행 성공률
RG	원문 대비 reference에 얼마나 가까워졌는지 보는 refinement gain	부분 정제가 있었는지, plausible output인지 해석
OCS@3	order-sensitive group의 모든 variant를 함께 맞출 때 성공	operator 순서 자체를 구분하는 능력
Atomic vs Compositional gap	단일 operator 점수와 recipe 점수의 차이	연산 조합에서 생기는 추가 실패 비용
Pre/Mid/Post DROP 분석	filter 위치별 Order-F 성능 비교	모델이 DROP 이후 실행을 멈추는지 진단

4. 실험 설정: 모델, 도메인, 프롬프트 전략

4.1 평가 모델과 추론 조건

실험은 폐쇄형 모델과 오픈소스 모델을 함께 본다. 표에는 Claude Opus 4.5/4.6, Qwen3.6-Max, GPT-5.4 같은 폐쇄형 모델과 DeepSeek-V4-Flash, Kimi-K2.6, Llama-4-Scout-17B, GLM-5, Gemma-4-31B-IT, Qwen3.6-27B, Qwen3.6-35B-A3B 같은 오픈소스 모델이 들어간다. 모든 모델은 기본적으로 temperature 0에서 평가되며, non-thinking mode에서는 최대 출력 길이 32,768 token을 사용한다. 오픈소스 모델은 8개 NVIDIA A100 GPU에서 배포하고, 폐쇄형 모델은 API를 통해 호출한다.

출력은 XML-like field 또는 JSON-like field로 고정되어 있으며, parsing 가능한 형식을 지켜야 한다. 이 조건은 실제 운영에 가까운 제약이다. 데이터 정제 시스템은 모델이 설명을 얼마나 잘했는지보다, 후속 step이 읽을 수 있는 status와 text를 안정적으로 받는지가 중요하다. formatting drift나 parse error가 failure taxonomy에 포함되는 이유도 여기에 있다. 모델이 의미상 비슷한 답을 했더라도, pipeline contract를 깨뜨리면 자동 처리에서는 실패다.

4.2 네 도메인과 operator inventory

도메인은 Web Refinement, LaTeX Refinement, RAG Preparation, Privacy Redaction으로 나뉜다. Web Refinement는 크롤링된 웹 문서에서 반복 줄, 과도한 특수문자, 품질 낮은 segment를 정리하는 상황에 가깝다. LaTeX Refinement는 arXiv 또는 논문 원문에서 수식/태그/환경 잔여물을 처리하는 맥락이다. RAG Preparation은 검색 인덱싱용 문서 chunk를 만들기 전에 불필요한 문구를 줄이고 검색 친화적 형식을 맞추는 목적을 가진다. Privacy Redaction은 PII나 민감한 식별자를 마스킹하고, 조건에 따라 샘플을 버리는 문제를 포함한다.

operator inventory는 shared filters와 domain-specific mappers로 구성된다. shared filter는 길이, line length, repetition ratio 같은 통계적 신호를 쓰며, domain mapper는 URL/HTML cleanup, LaTeX artifact 제거, RAG chunk cleanup, privacy redaction 같은 작업을 맡는다. 이 operator들은 사람이 결과를 주관적으로 평가하지 않아도 되는 범위로 제한된다. 그래서 benchmark는 모델이 이 출력을 더 자연스럽게 만들었는가보다 정해진 operator 의미를 재현했는가에 집중한다.

네 도메인은 단순히 이름만 다른 텍스트 집합이 아니다. Web Refinement는 noisy crawling artifact처럼 반복과 formatting 문제가 강하고, LaTeX Refinement는 command, environment, 수식 주변 잔여물처럼 표면 문법이 중요한 문제를 포함한다. RAG Preparation은 retrieval chunk로 들어갈 때 검색 품질을 망치는 boilerplate와 불필요한 구조를 줄이는 방향이고, Privacy Redaction은 status decision과 masking이 함께 중요하다. 이처럼 도메인마다 operator가 요구하는 신호가 달라, 같은 모델도 어느 도메인에서 어떤 오류를 내는지 비교할 수 있다.

도메인	Task 수	Family anchors	Recipes	대표적 정제 의미
LaTeX Refinement (LR)	500	2	9	논문 원문, LaTeX 환경, 수식 주변 artifact 정리
RAG Preparation (RP)	521	3	10	검색 인덱싱 전 문서 segment와 chunk 품질 정리
Privacy Redaction (PR)	1,304	5	23	개인정보/민감정보 마스킹과 조건부 DROP 판단
Web Refinement (WR)	1,137	6	21	크롤링 웹 텍스트의 반복, 잡음, format 불량 제거
Total	3,462	16	63	네 도메인에서 616개 executable variant로 materialize

4.3 프롬프트 전략과 thinking mode

기본 평가는 Direct Mode를 중심으로 하되, 논문은 Few-Shot, Plan-First, State-Aware 전략도 비교한다. Few-Shot은 예시를 보여 주는 방식이고, Plan-First는 모델에게 먼저 실행 계획을 세우게 한다. State-Aware는 중간 text state를 명시적으로 식별하고 각 operation/filter가 어느 상태에 적용되는지 쓰게 하는 방식이다. 이 전략들은 단순 prompt engineering으로 order-sensitive failure를 얼마나 줄일 수 있는지 보는 장치다.

또한 일부 모델에서는 thinking mode를 켰을 때의 변화를 본다. thinking mode는 모델이 더 긴 내부 추론을 하도록 하므로, 특히 Order-F처럼 중간 상태와 filter 위치를 추적해야 하는 경우에 도움이 될 수 있다. 그러나 논문의 핵심은 성능 향상 폭보다 잔여 gap이다. thinking이 들어가도 OCS가 충분히 높아지지 않는다면, 현재 모델의 문제는 생각할 시간 부족만으로 설명되지 않고, recipe state tracking과 deterministic execution을 안정적으로 유지하는 구조적 능력 부족이라는 해석이 가능하다.

5. 주요 실험 결과: 원자 연산은 되지만 조합 레시피가 무너진다

5.1 Atomic 성능과 compositional collapse

가장 눈에 띄는 결과는 atomic track과 compositional track의 차이다. Atomic-F에서는 GPT-5.4가 88.10, Gemma-4-31B-IT와 Qwen3.6-27B가 80.95를 기록한다. 이 수치만 보면 최신 모델은 filter 판단도 상당히 하는 것처럼 보인다. 하지만 Agnostic-M, Order-M, Order-F로 넘어가면 상황이 급격히 바뀐다. GPT-5.4의 Atomic-M은 30.30이고 Atomic-F는 88.10이지만, Order-M RS@3는 13.99, Order-M OCS@3는 4.90에 머문다. Order-F에서도 pre-drop 62.04와 달리 mid-drop 25.03, post-drop 14.97로 내려가며 OCS@3는 9.46이다.

이 결과는 두 가지를 말한다. 첫째, filter 하나를 판단하는 것과, mapper sequence 사이에서 filter를 적용할 정확한 시점을 추적하는 것은 다른 능력이다. 둘째, 일부 모델은 reference와 완전히 일치하지 않아도 RG를 어느 정도 유지한다. 즉 모델은 대략적인 정제 방향을 따라가며 자연스러운 텍스트를 만들 수 있다. 그러나 deterministic pipeline에서는 대략 맞음이 성공으로 이어지지 않는다. 개인정보 redaction에서 한 개 항목만 남아도 실패이고, RAG chunk cleanup에서 불필요한 boilerplate가 하나 남아도 검색 품질이 흔들릴 수 있다.

논문을 읽을 때 숫자를 해석하는 요령은 absolute score보다 score 간 관계를 보는 것이다. Atomic-F가 높다는 사실은 모델이 이 문서는 조건을 만족하는가 같은 단일 판단을 어느 정도 수행한다는 뜻이다. 그러나 Order-F에서 pre, mid, post score가 갈라지는 순간, 모델은 같은 filter 의미를 서로 다른 text state에 적용해야 한다. 여기서 낮은 OCS는 모델이 filter 개념 자체를 모른다기보다, 어떤 상태에 그 filter를 적용해야 하는지 안정적으로 추적하지 못한다는 쪽에 가깝다.

모델	Atomic-M RS@3	Atomic-F RS@3	Agnostic-M RS@3	Order-M RS@3 / OCS@3	Order-F RG / OCS@3
GPT-5.4	30.30	88.10	22.74	13.99 / 4.90	48.47 / 9.46
Claude Opus 4.6	29.55	73.81	22.33	12.24 / 2.80	47.03 / 18.68
Qwen3.6-Max	26.15	76.19	23.94	7.34 / 0.70	39.44 / 8.27
Gemma-4-31B-IT	29.55	80.95	25.55	8.04 / 0.70	43.19 / 6.11
Qwen3.6-35B-A3B	25.76	80.95	23.74	8.04 / 0.70	34.80 / 4.55
Llama-4-Scout-17B	16.92	62.50	13.59	3.87 / 0.00	26.98 / 0.86

5.2 도메인별 차이: 어디서 더 크게 무너지는가

도메인별 분석은 composition gap이 균일하지 않다는 점을 보여 준다. Web Refinement와 Privacy Redaction은 여러 local constraint를 동시에 만족해야 하므로 atomic-to-compositional 하락이 크게 나타난다. LaTeX Refinement는 formatting과 구조 변환이 얽혀 있어 deterministic surface match가 어렵다. RAG Preparation은 downstream retrieval 품질과 연결되는 불필요한 문구 제거, chunk-friendly formatting, boilerplate 제거가 섞이기 때문에 모델이 문서 의미를 유지하면서도 operator별 표면 규칙을 지키는 능력을 요구한다.

도메인별 score를 보면 CDR-Bench가 단순한 문장 편집 benchmark를 넘어 데이터 파이프라인의 작은 축소판이라는 점이 더 분명해진다. 같은 모델도 Privacy Redaction에서는 특정 PII group을 잘 지우지만, 여러 group을 한 번에 지워야 하면 exact output 성공률이 떨어진다. Web Refinement에서는 반복이나 길이 기반 필터처럼 수치적 기준이 들어가면 모델의 language intuition만으로는 충분하지 않다. LaTeX와 RAG Preparation에서는 표면 artifact 하나가 남는 것이 failure로 이어진다.

Figure 3: Web, LaTeX, RAG, Privacy 도메인별 atomic-to-compositional 성능 저하와 모델별 격차

Figure 3은 네 도메인에서 atomic 성능과 compositional 성능 사이의 하락 폭을 비교한다. 도메인마다 operator 성격이 다르지만, 공통 패턴은 단일 연산보다 조합 레시피가 훨씬 어렵다는 것이다. 특히 개인정보와 웹 정제처럼 여러 independent constraint가 한 출력에 동시에 반영되어야 하는 영역에서는 failure probability가 곱해지는 효과가 난다. 따라서 이 그림은 CDR-Bench의 메시지가 특정 operator set의 우연한 결과를 넘어 여러 데이터 정제 상황에 걸친 반복 패턴임을 뒷받침한다.

5.3 레시피 길이와 성공률

recipe length 분석은 직관적이지만 운영적으로 중요하다. 레시피가 길어질수록 모델은 더 많은 중간 상태를 기억해야 하고, 각 operator가 적용된 후 텍스트가 어떻게 변했는지 추적해야 한다. 짧은 recipe에서는 모델이 표면 패턴을 보고도 맞출 가능성이 있다. 그러나 길이가 늘면 skipped operator, under-application, wrong order, formatting drift가 누적된다. 논문은 representative LLM의 RS@3 line과 recipe-length bucket의 instance 수를 함께 보여 주어, 길이가 길어질수록 성공률이 낮아지는 경향을 시각화한다.

여기서 중요한 점은 긴 instruction을 읽기 어렵다는 단순 문제가 아니다. 데이터 정제에서 operator는 교환 가능하지 않다. 앞 단계에서 삭제한 문장은 뒤 단계에서 다시 등장하지 않아야 하고, 앞 단계에서 normalize한 token은 뒤 단계 filter의 통계값을 바꾼다. 모델이 instruction 전체를 기억하더라도 중간 상태를 명시적으로 갱신하지 않으면 길이가 늘수록 reference와 멀어진다. 이 때문에 state-aware prompting이 어느 정도 도움이 되지만, 그것만으로는 충분하지 않다.

Figure 4: 레시피 길이가 늘어날수록 compositional recipe track의 RS@3가 어떻게 낮아지는지 보여 주는 길이별 성능 분석

Figure 4는 레시피 길이가 성능에 주는 영향을 보여 준다. 막대는 각 length bucket에 실제 instance가 얼마나 있는지, 선은 representative model의 RS@3가 어떻게 변하는지를 나타낸다. 이 그림에서 볼 점은 긴 지시문 자체보다 중간 상태 갱신 부담이다. operator가 하나 늘어날 때마다 skipped step, wrong order, formatting drift가 들어갈 기회도 늘어나며, 모델의 언어적 자연스러움은 이런 누적 오류를 자동으로 보정하지 못한다.

길이별 분석을 표로만 보면 평균값 하나에 묻히는 현상이 있다. CDR-Bench는 bucket distribution을 함께 제시해, 긴 recipe가 소수의 예외인지 실제 평가에서 의미 있는 비중을 갖는지 확인하게 한다. 이는 benchmark 설계상 중요하다. 너무 긴 recipe만 모아두면 실패가 과장되고, 너무 짧은 recipe만 쓰면 절차적 병목이 보이지 않는다. 논문은 두 위험을 피하기 위해 family anchor와 materialized variant를 나눠 구성하고, 길이별 분포를 별도로 보고한다.

6. 추가 분석 및 Ablation Study: prompt와 thinking은 도움이 되지만 충분하지 않다

6.1 Few-shot, Plan-first, State-aware의 차이

Prompt 전략 비교에서 가장 실용적인 신호는 State-Aware가 비교적 일관되게 도움이 된다는 점이다. GPT-5.4의 경우 Plan-First는 Order-M RS@3를 13.99에서 18.18로 올리고, State-Aware는 Order-F pre-drop 성공률을 62.04에서 75.15로 끌어올린다. Qwen3.6-35B-A3B에서도 Few-Shot은 atomic mapper에는 조금 도움이 되지만 recipe-level 개선은 제한적이고, State-Aware가 Agnostic-M과 Order-F에서 더 분명한 이득을 준다. 이는 모델에게 중간 상태를 쓰게 하는 것이 단순 예시 제공보다 절차 추적에 더 직접적이라는 해석을 가능하게 한다.

하지만 개선 폭을 보면 한계도 뚜렷하다. GPT-5.4 + State-Aware에서도 Order-F OCS@3는 13.45에 그친다. Plan-First와 State-Aware가 RG를 높이는 경우도 있지만, group-level 순서 일관성까지 안정적으로 해결하지는 못한다. 즉 prompt는 모델이 몇몇 중간 상태를 더 의식하게 만들지만, deterministic executor처럼 state transition을 보장하지 않는다. 운영 환경에서는 이런 결과가 중요하다. prompt template만 잘 쓰면 자동 데이터 정제 agent가 신뢰 가능하다는 결론을 내리기 어렵기 때문이다.

전략	대표 변화	해석
Few-Shot	GPT-5.4에서 Agnostic-M RS@3 22.74 → 23.38, Order-F OCS@3 9.46 → 9.99	예시 제공은 일부 안정성을 주지만 order-sensitive 병목은 크게 남는다.
Plan-First	GPT-5.4 Order-M RS@3 13.99 → 18.18, Order-F OCS@3 9.46 → 13.06	실행 계획을 먼저 쓰게 하면 순서 추적이 조금 개선된다.
State-Aware	GPT-5.4 Order-F pre-drop 62.04 → 75.15, OCS@3 9.46 → 13.45	중간 상태 명시가 가장 직접적인 개선을 주지만 완전 해결은 아니다.
Thinking mode	Qwen 계열 Order-F에서 큰 폭의 RS 개선 보고	긴 reasoning은 도움을 주지만 절차 충실성의 구조적 결함을 닫지는 못한다.

6.2 Thinking mode의 효과와 잔여 실패

Thinking mode 분석은 현재 reasoning model을 데이터 정제 executor로 쓸 때의 장단점을 잘 보여 준다. 논문은 Qwen3.6-35B-A3B와 Qwen3.6-27B에서 thinking mode가 Order-F RS@3를 각각 약 19.6pp, 17.9pp 개선한다고 보고한다. Order-F는 filter 위치와 중간 상태가 중요하므로, 모델이 더 길게 생각하며 “현재 어떤 state에 어떤 filter를 적용해야 하는지”를 명시적으로 추적하면 이득을 본다. 이는 reasoning budget이 절차적 task에 실제 영향을 준다는 긍정적 신호다.

다만 thinking mode의 개선이 가장 큰 곳이 Order-F라는 점은 동시에 문제의 위치를 말해 준다. 모델은 자연어 이해 부족만으로 실패하는 것이 아니며, state transition을 안정적으로 bookkeeping하지 못한다. reasoning trace가 길어지면 어느 정도 보완되지만, trace 자체가 deterministic execution log는 아니다. 특히 output이 reference와 exact match되어야 하는 상황에서는 작은 formatting drift나 skipped operator도 실패다. 따라서 thinking mode는 production pipeline에서 보조 장치가 될 수는 있어도, 검증기와 provenance log 없이 단독으로 신뢰하기 어렵다.

Figure 5: thinking mode가 Order-F와 일부 조합 트랙에서 Recipe Success를 끌어올리지만 완전한 절차 충실성에는 도달하지 못하는 양상

Figure 5는 thinking mode가 track별로 어느 정도 개선을 주는지 보여 준다. 특히 Order-F에서 상승 폭이 크다는 점은 필터 위치, 중간 상태, DROP 이후 정지 판단이 extended reasoning의 수혜를 받는다는 뜻이다. 그러나 그래프가 말하는 핵심은 “thinking을 켜면 해결된다”가 아니다. 개선 뒤에도 절대 성공률은 낮고, order-sensitive group을 일관되게 모두 맞추는 능력은 여전히 부족하다. 운영 관점에서는 reasoning token을 늘리는 것과 별도로, 실행 trace 검증과 deterministic replay를 붙여야 한다.

6.3 DROP case와 stopping behavior

Order-F에서 특히 흥미로운 실패는 DROP 이후에도 모델이 계속 실행하는 경우다. 실제 pipeline에서는 filter가 rejecting decision을 내리면 해당 sample은 더 이상 정제할 필요가 없다. 하지만 LLM은 “요청받은 정제 작업을 끝까지 수행해야 한다”는 언어적 습관 때문에, DROP이어야 할 샘플에도 뒤 단계 mapper를 적용해 clean_text를 만들 수 있다. 논문은 Pre-DROP과 Mid-DROP 상황을 나누고, 모델 출력이 올바른 stopping state $t_{\mathrm{stop}}$에 가까운지, 아니면 filter를 무시하고 끝까지 실행한 full-execution state $t_{\mathrm{full}}$에 가까운지 비교한다.

Pre-DROP에서는 filter가 시작 지점에서 적용되므로 핵심은 즉시 멈추는 것이다. Mid-DROP에서는 그 전에 일부 mapper가 이미 실행되었기 때문에, 모델은 중간 정제도 맞춰야 하고 그 뒤 filter에서 멈춰야 한다. 당연히 Mid-DROP이 더 어렵다. 이 분석은 CDR-Bench의 장점을 잘 보여 준다. 단순 성공률만 보면 모델이 “나쁘다”는 결론에 그치지만, stopping state와 continued state의 거리를 비교하면 실패 원인이 계속 실행 습관인지, 중간 rewrite 품질인지, 필터 임계값 판단인지 더 구체적으로 드러난다.

Figure 6: 거부 필터가 등장한 뒤 올바르게 멈춘 상태와 계속 실행한 상태 중 모델 출력이 어느 쪽에 가까운지 비교한 분석

Figure 6은 DROP case에서 모델 출력이 올바른 정지 상태와 계속 실행 상태 중 어디에 더 가까운지 비교한다. Pre-DROP에서는 정지 여부가 거의 핵심 병목이고, Mid-DROP에서는 중간 rewrite 품질까지 함께 필요해진다. GPT-5.4는 상대적으로 stopping behavior가 좋지만 여전히 완전하지 않다. 이 분석은 데이터 정제 agent가 단지 “무언가를 계속 처리하는 모델”을 넘어, 필요할 때 작업을 중단하는 executor가 되어야 한다는 점을 강조한다.

6.4 실패 모드 taxonomy

실패 taxonomy가 특히 유용한 이유는 각 오류가 서로 다른 guardrail 설계로 이어지기 때문이다. filter threshold error가 많다면 모델에게 설명을 더 길게 쓰게 하기보다 threshold 계산을 deterministic function으로 빼는 편이 낫다. formatting drift가 많다면 canonicalizer나 post-formatter를 붙이는 것이 직접적이다. wrong order가 많다면 recipe compiler와 state machine 검증이 필요하다. 이런 식으로 CDR-Bench는 모델 순위를 매기는 데 그치지 않고, 데이터 정제 agent를 설계할 때 어떤 부분을 모델에게 맡기고 어떤 부분을 도구로 고정할지 판단하게 해 준다.

논문은 실패를 status-level과 text-level로 나눠 taxonomy를 만든다. 전체적으로 filter threshold error가 39.3%로 가장 크고, transformation-heavy track에서는 formatting drift가 28.4%로 두드러진다. missed operator, under-application, over-application, wrong order, semantic rewrite, instruction misread, format/parse error도 별도로 분류된다. 이 taxonomy는 benchmark의 해석 가능성을 높인다. 모델이 틀렸다는 사실보다, 어떤 오류 유형이 파이프라인 위험으로 이어지는지를 구분할 수 있기 때문이다.

예를 들어 filter threshold error는 privacy redaction이나 quality filtering에서 샘플을 남길지 버릴지 잘못 판단하는 문제로 이어진다. Formatting drift는 reference와 의미는 비슷하지만 downstream parser나 exact deduplication에는 실패하는 표면 불일치다. Semantic rewrite는 모델이 operator를 실행하는 대신 원문을 자기 식으로 paraphrase하는 현상이다. LLM은 이런 rewrite를 자연스러운 개선으로 여길 수 있지만, 데이터 정제 pipeline에서는 원문 보존과 최소 수정이 요구되는 경우가 많다.

Figure 7: 대표 모델들의 실패 유형 분포. 필터 임계값 오류, formatting drift, missed operator 등이 어떤 트랙에서 두드러지는지 보여 준다

Figure 7은 대표 모델별 실패 유형 분포를 보여 준다. 왼쪽 panel은 track-level failure rate를, 오른쪽 panel들은 failed prediction 안에서 어떤 오류가 주로 나타나는지 분해한다. 여기서 중요한 점은 실패가 무작위 generation noise로 흩어져 있지 않다는 것이다. 필터 임계값 오류와 formatting drift가 반복적으로 나타나며, 이는 현재 LLM이 데이터 정제 operator를 “정확한 실행 규칙”보다 “대략적인 언어 편집 의도”로 처리하는 경향을 가진다는 해석을 뒷받침한다.

Failure mode	논문 정의에 가까운 의미	운영 리스크
Filter Threshold Error	filter criterion 아래 KEEP/DROP 판단을 틀림	부적절한 샘플이 남거나 유용한 샘플이 삭제됨
Missed Operator	필수 operator 하나 이상을 건너뜀	정제 pipeline 일부가 조용히 누락됨
Under-application	cleanup이 부분적으로만 적용됨	artifact가 남아 downstream parser나 retriever를 오염시킴
Over-application	유효한 content까지 과도하게 삭제 또는 수정	데이터 손실과 의미 훼손 발생
Wrong Order	recipe에 지정된 순서와 다르게 실행	순서 민감 operator에서 gold와 다른 text state 생성
Formatting Drift	의미는 비슷하나 deterministic surface form이 다름	exact matching, deduplication, schema parsing에서 실패
Semantic Rewrite	operator 실행 대신 paraphrase 수행	원문 보존이 필요한 정제 작업에서 provenance가 흐려짐

6.5 의미론적 확장: rule-based operator 밖에서도 gap이 남는가

논문은 rule-based Data-Juicer operator만으로 끝내지 않고, 네 가지 semantic extension도 확인한다. PII redaction은 AI4Privacy 계열 데이터, hallucination processing은 FAVA 기반 subset, safety tagging은 Aegis-AI-Content-Safety-Dataset-2.0, rubric scoring은 HelpSteer2를 사용한다. 각 domain은 atomic subtask와 compositional task로 나뉜다. 평균적으로 Atomic Avg RS@3는 58.8%, Compositional RS@3는 30.8%로, 전체 gap은 28.0pp다. 이는 composition bottleneck이 rule-based operator 설계의 artifact에만 머물지 않는다는 근거가 된다.

다만 semantic domain 사이의 gap 양상은 다르다. PII redaction, safety tagging, rubric scoring처럼 여러 독립 판단을 하나의 output schema 안에 모두 맞춰야 하는 경우 gap이 크다. 특히 rubric scoring은 다섯 차원 점수를 모두 맞춰야 하므로 atomic 점수가 높아도 compositional exact success가 낮아진다. Hallucination processing은 gap이 상대적으로 작다. detection, span extraction, type classification, correction이 coarse-to-fine 계층을 이루고, fine-grained correction 자체가 이미 어렵기 때문이다. 즉 composition difficulty는 domain label보다 subtask 구조와 output schema에 의해 좌우된다.

Figure 8: semantic PII redaction에서 contact, person, location, identification, temporal group별 atomic RS@3가 어떻게 달라지는지 보여 주는 heatmap

Figure 8은 semantic extension 중 PII redaction의 atomic subtask 난이도를 더 세밀하게 보여 준다. contact information처럼 표면 패턴이 뚜렷한 group은 비교적 쉽지만, person, location, identification처럼 문맥 판단이 필요한 group은 더 낮다. 이 heatmap은 compositional collapse가 단지 여러 쉬운 작업을 합쳐서 생기는 것이 아님을 말해 준다. 이미 atomic subtask 안에서도 난이도 구조가 있고, compositional task는 그 구조 위에 모든 group을 동시에 맞춰야 하는 추가 조건을 얹는다.

Figure 9: PII, hallucination, safety, rubric scoring 의미론적 확장 과제에서 atomic 평균과 compositional 성능 사이의 하락 폭

Figure 8은 네 semantic domain에서 atomic 평균과 compositional 성능 사이의 하락 폭을 보여 준다. rubric scoring의 gap이 가장 크고, PII와 safety tagging도 큰 폭으로 떨어진다. hallucination processing은 추가 composition gap이 작지만, 이는 쉬워서라기보다 span, type, correction 같은 fine-grained subtask 자체가 이미 병목이기 때문이다. 이 그림은 CDR-Bench의 중심 메시지가 실제 annotation, moderation, scoring 같은 semantic data preparation에도 적용될 수 있음을 보여 준다.

Semantic domain	Atomic Avg RS@3	Compositional RS@3	Gap	해석
PII Redaction	모델 평균 기준 compositional보다 높음	atomic 대비 19.8~38.8pp 낮음	약 29.1pp	여러 PII group을 동시에 정확히 redaction해야 해 실패가 누적
Hallucination Processing	detection은 높고 span/type/correction은 낮음	atomic 대비 추가 gap이 작음	약 4.0pp	fine-grained correction 자체가 이미 병목이라 composition 추가 비용이 작음
Safety Tagging	binary label은 대체로 높고 category tagging은 어려움	세 field를 모두 맞추는 JSON에서 하락	약 27.6pp	prompt/response label과 violated category의 joint correctness가 어려움
Rubric Scoring	개별 차원 scoring은 상대적으로 가능	다섯 차원 동시 exact success가 매우 낮음	약 51.1pp	structured multi-field exact matching에서 composition collapse가 가장 큼
Overall	58.8%	30.8%	28.0pp	semantic task에서도 atomic 성능이 deployable compositional reliability를 보장하지 않음

6.6 실제 데이터 파이프라인 관점의 해석

이 결과를 운영 환경으로 옮기면, LLM-as-executor와 LLM-as-orchestrator를 구분해야 한다. LLM-as-executor는 모델이 원문을 직접 받아 모든 변환과 필터 판단을 수행하는 구조다. CDR-Bench는 이 구조가 현재로서는 취약하다는 근거를 제공한다. 반면 LLM-as-orchestrator는 모델이 자연어 요구를 해석해 operator graph를 만들고, 실제 변환은 deterministic operator나 코드가 수행하며, 모델은 예외 설명과 검증 요약을 맡는 구조다. 낮은 RS와 OCS는 후자의 구조가 더 안전하다는 쪽으로 읽을 수 있다.

특히 RAG corpus preparation에서는 작은 표면 오류가 downstream retrieval에 직접 반영된다. boilerplate 문장이 하나 남으면 검색 결과가 오염되고, chunk boundary가 흔들리면 답변 근거가 불안정해진다. Privacy Redaction에서는 실패 비용이 더 명확하다. entity 하나가 남거나, DROP해야 할 샘플을 KEEP하면 개인정보 보호 정책을 위반할 수 있다. CDR-Bench가 exact match를 쓰는 이유는 이런 use case에서 의미가 비슷한 출력이 충분하지 않기 때문이다. 이 benchmark는 모델의 언어 능력을 벌주려는 장치보다, 자동 데이터 파이프라인에서 허용 가능한 오차 범위를 매우 좁게 잡은 테스트에 가깝다.

또 하나의 실무적 시사점은 process reward 설계다. 모델을 데이터 정제에 맞게 fine-tuning하거나 reinforcement learning으로 개선하려면, 최종 clean_text 선호도만 보상해서는 부족하다. 각 step의 intermediate state, filter statistic, stop decision, schema validity를 함께 보상해야 한다. 예를 들어 Order-F에서 DROP 이후 계속 실행한 답변은 문장 품질이 좋아도 큰 penalty를 받아야 한다. 이런 보상이 있어야 모델은 “끝까지 예쁘게 고치기”보다 “정해진 지점에서 멈추기”를 배운다.

CDR-Bench의 failure taxonomy는 이런 reward를 만드는 출발점이 된다. filter threshold error, missed operator, wrong order, formatting drift, semantic rewrite는 서로 다른 gradient signal이나 rule-based penalty로 바꿀 수 있다. 단순 exact-match 실패를 하나의 0점으로 처리하면 모델은 어떤 부분을 고쳐야 하는지 배우기 어렵다. 반대로 failure mode를 분해하면, data refinement agent가 점차 deterministic executor에 가까운 행동을 하도록 훈련할 수 있다.

7. 한계점 및 향후 연구 방향: 결정적 평가의 장점과 빈칸

7.1 Data-Juicer operator 범위의 한계

결정적 operator 중심 benchmark는 평가를 투명하게 만들지만, 모델이 현실에서 수행하는 창의적 정제와는 일부 거리가 있다. 예컨대 domain-specific guideline을 따라 문장을 보존하면서 위험 표현만 완화하거나, 서로 충돌하는 품질 기준 사이에서 우선순위를 조정하는 작업은 deterministic gold 하나로 표현하기 어렵다. CDR-Bench는 이런 문제를 다루기보다, 데이터 정제 workflow에서 자동화하기 쉬운 core operator들을 먼저 시험한다. 따라서 이 논문은 데이터 정제의 전체 지도를 그렸다기보다, 그중 가장 재현 가능한 절차 실행 영역을 깊게 파고든 연구로 읽는 편이 맞다.

논문도 인정하듯 CDR-Bench는 Data-Juicer operator library의 semantics와 coverage에 묶여 있다. 결정적 reference를 만들기 위해 주관적 정제 recipe를 제외했고, LLM judge를 final evaluator로 쓰지 않았다. 이 선택은 평가를 깨끗하게 만들지만, 실제 데이터 정제에서 자주 등장하는 애매한 품질 판단, 문체 보존, 도메인별 content policy, task-specific utility 최적화는 충분히 담지 못한다. 따라서 CDR-Bench 점수가 높다고 해서 모든 데이터 정제 상황에서 모델이 신뢰 가능하다고 말할 수는 없다.

반대로 이 제한이 benchmark의 강점이기도 하다. 주관적 평가를 줄였기 때문에 모델의 plausible paraphrase를 성공으로 봐주는 위험을 낮춘다. 데이터 정제 pipeline에서는 “사람이 보기엔 괜찮음”보다 “정해진 규칙이 재현 가능하게 적용됨”이 중요한 순간이 많다. 예를 들어 개인정보 redaction, license-sensitive corpus cleaning, benchmark preprocessing에서는 작은 surface mismatch가 감사 추적 문제로 이어질 수 있다. CDR-Bench는 바로 그런 use case를 위해 보수적으로 설계된 benchmark다.

7.2 자연어 verbalization과 사용자 요청의 간극

두 번째 한계는 prompt verbalization이다. 논문은 여러 style을 사용하고 instruction validation을 하지만, 자연어 request 일부는 LLM-assisted generation을 거친다. 실제 사용자는 더 모호하게 말하거나, 도메인 jargon을 섞거나, 레시피 일부를 생략한 채 맥락에 기대기도 한다. CDR-Bench의 request는 operator semantics를 보존하도록 만들어졌기 때문에, production 환경의 messy instruction보다 정돈되어 있을 가능성이 있다. 따라서 실제 사용 시에는 CDR-Bench보다 instruction ambiguity 문제가 더 커질 수 있다.

향후 연구에서는 deterministic recipe와 real user request 사이를 연결하는 계층이 필요하다. 하나의 방향은 user request를 operator graph로 compile한 뒤, 그 graph를 다시 verifier가 확인하는 방식이다. 또 다른 방향은 모델 output과 함께 intermediate state log를 요구하고, 각 단계가 reference executor와 얼마나 일치하는지 단계별로 평가하는 것이다. 이렇게 하면 모델이 최종 clean_text를 우연히 맞추는 경우와, 실제로 recipe를 따라간 경우를 더 명확히 구분할 수 있다.

7.3 Tool use와 interactive refinement가 빠진 점

CDR-Bench는 직접 text-level execution에 집중하기 위해 tool use, code generation, interactive refinement를 제외한다. 하지만 실제 데이터 preparation agent는 보통 Python script를 실행하고, sample을 검사하고, 오류 로그를 보고, operator parameter를 조정한다. 이런 환경에서는 LLM이 직접 모든 변환을 문자열로 수행할 필요가 없을 수 있다. 오히려 적절한 deterministic tool을 호출하고, 결과를 검증하고, 실패 시 recipe를 수정하는 능력이 더 중요할 수 있다.

그렇다고 CDR-Bench가 agent 연구와 무관한 것은 아니다. tool-using agent도 자연어로 주어진 data cleaning intent를 operator sequence로 해석해야 하고, 중간 상태와 filter 시점을 추적해야 한다. CDR-Bench의 실패 유형은 tool agent에서도 그대로 나타날 수 있다. 차이는 실행 주체다. 현재 benchmark는 모델 자체가 executor 역할을 맡는다. 다음 단계 benchmark는 모델이 planner/verifier 역할을 맡고 deterministic tool이 executor가 되는 하이브리드 설정을 평가할 수 있다.

7.4 운영 적용 시 필요한 검증 계층

운영 적용을 생각하면 CDR-Bench의 결과는 모델을 쓰지 말라는 경고보다 검증 계층을 붙이라는 요구에 가깝다. 첫 단계는 자연어 요청을 operator graph로 변환하고, 각 operator의 parameter를 명시하는 것이다. 두 번째 단계는 실행 결과를 deterministic reference 또는 invariants로 검증하는 것이다. 세 번째 단계는 모델이 만든 clean_text가 reference와 다를 때, 차이를 단순 edit distance로만 보지 않고 어떤 operator contract가 깨졌는지 분류하는 것이다. 이 세 계층이 있으면 LLM은 전부를 직접 실행하는 black-box executor 역할에 갇히지 않고, recipe 해석과 예외 설명을 담당하는 component가 된다.

이 관점에서 CDR-Bench는 guardrail benchmark로도 쓸 수 있다. 모델 자체 점수만 비교할 때는 GPT-5.4, Claude Opus, Gemma, Qwen 계열의 상대 순위가 눈에 들어오지만, 시스템 설계 관점에서는 failure mode별 완화책이 더 중요하다. 예를 들어 Privacy Redaction에서 threshold error가 반복되면 filter는 코드로 고정하고, 모델은 애매한 entity group 설명만 맡기는 식이다. RAG Preparation에서 formatting drift가 많으면 최종 output을 canonical schema로 재직렬화한다. benchmark 결과가 이런 architecture 선택으로 연결될 때, 논문의 실무적 의미가 가장 커진다.

8. 내 해석: 약점 1 + 후속 제안 1

나는 CDR-Bench의 가장 설득력 있는 부분이 “LLM이 자연어로 그럴듯하게 정제한다”는 능력과 “데이터 파이프라인 operator를 충실히 실행한다”는 능력을 분리한 점이라고 본다. 이전에 봤던 장기 에이전트 benchmark들이 최종 성공률만으로는 trajectory 품질을 놓치기 쉽다고 지적했다면, 이 논문은 같은 문제를 훨씬 작은 텍스트 정제 단위로 가져온다. 특히 RG가 남아 있는데 RS와 OCS가 낮은 구간이 중요하다. 모델은 엉망으로 실패하기보다, 사람이 대충 보면 맞아 보이는 방향으로 실패한다. 데이터셋 구축에서는 이 유형이 더 위험하다. 실패가 눈에 덜 띄고, downstream 모델 학습이나 retrieval 품질 저하로 늦게 나타나기 때문이다.

내가 걸리는 약점은 CDR-Bench가 아직 “직접 실행형 LLM” 설정에 강하게 고정되어 있다는 점이다. 실제 운영에서는 모델에게 개인정보 redaction을 문자열로 직접 하라고 맡기기보다, 정규식/NER/tool 기반 operator를 조합하고 모델은 recipe 해석, 예외 판단, 검증 보고를 맡기는 구조가 더 현실적일 수 있다. 그래서 이 benchmark의 낮은 점수를 곧바로 “LLM data agent는 못 쓴다”로 읽으면 과하다. 정확히는 현재 모델을 deterministic executor처럼 단독 사용하면 위험하다는 결론에 가깝다. tool을 붙인 agent에서는 실패 양상이 달라질 수 있고, CDR-Bench는 그 전 단계의 최소 능력 검사지로 보는 편이 더 안전하다.

내가 확장한다면 다음 버전은 execution trace 기반 CDR-Bench로 만들 것 같다. 모델에게 최종 status와 clean_text만 내게 하지 않고, 각 operator 뒤의 intermediate text state, filter statistic, threshold comparison, stop decision을 JSON trace로 요구한다. 그 다음 deterministic executor와 step-by-step으로 비교한다. 이렇게 하면 최종 output이 틀렸을 때도 어느 단계에서 어긋났는지 바로 알 수 있고, 반대로 최종 output이 우연히 맞은 경우도 trace fidelity로 걸러낼 수 있다. 또한 tool-using 설정에서는 모델이 직접 text를 변환했는지, Data-Juicer 같은 tool 결과를 올바르게 해석했는지 분리해 평가할 수 있다.

후속 제안은 benchmark를 “모델 순위표”보다 “데이터 정제 시스템 설계 도구”로 쓰는 것이다. 예컨대 CDR-Bench의 failure taxonomy를 production pipeline monitor에 연결해, filter threshold error가 많은 task는 deterministic filter로 강제하고, formatting drift가 많은 task는 canonical formatter를 붙이며, wrong order가 많은 task는 recipe compiler와 state verifier를 둔다. 이렇게 사용하면 benchmark 점수가 낮다는 사실이 단순 비판에 머물지 않고 system architecture 선택으로 이어진다. 특히 RAG corpus 구축이나 개인정보 제거처럼 감사 가능한 preprocessing이 필요한 곳에서는, CDR-Bench식 평가가 모델 선택보다 guardrail 설계에 더 큰 가치를 줄 수 있다.

또 하나 주목한 점은 CDR-Bench가 모델 개발자에게도 꽤 불편한 평가라는 것이다. 일반 benchmark에서는 reasoning trace가 길고 설명이 설득력 있으면 좋은 인상을 주지만, 여기서는 trace의 설득력보다 final state의 재현성이 중요하다. 이 차이는 앞으로 agent training에도 영향을 줄 수 있다. reward model이 자연스러운 설명이나 plausible cleanup을 보상하면, 모델은 실제 operator semantics를 따르지 않고도 높은 선호 점수를 받을 수 있다. 반대로 CDR-Bench식 reward는 중간 상태와 output contract를 강하게 묶는다. 데이터 정제 agent를 강화학습하거나 supervised fine-tuning할 때는 이런 deterministic process reward가 필요해 보인다.

내가 특히 높게 보는 부분은 Refinement Gain을 함께 둔 점이다. RS만 보면 모델은 단순히 실패한 것으로 보인다. 그러나 RG가 남아 있으면 모델이 reference 방향으로 일부 이동했다는 사실을 알 수 있다. 이 차이는 모델 개선에 중요하다. RG가 낮은 실패는 task 이해부터 문제일 수 있고, RG가 높은 실패는 formatting, operator 누락, stop condition처럼 비교적 구체적인 보정 대상으로 볼 수 있다. CDR-Bench는 이 둘을 섞지 않으려 한다.

반대로 Order-Consistent Success는 intentionally harsh한 지표다. 같은 operator 집합의 여러 ordering variant를 모두 맞춰야 하므로, 한 instance를 우연히 맞추는 shortcut을 줄인다. 실제 pipeline에서도 이 harshness가 필요하다. 오늘은 filter가 앞에 있고 내일은 filter가 중간에 들어가는 recipe를 같은 모델에 맡길 때, 모델이 두 상황을 구분하지 못하면 자동화 신뢰성이 무너진다. OCS는 이런 신뢰성 요구를 숫자로 압축한다.

9. 결론: 그럴듯한 정제와 충실한 실행 사이의 거리

CDR-Bench는 LLM 데이터 정제 능력을 평가하는 방식에 중요한 구분을 추가한다. 기존 benchmark가 단일 편집, 코드 기반 workflow, semantic tagging을 각각 다뤘다면, 이 논문은 자연어 recipe를 결정적 operator sequence로 실행하는 능력을 본다. 3,462개 task, 29개 operator, 네 데이터 정제 도메인, 여러 prompt style, atomic-to-compositional track, order-sensitive group 평가를 통해 모델의 약점을 체계적으로 드러낸다. 핵심 결과는 간단하다. 모델은 단일 operator를 어느 정도 수행하고, 완전 실패 대신 그럴듯한 refinement를 만들 수 있지만, 여러 operator가 순서에 따라 연결되면 recipe-level success와 order-consistent success가 크게 낮아진다.

실무적으로 이 논문은 LLM을 데이터 전처리 agent로 쓸 때의 설계 원칙을 제안한다. 모델에게 최종 clean text만 맡기면 안 된다. operator graph, intermediate state, deterministic verifier, canonical formatter, stop condition checker가 함께 필요하다. 특히 DROP 이후에도 계속 실행하는 습관, 필터 임계값 판단 오류, formatting drift, semantic rewrite는 production data pipeline에서 조용히 누적될 수 있다. CDR-Bench는 이런 실패를 작은 실험실에서 재현하고, prompt나 thinking mode가 도움이 되더라도 충분하지 않다는 점을 보여 준다.

논문의 한계도 명확하다. Data-Juicer operator 범위, 정돈된 verbalization, direct text execution setting, 영어 중심 텍스트, multimodal/interactive refinement 부재는 후속 benchmark가 채워야 할 부분이다. 그럼에도 CDR-Bench의 가치는 뚜렷하다. LLM 평가에서 “답이 맞는가”를 넘어 “절차를 실제로 지켰는가”를 묻는 benchmark는 앞으로 더 중요해질 것이다. 에이전트가 데이터를 고치고, 필터링하고, privacy guardrail을 적용하고, RAG corpus를 만드는 역할을 맡을수록, procedural faithfulness는 부가 능력이 아니라 기본 안전 조건에 가까워진다.

9.1 CDR-Bench가 남기는 실무 체크리스트

CDR-Bench를 실제 프로젝트에 적용한다면 먼저 정제 요구를 operator catalog로 분해해야 한다. 어떤 작업은 정규식, parser, schema validator로 고정할 수 있고, 어떤 작업은 LLM의 semantic 판단이 필요하다. 그다음 각 operator가 입력 state, 출력 state, 실패 조건, stop condition을 명시해야 한다. 이런 정의가 없으면 모델은 자연어 요청을 하나의 편집 의도로 뭉뚱그려 처리한다. benchmark에서 나타난 wrong order와 missed operator는 대부분 이 경계가 흐려질 때 생긴다.

두 번째 체크리스트는 intermediate state logging이다. 최종 clean_text만 저장하면 나중에 오류가 발생했을 때 어떤 단계에서 망가졌는지 알기 어렵다. 각 operator 뒤의 text snapshot, filter score, threshold, KEEP/DROP decision을 함께 남기면 audit가 가능해진다. 특히 privacy cleanup이나 benchmark preprocessing처럼 재현성이 중요한 작업에서는 이 로그가 품질 보증 문서가 된다. CDR-Bench가 step-level trace를 직접 요구하지는 않지만, 낮은 OCS는 이런 logging이 왜 필요한지 강하게 암시한다.

세 번째는 canonical output layer다. 모델이 의미상 맞는 값을 만들었더라도 surface form이 흔들리면 자동 평가와 downstream parser가 실패한다. 따라서 JSON field ordering, whitespace normalization, redaction token format, chunk delimiter, LaTeX cleanup rule은 후처리 layer에서 다시 정규화하는 편이 안전하다. 모델은 모호한 판단과 예외 설명에 집중하고, 표면 형식은 결정적 formatter가 책임지는 구조가 CDR-Bench의 실패 패턴과 잘 맞는다.

마지막으로, 이 논문은 데이터 정제 agent 평가가 단순한 leaderboard 경쟁보다 system reliability 문제에 가깝다는 점을 보여 준다. 모델이 한두 percentage point 앞서는 것보다, 어떤 failure mode가 반복되고 그것을 어느 guardrail이 막을 수 있는지가 더 중요하다. 따라서 CDR-Bench 결과를 읽을 때도 최고 점수 모델을 찾는 데서 멈추지 말고, failure taxonomy를 자사 pipeline의 위험 목록과 대조하는 방식으로 쓰는 편이 생산적이다.

논문이 보여 준 또 다른 실무 포인트는 evaluation granularity다. 데이터 정제 시스템을 배포하기 전에는 전체 corpus 샘플 몇 개를 눈으로 확인하는 방식으로는 부족하다. operator별 unit test, recipe별 integration test, order-sensitive adversarial variant를 따로 만들어야 한다. CDR-Bench는 이를 benchmark 규모로 수행한 사례다. 같은 원리를 내부 데이터 파이프라인에 적용하면, 모델 업데이트나 prompt 변경 이후 어떤 operator family가 깨졌는지 빠르게 찾을 수 있다.

또한 CDR-Bench는 “더 강한 모델을 쓰면 언젠가 해결된다”는 낙관을 조심하게 만든다. 폐쇄형 최신 모델도 낮은 OCS를 보이고, prompt와 thinking mode가 개선을 주더라도 gap은 남는다. 이 결과는 모델 규모 확장과 시스템 설계가 함께 가야 함을 뜻한다. strong model, explicit recipe graph, deterministic tool, verifier, audit log가 결합될 때 데이터 정제 자동화가 실제로 신뢰 가능한 형태에 가까워진다.

결국 이 논문은 모델 평가를 데이터 엔지니어링 문제로 다시 끌어온다. 레시피가 실행 단위로 정의되고, gold가 재현 가능하며, 실패 유형이 guardrail 설계로 연결될 때 LLM benchmark는 단순 성능표를 넘어 운영 설계 문서가 된다. 이 점 때문에 CDR-Bench는 데이터셋 구축, 개인정보 제거, RAG corpus 정제처럼 반복 실행되는 작업을 자동화하려는 팀에게 특히 유용한 진단 도구로 읽힌다.

10. 요약 정리

• CDR-Bench는 LLM이 자연어로 주어진 compositional, order-sensitive data refinement recipe를 결정적 operator sequence처럼 충실히 실행하는지 평가한다.
• 벤치마크는 3,462개 task, 29개 operator, Web/LaTeX/RAG/Privacy 네 도메인으로 구성되며, Data-Juicer replay를 통해 LLM judge 없이 gold를 만든다.
• Atomic-M/F에서는 일부 모델이 그럭저럭 높은 성능을 보이지만, Agnostic-M, Order-M, Order-F로 넘어가면 Recipe Success와 Order-Consistent Success가 크게 낮아진다.
• RS, RG, OCS를 함께 쓰면 모델이 완전히 엉뚱한 답을 내는지, 그럴듯하지만 레시피와 어긋난 정제를 하는지, 순서별 variant를 실제로 구분하는지 분리해 볼 수 있다.
• Few-Shot, Plan-First, State-Aware prompting과 thinking mode는 일부 개선을 주지만, order-sensitive group을 안정적으로 해결하기에는 부족하다.
• DROP case 분석은 모델이 rejecting filter 이후에도 계속 정제를 수행하는 경향을 드러내며, 이는 데이터 파이프라인에서 stop condition checker가 필요하다는 신호다.
• 실패 taxonomy에서는 filter threshold error와 formatting drift가 크게 나타나며, 이는 LLM이 operator 실행을 정확한 규칙보다 대략적인 편집 의도로 처리하는 경향을 보여 준다.
• 의미론적 확장에서도 atomic 평균 58.8%와 compositional 30.8% 사이에 28.0pp gap이 나타나, composition bottleneck이 rule-based operator에만 국한되지 않음을 시사한다.
• 이 논문은 LLM 데이터 정제 agent를 만들 때 최종 출력만 보지 말고 intermediate state trace, deterministic verifier, canonical formatter, tool-based executor를 함께 설계해야 한다는 실무적 메시지를 준다.