과정을 채점했더니 답이 좋아졌다 — OneSearch-VL

정답만 보지 않는다. '어디를 봤고 무슨 근거로 답했나'까지 채점하는 OneSearch-VL. 이 과정 채점을 보상에 더하자 벤치마크 평균이 57.3에서 61.1로 올랐다.
English  ·  日本語  ·  한국어
← 목록으로
온
온틀 리서치
2026년 10월 10일 수정 2026.10.16 읽기 17분 조회 2

답이 맞았는지만 채점하는 AI는 많다. OneSearch-VL이 다른 건, "그 답에 어떻게 도달했는지"까지 따로 채점한다는 점이다.

사진 한 장, 여러 장, 영상까지 세 가지 시각 입력을 하나의 에이전트(스스로 도구를 골라 써가며 일을 처리하는 AI)로 조사하게 만든 8B(80억 파라미터) 규모 모델이다. 핵심 장치는 두 가지를 들여다본다. 하나, 답을 떠받치는 사실이 실제로 도구가 돌려준 화면과 검색 결과에서 나왔는가. 둘, 화면에서 엉뚱한 데가 아니라 올바른 지점을 짚어 그 뒤 조사를 끌고 갔는가.

효과는 저자들이 실험으로 못박았다. 답과 질의 품질만 채점하던 보상에 이 '과정 채점'을 얹자, 표준 성능 시험(벤치마크) 평균이 57.3에서 61.1로 올랐다. 답에 이르는 길을 채점했을 뿐인데, 도착한 답 자체가 좋아진 것이다.

왜 최종 답만 봐선 안 되나

거리를 천천히 훑는 10초짜리 영상이 있다. 가게 간판 몇 개가 지나간다. 질문은 이렇다. "이 영상에 나온 브랜드 중 창업한 지 50년이 넘은 곳은 몇 개인가?"

눈으로만 봐선 못 푼다. 창업 연도는 화면에 안 적혀 있으니까. 제대로 답하려면 이런 사슬을 밟아야 한다. 먼저 간판이 보이는 구간을 고르고, 그 순간의 프레임을 뽑는다. 간판을 하나씩 잘라 글자를 읽고 어느 브랜드인지 식별한다. 브랜드마다 창업 연도를 웹에서 검색한다. 그중 50년이 넘은 곳만 골라 센다. 그제야 개수가 나온다.

이걸 하려고 모델은 여러 도구를 쓴다. 구간 고르기, 프레임 뽑기, 자르기, 글자 읽기, 이미지 검색, 웹 검색 같은 것들. 중요한 건 도구가 제각각 놀지 않는다는 점이다. 도구 종류가 무엇이든 같은 창구로 명령을 내리고 같은 양식으로 결과를 돌려받는다. 그래서 사진 한 장이든 영상이든, 하나의 에이전트가 같은 방식으로 다룬다.

자, 모델이 "3개"라고 답했다 치자. 맞았다. 그런데 이 3개는 제대로 조사해서 나온 걸까, 아니면 엉뚱한 프레임을 보고 대충 찍었는데 운 좋게 맞은 걸까? 최종 답만 봐선 둘이 똑같아 보인다. 브랜드를 다 맞혀도 창업 연도를 잘못 가져오면 틀리고, 과정이 엉터리인데 우연히 3개가 맞을 수도 있다. 어려운 건 마지막 숫자가 아니라 거기까지 가는 사슬이다. 이 논문의 베팅은 분명하다. 그 사슬을 통째로 붙들어 데이터·학습·평가에 똑같이 쓰겠다는 것.

흩어진 단서를 하나로 꿰는 '증거 보드'

이 사슬을 데이터에 어떻게 남기느냐가 진짜 숙제다. 기존 연구들이 번번이 미끄러진 지점이기도 하다.

수사 드라마의 증거 보드를 떠올려 보자. 벽에 사진을 붙이고, 압정으로 문서를 꽂고, 실로 사진과 문서와 결론을 잇는 그 보드. 사건을 푸는 건 사진 한 장이 아니라 그걸 잇는 실이다. 기존 방법들이 자주 잃어버린 게 바로 이 실이었다. 증거를 그래프 같은 구조에 담아 쓰긴 했지만, '간판 → 브랜드 → 창업 연도 → 개수'로 이어지는 의존의 사슬을 끝까지 보존하지 못했다. 사진이나 최종 결론은 남겼는데 그 사이를 잇는 부분을 흘렸다. 영상 쪽은 더 심해서, 키프레임을 검색의 씨앗으로만 쓰고 "이 결론이 어느 관측에서 나왔는지"의 출처를 명시적으로 남기지 않았다.

OneSearch-VL이 디지털로 옮긴 증거 보드가 VGEG(시각 근거 증거 그래프)다. 벽에 붙인 사진은 화면에서 "여기를 봤다"고 집어낸 지점(앵커)과 그게 무엇인지에 해당한다. 압정으로 꽂은 문서는 출처가 뒷받침하는 외부 사실이다. 둘을 잇는 실은 앵커와 사실과 연산 사이의 의존 관계다. 여기에 사실들을 묶어 답을 만드는 연산 — 세기, 비교, 계산 — 이 더해진다. 우리 영상 질문이라면, 간판이 찍힌 프레임(사진), 각 브랜드의 창업 연도 문서(압정 문서), 그리고 '이 간판 = 이 브랜드 = 그 창업 연도 = 50년 기준 해당'을 잇는 실이 한 보드에 모인다.

핵심은 이 보드 한 장을 네 군데에 똑같이 쓴다는 데 있다. 질문을 만들 때, 전문가의 풀이를 걸러낼 때, 모델이 직접 풀어보고 점수를 받을 때, 연산별로 성적을 매길 때. 학습과 평가가 서로 다른 잣대로 노는 대신 같은 보드를 본다. 과제가 주어지면 입력 전체의 큰 증거 지도에서 그 과제에 필요한 부분만 오려내 작은 보드를 만든다. 거대한 지도에서 이번 질문에 쓸 구역만 표시한 미니맵인 셈이다.

보드를 중심으로 데이터도 찍어낸다. 쓸 만한 웹 영상 250만 개를, 식별 가능한 대상과 검색 여지가 있는 7만 개로 걸러낸다. 각 영상을 잘게 쪼개 화면 곳곳에 '여기 이게 있다'는 앵커를 심고, 그 앵커를 이미지 검색·글자 읽기·웹 검색으로 실제 사실과 출처에 잇는다. 완성된 보드에 비춰 질문과 답을 만들고, 마지막으로 전문가 모델이 실제 도구를 써가며 남긴 풀이 가운데 답도 맞고 과정 품질도 통과한 것만 남긴다. 이렇게 모은 게 학습용 데이터 SFT-110K와 RL-10K다(두 숫자가 각각 무엇을 센 건지는 끝의 FAQ에서).

한 가지 짚어둘 게 있다. 이 연구는 새로운 검색 능력을 더한 게 아니다. 직전작의 데이터와 보상을 물려받고, 그 위에 '증거를 어떻게 다뤘는지'를 감독하는 틀을 얹어 다중 이미지와 영상으로 범위를 넓힌 쪽에 가깝다.

운으로 맞힌 길과 제대로 밟은 길을 가른다

리드에서 말한 그 두 채점 축에 장치 이름이 있다. EVGR이다. 과제마다 채점표를 만든다. 답의 핵심은 무엇이고, 그걸 떠받칠 사실은 무엇이며, 그 사실의 출처와 근거 문장은 무엇이고, 어느 프레임과 영역을 봐야 하는지. 모델의 풀이를 이 채점표에 포개 보고 점수를 매긴다.

두 축을 굳이 나눈 이유가 중요하다. 답만 보면 운으로 맞힌 길과 제대로 밟은 길이 똑같아 보인다. 하지만 '사실이 진짜 관측에서 나왔나'와 '화면에서 맞는 데를 짚었나'를 따로 물으면, 우연히 정답에 도착한 엉터리 풀이를 걸러낼 틈이 생긴다.

그리고 이 두 축은 입력 종류에 따라 무게가 다르다. 사진 한 장이나 여러 장은 볼 장면이 이미 다 주어져 있다. 그래서 관련된 순간을 담은 프레임을 직접 골라야 하는 부담이 없다 — 추가로 시각 도구를 반드시 더 불러야 하는 건 아니라는 뜻이지, 아예 안 쓴다는 말이 아니다. 사진에도 자르기(Crop)·글자 읽기(OCR) 같은 도구가 똑같이 주어지고, 실제로 여러 장을 조사할 땐 화면을 여러 번 잘라 보는 경우도 있다. 영상은 다르다. 관련된 순간을 담은 프레임을 직접 골라야 하고, 그 선택이 틀리면 뒤따르는 검색이 통째로 어긋난다. 그래서 '화면에서 맞는 데를 짚었나'라는 축은 영상에서 유독 무겁게 작동한다. 영상 조사가 어려운 진짜 이유가 여기 있다.

따라 배운 뒤, 직접 써보며 다듬는다

학습은 두 단계다. 먼저 전문가가 실제로 도구를 써서 남긴 풀이를 통째로 따라 배운다. 그다음 모델이 직접 도구를 써보게 하고, 받은 점수로 판단을 더 정교하게 다듬는다. 앞이 모방, 뒤가 시행착오다.

설계에서 눈여겨볼 대목 몇 가지. 따라 배우는 단계에서는 도구가 돌려준 결과물을 '잘 맞혔나' 채점에서 뺀다. 그건 모델이 지어낸 게 아니라 밖에서 들어온 값이니, 모델이 스스로 고른 행동만 평가하는 게 공정하다. 다듬는 단계의 점수는 답 정확성, 질의 품질, 그리고 EVGR의 과정 점수를 합한 값이다. 단, 추론과 도구 호출과 응답의 형식이 올바를 때만 점수를 준다. 또 하나, 라이브 웹 검색은 중간에 실패하는 게 거의 상수다. 그래서 도구 실행이 끊긴 풀이도 통째로 버리지 않고, 실패 직전까지의 멀쩡한 부분만 추려 학습에 쓴다. 사소해 보여도 실전에선 결정적인 처리다.

평가: 연산 단위로 쪼개는 영리함

그럼 잘했는지 어떻게 재나. 최종 답은 GPT-4o가 참조 답과 비교해 맞다·틀리다로 가른다. 비교 상대는 세 층으로 깔았다. 도구 없이 바로 답하는 쪽, 검색 결과를 붙여 주는 쪽, 도구를 쓰는 에이전트 쪽. 이 중 같은 8B 규모의 바탕 모델에 도구만 붙인 버전이 가장 공정한 맞상대다.

영리한 선택은 평가를 '무엇을 묻나'가 아니라 '무슨 연산이 필요한가'로 쪼갠 것이다. 새로 만든 두 벤치마크는 같은 연산 분류를 쓴다. 앵커 하나로 푸는 문제, 여러 번 검색을 타고 넘어야 하는 문제, 조건을 걸어 세는 문제, 여러 앵커를 이어 붙이거나 계산하거나 비교하는 문제. 왜 이렇게까지 쪼갰나. 정답률 하나로는 실패가 어디서 났는지 안 보이기 때문이다. 대상을 못 찾은 건지, 관계를 못 이은 건지, 조건을 못 거른 건지. 연산별로 나눠야 그 지점이 드러난다.

다만 이런 영리함이 역으로 미심쩍은 구석도 낳았다. 이 두 벤치마크를 짜는 연산 분류가, 모델을 학습시킨 데이터 엔진의 분류와 같은 체계다. 시험 문제를 낸 기준과 공부시킨 기준이 같다는 뜻이다. 그러니 이 두 벤치마크 성적에는 '같은 틀을 공유하는 유리함'이 얼마간 섞여 있다고 봐야 한다. 그래서 바깥에서 만든 영상 벤치마크 VideoDR과 기존 단일 이미지 일곱 개 벤치마크를 함께 봐야 균형이 맞는다. 하나 더, GPT-4o의 이진 판정은 최종 답만 잰다. 거기까지 간 경로의 질은 못 잰다. 그 공백을 메우는 게 EVGR의 두 심판과 방금 말한 연산별 분해다.

점수는 증거를 엮는 자리에서 벌어졌다

이제 숫자를 보자. 단일 이미지 일곱 개 벤치마크 평균은 58.3. 같은 바탕 모델에 도구만 붙인 에이전트보다 16.3%p, 직전작 OpenSearch-VL보다 1.7%p 높다. 일곱 개 전부에서 직전작을 앞섰고, 도구를 쓰는 다른 방법들과 견줘도 일곱 중 여섯에서 최고였다. 이 결과가 말하는 건 하나다. 다중 이미지·영상 풀이까지 한 솥에 넣고 함께 배웠는데도, 사진 한 장 조사 실력이 깎이지 않았다. 섞어 배운 게 손해가 아니었다는 첫 신호다.

다중 이미지와 영상에서는 격차가 더 벌어진다. 새 벤치마크 두 개에서 도구 붙인 동급 모델을 각각 20.2%p, 17.6%p 앞섰고, 바깥에서 만든 VideoDR에서는 27.0%p를 벌렸다.

중요한 건 격차가 어디서 벌어졌느냐다. 단순 조회가 아니었다. 여러 증거를 걸러 엮고 계산하는 복합 문제에서 크게 벌어졌다. 다중 이미지에서는 조건을 걸어 세기(+29.8%p), 여러 앵커를 모아 계산하기(+26.3%p), 비교하기(+22.5%p). 영상에서는 여러 번 검색을 타고 넘기(+25.5%p), 계산하기(+20.0%p), 앵커 이어 붙이기(+19.2%p). 하나같이 데이터 엔진이 처음부터 겨냥한 조합 연산이다.

패턴은 한쪽으로 뚜렷하다. 단순 찾기에서는 격차가 작고, 증거를 조합해야 하는 자리에서만 유독 크게 벌어진다. 이 쏠림은 이 모델이 '흩어진 증거를 더 잘 엮는' 쪽으로 개선됐음을 시사한다. 데이터 설계 단계부터 조준했던 바로 그 능력에서 점수 차가 벌어진 셈이다. 다만 여기엔 분명한 선이 있다. 논문은 연산별 정답률과 보상 제거 실험은 보고하지만, 검색 횟수를 통제하거나 검색량의 영향만 따로 떼어낸 실험은 제시하지 않는다. 그러니 복합 문제에서 개선 폭이 크다는 사실만으로 '검색을 더 많이 해서 오른 게 아니다'라고 단정할 수는 없다. 지금 말할 수 있는 선은, 이 패턴이 증거 조합 능력의 개선을 시사한다는 데까지다.

받침이 되는 실험이 둘 더 있다. 첫째, 세 입력을 함께 배운 구성이 6개 벤치마크 평균 55.8로, 한 유형만 배운 경우(51.7~55.1)보다 높았다. 섞는 게 이득이라는 걸 숫자로 못박았다. 둘째가 리드에서 든 그 결과다. 답·질의 보상만 쓰다가 과정 채점을 더했을 때의 상승 — 과정을 채점하는 보상이 결과 점수까지 끌어올린다는 직접 증거다. 단, 이 두 실험은 서로 다른 설정(데이터 혼합 / 보상 구성)에서 나온 값이다. 55.8과 리드의 그 상승을 한 줄로 이어 읽으면 안 된다.

한계와 남은 질문

짚을 지점은 넷이다.

하나, 평가도 보상도 '판정 모델'에 기댄다. 최종 정답은 GPT-4o가, 과정 점수는 두 심판 모델이 매긴다. 심판의 품질과 편향이 곧 평가와 보상의 천장이다. 심판이 틀리면 정답도 보상도 같이 틀린다.

둘, 데이터 엔진이 LLM의 생성·검증·필터에 크게 의존한다. 250만 개를 7만 개로 쳐내는 과감한 거르기는 남은 데이터의 품질을 올리는 동시에, 무엇이 살아남느냐가 상류 모델의 성향에 좌우된다는 뜻이기도 하다.

셋, 보고된 성적은 8B 한 규모의 것이다. 더 크거나 작은 모델에서도 같은 이점이 나올지, 비용은 얼마일지는 이 논문이 답하지 않는다.

넷, 앞서 말한 신규 벤치마크의 홈 어드밴티지. 다만 바깥에서 만든 영상 벤치마크에서도 격차가 크게 난 사실이 이 우려를 상당히 덜어 준다.

온틀에 옮겨 보면

OneSearch-VL의 문제의식은 우리가 매일 마주하는 고민과 똑같다. 답이 그럴듯하면 맞는 것처럼 보인다. 근거가 있는지 없는지는 답만 봐선 모른다. 온틀의 AI PM에도 정확히 이 급소가 있다.

장면 하나를 끝까지 따라가 보자. 고객이 10분짜리 결제 화면 녹화를 올리며 묻는다. "우리 결제 플로우에서 경쟁사 대비 빠진 게 뭐냐." PM이 할 일은 방금 본 영상 조사와 사실상 같다. 결제 단계가 보이는 구간과 프레임을 집고, 화면 속 버튼이 무슨 기능인지 식별하고, 외부 문서를 검색해 경쟁사 표준과 대조한 뒤, 그 사실들을 묶어 결론을 낸다.

과거에 데인 지점이 정확히 여기였다. 그럴듯하게 들리지만 영상 어디에도, 어떤 출처에도 근거가 없는 결론. EVGR의 발상을 온틀 언어로 옮기면 이렇게 된다. 답이 맞았는지와는 별개로, 그 결론을 떠받치는 사실이 고객이 올린 영상의 그 프레임과 검색해 읽은 그 문서에서 실제로 나왔는지, 그리고 PM이 영상의 '맞는 순간'을 진짜로 짚었는지를 따로 확인한다.

그래서 제품에 내릴 결론은 한 줄이다. 결론을 먼저 내고 근거를 나중에 끼워 넣지 말 것. 결론마다 '화면의 어느 지점'과 '어느 외부 출처'를 처음부터 함께 묶어 저장한다. 온틀의 고객 화면은 작업을 시간순 흐름으로 보여 준다. 그 흐름의 매 노드에 '이 결론은 업로드 영상 03:12의 그 장면과 외부 출처 2건에 근거함'이 애초에 달려 있게 하는 것이다. 그러면 나중에 근거를 되짚는 일이 사후에 붙이는 기능이 아니라 작업 구조 자체에서 나온다. 고객 화면에는 내부 용어 없이 '근거: 업로드 영상 03:12, 참고 출처 2건'처럼 고객의 말로만 비치면 된다. 그럴듯함이 아니라 되짚을 수 있는 근거를 기본값으로. 이게 이 논문이 온틀의 결제 영상 한 장면에 주는 실질적인 결론이다.

FAQ

모델과 데이터는 공개되나?

논문은 프로젝트 저장소로 GitHub(appletea233/OneSearch-VL), 모델 허브로 HuggingFace(OneSearch-VL)를 제시한다. 공개 범위·라이선스·체크포인트의 구체적 사항은 해당 저장소에서 직접 확인해야 한다.

SFT-110K와 RL-10K의 숫자는 각각 무엇을 센 건가?

센 대상이 다르다. SFT-110K는 통합 멀티턴 형식으로 합친 전문가 풀이 과정(궤적)의 모음이고, RL-10K는 세 입력 유형을 아우르는 과제 풀에서 구성한 과제들이다. 하나는 '궤적', 다른 하나는 '과제' 단위라 섞어 읽으면 안 된다.

질문에서 대상 이름을 일부러 가린다는데, 왜 그렇게 하나?

질문에 대상 이름이 그대로 노출되면 모델이 시각 입력을 보지 않고도 답할 수 있다. 그래서 데이터 엔진은 명시적 이름 언급을 '시각적으로 가리키는 참조'로 바꿔 쓰고, 텍스트만으로 자신 있게 답할 수 있는 문항은 따로 제거한다. 시각 입력을 반드시 거치게 만드는 장치다.

성능이 외부 웹 검색에 의존하는데, 시점에 따라 흔들리지 않나?

그럴 수 있다. 웹 검색·이미지 검색은 외부 웹을 질의하므로, 웹 내용이 바뀌면 결과도 달라질 수 있다. 이 부류 시스템 전반의 구조적 변수다. 재현을 원한다면 평가 시점과 도구 환경을 함께 고정해 기록하는 편이 안전하다.

참고자료

  • 논문: OneSearch-VL: Unified Multimodal Deep Research Agent for Image and Video
  • 저자: Hongyu Li, Manyuan Zhang, Kaituo Feng, Shu Chen, Dian Zheng, Hao Li, Hao Yu, Zhangquan Chen, Zoey Guo, Ray Zhang, Shaofei Huang, Tianrui Hui, Linjiang Huang, Si Liu (소속: BUAA, CUHK, NTU, THU, HFUT)
  • arXiv: https://arxiv.org/abs/2610.12419
  • HuggingFace: https://huggingface.co/papers/2610.12419