GeoReform: 형식화 자체를 진화시켜 멀티모달 기하 문제를 푸는 새로운 길

멀티모달 대형 언어 모델은 오랫동안 기하 문제에 약했고, 그 이유는 어렵지 않게 설명된다. 풀이의 핵심 정보가 도형 안에 있기 때문이다. 어느 선이 수직인지, 어느 각이 같은지, 어느 호가 어느 원에 속하는지를 모델은 자주 정확히 읽지 못한다. 읽는 데 성공해도 그것을 올바르게 쓰지 못하는 경우가 많다. 최근 널리 쓰이는 대응책은 도형 속 기하 개체, 관계, 제약을 명시적인 텍스트로 옮기고, 그 텍스트 위에서 모델이 추론하게 하는 것이다. 이 발상은 직관적이고 실제로 효과도 있다. 그러나 2026년 10월 8일에 공개된 논문 GeoReform(arXiv 2610.12391, 저자 Jialu Wang, Ruichen Zhang, Xiaoou Liu, Hua Wei, Tianlong Chen)은 더 날카로운 질문을 던진다. 번역의 품질 자체가 어려운 문제가 아닌가 하는 질문이다.

논문이 제시하는 숫자는 작지만 설득력이 있다. Geometry3K의 200개 예시에서 구조 주입은 기존 모델이 틀리던 28문제를 바로잡았다. 하지만 동시에 원래 맞히던 13문제를 틀리게 만들었다. 합산하면 개선이지만 대가는 분명히 존재한다. 저자들은 원인을 평이하게 정리한다. 중복된 관계는 모델의 주의를 흩뜨린다. 도형 요소에 대한 모호한 지칭은 제약을 엉뚱한 대상에 적용하게 만든다. 따라서 병목은 더 많은 기하 사실을 추출하는 데 있지 않다. 그 사실들을 다음 단계의 추론을 뒷받침하는 표현으로 조직하는 데 있다. 모델에 정보를 많이 주는 것과 올바른 정보를 주는 것은 다르다.

이 진단에 따라 GeoReform은 형식화의 지위를 바꾼다. 형식화는 더 이상 파서가 내놓는 고정된 출력이 아니다. 시스템이 최적화할 수 있는 정책이 된다. 절차는 이렇게 요약된다. 먼저 현재의 형식화 정책으로 추론 파이프라인 전체를 실행한다. 다음으로 실패한 추론 궤적을 모은다. 이어서 현재 표현에 어떤 결함이 있는지 진단한다. 마지막으로 정책을 변이시켜 기하 개체, 관계, 제약, 구하려는 대상을 더 잘 선택하고, 접지하고, 묶고, 제시하게 한다. 이 네 동사는 각각 서로 다른 실패에 대응한다. 선택은 어떤 사실을 남길지 정한다. 접지는 한 진술이 도형의 어느 요소를 가리키는지 확정한다. 묶기는 사실들 사이의 구조를 정한다. 제시는 모델이 읽을 텍스트의 배열을 정한다.

설계의 핵심은 학습 신호가 어디서 오느냐에 있다. 전통적인 파서는 이미지를 충실하게 기술하려 하지만, 충실한 기술이 항상 유용한 기술은 아니다. GeoReform에서는 실패한 추론이 어떤 표현이 모델을 오도하는지 시스템에 알려 준다. 이런 점에서 이 방법은 성찰형·진화형 프롬프트 및 정책 최적화의 흐름에 속하며, 지난 오류를 검토하는 일을 시스템의 일부로 만든다. 다만 주의할 점이 있다. 초록은 변이 연산의 구체적 내용, 탐색 예산, 각 구성 요소의 절제 실험을 밝히지 않는다. 이런 세부 사항은 본문에서 확인할 일이며, 여기서는 추측하지 않는다.

결과는 특히 작은 모델에 유리하다. Geometry3K에서 Qwen3VL-2B의 정확도는 42.0%에서 56.0%로 14퍼센트포인트 올랐다. 20억 매개변수 규모의 모델이 더 나은 표현만으로 이만큼 향상되었다. 이는 오류의 상당 부분이 추론 능력 부족이 아니라, 추론이 시작되기 전에 문제 진술이 잘못 표현된 데서 비롯되었을 가능성을 시사한다. 저자들은 여러 기하 추론 벤치마크에서 폭넓은 실험과 분석을 수행했고, 효과적인 형식화가 멀티모달 기하 추론에 결정적이라고 결론짓는다. 그렇더라도 한 벤치마크의 한 모델 결과를 일반 법칙으로 볼 수는 없다. 더 큰 모델과 다른 벤치마크에서도 같은 폭의 향상이 유지되는지는 독립적인 재현이 필요하다.

업계에 주는 시사점은 기하학을 넘어선다. 시각 또는 반구조화 입력을 텍스트로 바꾼 뒤 추론하는 과제는 모두 같은 긴장을 안고 있다. 정보를 추출하는 일과 정보를 조직하는 일은 서로 다른 작업이다. 차트 질의응답, 회로도 이해, 설계 도면 검토가 모두 이 유형에 속한다. GeoReform은 중간 표현을 최적화해야 할 일급 대상으로 다루는 편이 모델을 단순히 키우는 것보다 더 이득일 수 있음을 시사한다. 엔지니어링 팀에게 현실적인 첫걸음은 실패 사례를 구조화해 쌓고, 프롬프트뿐 아니라 입력 표현을 고치는 데 쓰는 것이다. 이 길은 비용이 낮고, 감사하기 쉽고, 반복하기도 쉽다. 오늘의 기술 레이더에 올릴 만하다.