GraphForge는 실제 업무 파일 위에서 과제와 그 채점 기준을 함께 세워, 문서를 읽고 도구를 다뤄 결과물을 만드는 '일하는 에이전트(working agent)'의 학습 데이터를 합성하는 방법이다. 파일들 사이의 관계를 증거 그래프(evidence graph)로 엮은 뒤, 거기서 과제 설명과 평가 항목을 동시에 뽑아낸다는 게 핵심이다. 이렇게 만든 2,169개 학습 궤적으로 Qwen3.6-27B를 미세조정하자 업무 능력을 재는 세 벤치마크 점수가 모두 올랐다.
일하는 에이전트를 가르치려면 두 가지가 동시에 필요하다. 하나는 진짜 같은 일거리 — 보고서, 스프레드시트, 정책 문서가 뒤섞인 실제 작업 공간이다. 다른 하나는 그 일을 제대로 해냈는지 가려낼 채점표다. 신입에게 실무를 맡길 때 현실적인 과제를 주는 일과, 결과물을 평가할 기준을 쥐여주는 일이 서로 다른 준비인 것과 같다.
지금까지 나온 학습 데이터 합성 방식은 둘 중 하나를 포기했다. 논문이 비교 대상으로 든 두 파이프라인이 그 두 갈래를 각각 대표한다.
| 방식 | 작업 환경 | 검증 | 규모 |
|---|---|---|---|
| EnvCraft | 모델이 생성한 작업 공간 | 상태 확인 스크립트 | 20K 과제 |
| NexForge | 실제 파일 | 없음 | 5.6K 과제 |
| GraphForge | 실제 파일 | 증거 기반 에이전트 심판 | 2.1K 과제 |
EnvCraft는 파일 자체를 모델로 찍어내는데, 그러다 보니 현실성과 다양성이 떨어진다. 게다가 검증을 파이썬 스크립트로 작업 공간의 '상태'만 보기 때문에 파일 내용을 읽지 못하고, 문서 결과물 안에 숨은 오류를 놓친다. NexForge는 반대로 실제 파일 위에 과제를 세우지만 과제별 채점 기준이나 검증기를 주지 않아서, 에이전트가 내놓은 결과의 품질을 따져볼 길이 없다. 진짜 파일로 다양한 과제를 만들면서, 거기에 믿을 만한 채점 기준까지 붙이는 일이 그만큼 어려웠다는 뜻이다.
GraphForge가 영리한 지점은 '방향'과 '내용'의 출처를 갈라놓은 데 있다. 모델에게 과제를 알아서 지어내라고 하면 흔한 직업과 뻔한 분석 과제로 쏠린다. 그래서 과제의 방향은 직업 데이터로 못 박고, 구체적인 내용과 검증은 전부 실제 파일에서 끌어낸다. 전체 과정은 다섯 단계로 흐른다.
먼저 씨앗(seed)을 O*NET이라는 직업 데이터베이스에서 뽑는다. 미국 노동부 계열의 공식 직업 사전으로, 직업마다 할 일과 세부 업무 활동(DWA)이 정리돼 있다. 이 중 디지털로 수행 가능한 과제만 남기면 16개 산업 분야에 걸친 246개 직업, 891개 업무 유형, 3,419개의 유효한 조합이 남는다. 쏠림을 막기 위해 이미 고른 씨앗과 겹치지 않는 쪽을 우선 집어 다양성을 넓게 펼친다.
씨앗 자체에는 회사명도, 사건도, 데이터도 없다. "누가, 어떤 수요를, 주로 어떻게 처리하는가"만 담긴 빈 틀이다. 다음 단계에서 검색 에이전트가 실제로 존재하는 공개 사례를 찾아 그 일에 필요한 파일들을 모아 작업 공간을 꾸린다. 이때 파일마다 겉으로 드러나지 않는 역할이 붙는다. 핵심 파일은 계산과 판단을 끌어가고, 보조 파일은 맥락을 주며, 혼란 파일(confuser)은 그럴듯하지만 실제로는 쓸모없는 함정이고, 주변 파일은 현실적인 잡음을 더한다. 이 역할표는 과제를 푸는 에이전트에게는 끝까지 보여주지 않는다.
그 위에 증거 그래프를 세운다. 그래프의 노드는 어떤 파일이 제공하는 사실이나 값이고, 엣지는 파일을 넘나드는 의존 관계 — 비교하거나 대조하거나 끌어내야 하는 연결이다. 바로 이 그래프에서 과제 설명과 채점 기준이 함께 컴파일된다. 각 채점 항목에는 평가에 필요한 파일이 증거 앵커(anchor)로 묶이고, 어떻게 확인할지 절차까지 붙는다. 과제를 푸는 에이전트는 과제문과 요구사항만 보고, 심판은 앵커와 확인 절차를 받는다. 채점표를 파일에 못 박아 두되, 그 못의 위치는 문제지에 새어 나가지 않게 한 셈이다.
여기서 끝내지 않는다. 글로만 들여다봐서는 긴 과제의 애매함이 다 잡히지 않으므로, 강한 교사 모델에게 과제를 한 번 실제로 풀려 본다. 그 실행 결과를 수정 에이전트가 원본 파일·그래프와 대조해, 과제가 자연스러운지, 요구한 값이 파일로 뒷받침되는지, 모든 항목이 제대로 앵커돼 있는지를 점검하고 고쳐야 할 부분만 돌려준다. 마지막으로 결과물이 실제로 만들어졌는지 기계적으로 확인한 뒤, 에이전트 심판이 원본 파일과 산출물을 번갈아 보며 항목별로 점수를 매긴다. 도구를 헛되이 반복 호출하는 등 비정상적인 궤적은 걸러낸다. 이렇게 통과한 것만 학습 데이터로 들어간다.
저자들은 Qwen3.6-27B를 GraphForge 데이터로 미세조정해 세 벤치마크에서 재봤다. 수치는 각각 다른 평가 하네스(에이전트 실행 틀) 아래서 나온 값이라, 조건을 묶어 읽어야 한다.
| 벤치마크 | 결과 | 향상 | 평가 하네스 |
|---|---|---|---|
| GDPVal (Elo) | 1445.7 | +65.7 | OpenHands |
| Workspace-Bench-Lite | 63.7 | +7.7 | Claude Code |
| SpreadsheetBench II | 24.0 | +13.7 | Claude Code |
GDPVal 점수는 백분율이 아니라 Elo 평점인데, 뜻을 정확히 새겨야 한다. 이 1445.7은 사람의 작업물과 직접 견준 값이 아니다. 저자들이 여러 모델·하네스 조합을 서로 맞붙여 산출한 내부 Elo로, GLM-5.3(OpenHands) 조합을 1667로 고정해 척도의 기준점을 잡았고 1445.7은 그 척도 위에서의 상대 위치다. GDPVal 자체는 44개 직업에 걸친 1,320개 과제를 전문가 채점표로 평가하는 벤치마크이고, 저자들은 그중 220개 금(gold) 부분집합을 썼다. 눈에 띄는 건 스프레드시트 쪽 상승폭이다. 24.0은 +13.7이 더해진 값이니 출발점이 10.3 안팎이었다는 뜻인데, 상대적으로 가장 크게 뛰었다.
여기에 더해, 저자들은 미세조정한 모델이 스스로 만든 실행 결과 중에서 증거 기반 채점표로 좋은 것만 골라 다시 학습시키는 거절 미세조정(rejection fine-tuning)을 돌렸다. 세 벤치마크 모두에서 추가로 점수가 올랐다는 건, 그 채점표가 단순한 평가 도구를 넘어 "어떤 결과물이 쓸 만한지" 골라내는 신호 역할까지 한다는 뜻이다. 같은 데이터가 구조가 다른 두 번째 기반 모델(Qwen3.6-35B-A3B)에서도 효과를 냈다는 점은, 이 방식이 특정 모델에만 들어맞는 요령이 아닐 가능성을 보여준다.
규모를 보면 또 다른 판단이 선다. GraphForge의 과제 수는 2.1K로, 비교군(20K, 5.6K)보다 훨씬 적다. 적게 만들었는데 더 나아졌다면, 검증된 소수의 데이터가 검증 없는 다수보다 낫다는 쪽을 가리킨다. 데이터와 모델은 공개돼 있다.
솔직히 짚을 대목이 몇 가지 있다.
최종 채점을 사람이 아니라 에이전트 심판(LLM 기반)이 한다. 채점표가 파일에 앵커돼 있어 근거 없는 판정은 줄겠지만, 심판 자체의 신뢰도는 여전히 열린 문제다. 논문의 표현도 단정이 아니라 "채점표가 유용한 선택 신호를 주는 것으로 보인다"는 식의 조심스러운 쪽이다.
학습 궤적이 강한 교사 모델의 실행에서 나온다는 점도 양날이다. 교사가 못 푸는 유형은 데이터에도 담기기 어렵고, 교사의 습관과 한계를 물려받을 소지가 있다. 증거 그래프 역시 저자들이 "정답이 아니라 중간 표현"이라고 분명히 못 박았다. 그래프의 주장은 원본 파일에서 다시 확인 가능해야 하는 보조 장치일 뿐이어서, 그래프가 파일을 얼마나 충실히 반영했는지에 품질이 걸린다.
위 수치는 특정 벤치마크를 특정 하네스 아래서 잰 값이다. 다른 과제나 다른 실행 환경으로 얼마나 번질지는 보고된 범위 밖이다. 논문에는 별도의 한계 논의 절이 있다고 돼 있으나, 이 글이 받은 발췌에는 그 세부가 담기지 않아 구체 내용을 단정하지 않는다.
온틀에서 AI PM이 작업을 "완료"라고 보고하는 순간을 떠올려 보자. 고객이 올린 이카운트 정산 내역, 공급사 견적 엑셀, 계약 조건 PDF가 한 폴더에 섞여 있고, PM은 그걸 읽어 월 정산 리포트를 만들어 냈다고 한다. 문제는 그다음이다. 정말 맞게 했는가. 온틀이 반복해서 데인 '가짜완료(ghost-done)' — 상태는 완료로 바뀌었는데 실제 결과는 비어 있거나 틀린 상황 — 이 바로 이 지점에서 생긴다. 지금까지의 확인은 결국 "산출물이 그럴듯한가"를 사람이 눈으로 훑는 수준에 머물기 쉽다.
GraphForge의 증거 앵커 발상이 바꾸는 게 정확히 이 장면이다. "정산 합계가 맞다"를 막연히 판정하는 대신, 그 판정에 필요한 파일과 셀을 채점 항목에 미리 못 박아 둔다. 견적 엑셀의 D열 합계, 계약 PDF의 수수료 조항, 이카운트 내역의 해당 전표 — 각 합격 조건이 어느 파일의 어느 값을 봐야 검증되는지가 과제를 만드는 순간에 함께 정해진다. 그러면 PM의 "완료"는 느낌이 아니라 "이 항목은 이 파일의 이 값과 대조해 통과"라는 추적 가능한 근거로 바뀐다. 과제를 푸는 PM에게는 앵커를 숨기고 심판에게만 주는 구조도 그대로 쓸모가 있다. PM이 정답 경로를 역산해 흉내 내는 게 아니라, 실제로 파일을 읽어 일하도록 강제되기 때문이다. 온틀이 당장 이 파이프라인을 들여오자는 얘기가 아니라, "완료를 소스 파일에 묶어 검증한다"는 설계 원리가 가짜완료 문제의 정공법에 가깝다는 뜻이다.
논문은 합성 데이터와 학습된 모델을 공개했다고 밝히고 있습니다. HuggingFace의 groundhogLLM/graphforge 컬렉션에서 접근할 수 있다고 적혀 있습니다. 다만 라이선스와 실제 재현 조건은 공개 페이지에서 직접 확인해야 합니다.
직업마다 수행 업무와 세부 활동을 정리해 둔 공식 직업 데이터베이스입니다. 모델이 자유롭게 과제를 지어내면 흔한 직업과 뻔한 분석에 쏠리는데, 직업 데이터를 씨앗으로 쓰면 과제의 방향을 넓게 펼친 채로 고정할 수 있습니다. GraphForge는 이 중 디지털로 수행 가능한 과제만 남겨 씁니다.
아닙니다. 논문은 증거 그래프가 정답이 아니라 중간 표현이라고 분명히 합니다. 그래프에 담긴 주장은 반드시 원본 파일에서 다시 확인 가능해야 하는 보조 장치이고, 최종 근거는 어디까지나 실제 파일입니다.
일반 미세조정(SFT)이 교사 모델의 실행 궤적을 그대로 배우는 단계라면, 거절 미세조정은 학습된 모델이 새 과제에서 스스로 만든 결과 중 채점표로 좋은 것만 골라 다시 학습하는 방식입니다. 이 논문에서는 선별 기준으로 증거 기반 채점표를 썼고, 세 벤치마크 모두에서 추가 향상이 나왔습니다.