12 분 소요

0. Introduction

Paper link

Code link

Model link

한 줄 요약: Harness-1은 20B search agent를 stateful retrieval harness 안에서 RL로 학습해, candidate pool, curated evidence, evidence links, verification records, budget-aware context rendering 같은 recoverable bookkeeping은 harness가 맡고, policy는 search, inspect, curate, verify, stop 같은 semantic decision에 집중하게 만든 논문이다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

  • Agent 성능을 model capacity만이 아니라, model이 상호작용하는 environment contract 관점에서 분석한다.
  • Long-horizon search agent에서 transcript가 곧 memory가 되는 설계의 한계를 직접 겨냥한다.
  • RAG, Deep Research, enterprise search agent를 만들 때 필요한 state schema, evidence curation, verification interface를 꽤 구체적으로 보여준다.
  • 20B급 open search agent로, code와 model checkpoint가 같이 공개되어 실험 재현과 변형의 출발점으로 쓰기 좋다.
  • 단순 answer accuracy보다 curated recall, trajectory recall, precision 같은 search subagent 지표를 전면에 둔다.

Harness-1은 “더 긴 context를 넣으면 agent가 알아서 잘 기억할 것”이라는 방향과 조금 다르다. 이 논문은 search 과정에서 반복적으로 생기는 state, 예를 들면 어떤 문서를 봤는지, 어떤 evidence가 curated set에 들어갔는지, 어떤 link가 어떤 claim을 지지하는지, 어떤 후보가 이미 rejected 되었는지를 model hidden state나 growing transcript 안에만 두지 않는다. 대신 harness가 명시적인 외부 작업 공간을 관리하고, model policy는 다음에 무엇을 검색하고, 무엇을 읽고, 무엇을 evidence로 채택하고, 언제 검증하고, 언제 멈출지를 결정한다.

이 논문의 핵심은 “agent를 더 똑똑하게 만든다”보다 “agent가 학습하는 작업 환경을 더 구조화한다”에 가깝다. 특히 RL로 search agent를 학습할 때, policy가 배워야 하는 것은 raw transcript 관리가 아니라 search strategy와 evidence decision이어야 한다는 관점이 중요하다.

1. Problem Setting

1-1. Problem definition

Harness-1이 다루는 문제는 long-horizon retrieval task에서 search agent가 query, document inspection, evidence selection, verification을 여러 turn에 걸쳐 수행하고, 마지막에 answer에 필요한 evidence set을 잘 구성하는 것이다.

좀 더 구체적으로 보면 agent는 매 step마다 다음과 같은 decision을 해야 한다.

  • 어떤 query를 던질 것인가.
  • 어떤 retrieved document를 열어볼 것인가.
  • 어떤 sentence나 passage를 evidence로 curate할 것인가.
  • 어떤 evidence가 중복이거나 약한지 제거할 것인가.
  • 어떤 claim이나 evidence link를 verify할 것인가.
  • 더 검색할지, 현재 evidence set으로 멈출지 결정할 것인가.

이 문제는 일반적인 QA와 다르다. 최종 답을 맞히는 것만으로는 충분하지 않고, 최종 답을 지지하는 evidence를 얼마나 잘 찾아서 보존했는지가 중요하다. 그래서 Harness-1은 curated recall, final answer recall, trajectory recall, precision 같은 retrieval-centric metric을 사용한다.

간단히 쓰면 다음과 같은 구조다.

\[policy(state_t) -> action_t\]

여기서 중요한 점은 $state_t$를 단순히 transcript token sequence로 보지 않는다는 것이다. Harness-1에서 $state_t$는 candidate pool, curated evidence set, evidence links, verification records, context budget 상태를 포함하는 structured workspace에 가깝다.

1-2. Why previous approaches are insufficient

기존 search agent는 많은 경우 transcript가 사실상 memory 역할을 한다. Agent가 검색하고, 문서를 읽고, 요약하고, 다시 검색하는 모든 과정이 계속 prompt에 쌓인다. 이 접근은 구현이 단순하지만 long-horizon setting에서는 몇 가지 문제가 생긴다.

  1. Bookkeeping burden이 model에 과하게 들어간다.

    어떤 문서를 이미 봤는지, 어떤 evidence가 strong한지, 어떤 후보가 duplicate인지, 어떤 출처가 어떤 claim을 지지하는지를 model이 text로 계속 기억해야 한다. 이는 reasoning 문제라기보다 state management 문제에 가깝다.

  2. Context budget이 search quality와 충돌한다.

    Transcript가 길어질수록 중요한 observation이 뒤섞이고, context window 안에 무엇을 남길지 결정하는 문제가 생긴다. Long context model을 쓰더라도 state가 구조화되지 않으면 attention budget과 retrieval decision이 계속 충돌한다.

  3. RL이 불필요한 일을 같이 배운다.

    RL로 agent를 학습할 때 policy가 search strategy만 배우는 것이 아니라, prompt 안에서 state를 어떻게 유지할지까지 같이 배워야 한다. Harness-1 관점에서는 이 중 일부는 environment가 확정적으로 처리하는 편이 낫다.

  4. Evidence provenance가 약해진다.

    Search agent가 어떤 evidence를 왜 채택했는지, 어떤 claim과 어떤 source가 연결되는지 명시적으로 남기지 않으면, 최종 답은 맞아도 검증 가능한 연구용 또는 서비스용 pipeline으로 쓰기 어렵다.

2. Core Idea

2-1. Main contribution

Harness-1의 핵심 기여는 state-externalizing harness다. 즉, agent의 search state 중 recoverable하고 structured하게 관리할 수 있는 부분을 model transcript 밖으로 빼고, harness가 이를 관리한다.

논문이 제안하는 방향은 다음 네 가지로 요약할 수 있다.

  1. State를 transcript 안에 숨기지 않는다.

    Candidate documents, curated evidence, evidence links, verification records를 harness state로 관리한다. Model은 이 state를 직접 raw text로 다 기억하지 않아도 된다.

  2. Policy는 semantic action에 집중한다.

    Model이 해야 하는 일은 다음 search query를 고르거나, 어떤 document를 inspect할지 선택하거나, 어떤 evidence를 curate할지 결정하는 것이다. 반대로 state update, duplicate tracking, budget-aware rendering은 harness가 맡는다.

  3. RL은 structured workspace 위에서 진행된다.

    Agent는 harness와 상호작용하며 action을 선택하고, retrieval quality와 evidence curation quality에 맞춰 학습된다. 이때 학습 대상은 model alone이 아니라 model plus harness interaction이다.

  4. Evaluation은 answer뿐 아니라 evidence curation을 본다.

    Harness-1은 curated recall을 핵심 지표로 보고, final evidence set이 gold evidence를 얼마나 포함하는지 평가한다. 이는 search subagent를 평가하기에 answer-only metric보다 더 직접적이다.

2-2. Design intuition

Harness-1의 설계 직관은 간단하다. Search agent가 실패하는 이유 중 상당수는 “모델이 몰라서”가 아니라 “작업 공간이 정리되지 않아서”일 수 있다.

Layer Transcript-only agent Harness-1
Search decision Model이 query와 next action을 모두 결정 Model policy가 semantic action을 결정
Candidate tracking Prompt 안에 암묵적으로 누적 Harness state의 candidate pool로 관리
Evidence curation Model이 text로 기억하고 재요약 Curated evidence set으로 명시 관리
Evidence provenance Source와 claim 연결이 약해질 수 있음 Evidence links와 verification records로 보존
Context budget Growing transcript를 계속 압축해야 함 Budget-aware context rendering으로 제어
RL target Reasoning plus bookkeeping이 섞임 Search strategy와 curation decision에 집중

이 관점은 software engineering의 separation of concerns와 비슷하다. Agent policy가 잘해야 하는 일과 harness가 deterministic하게 처리할 일을 분리한다. 잘 분리되면 policy는 더 작아도 되고, trajectory는 더 길어질 수 있으며, evaluation도 더 해석 가능해진다.

3. Architecture / Method

3-1. Overview

Item Description
Method Harness-1
Target Long-horizon search agent and retrieval subagent
Base scale Paper 기준 20B search agent
Public model Hugging Face checkpoint로 공개된 merged model
Key environment Stateful retrieval harness
Main state Candidate pool, curated evidence, evidence links, verification records
Main actions Search, inspect, curate, verify, stop
Main metric Curated recall, final answer recall, trajectory recall, precision
Main claim Structured harness와 RL을 결합하면 20B급 open search agent도 강한 retrieval 성능을 낼 수 있음

Harness-1을 model architecture 논문으로만 보면 핵심을 놓치기 쉽다. 이 논문에서 중요한 것은 Transformer block을 바꾸는 것이 아니라, agent가 interaction하는 external state machine을 바꾸는 것이다.

논문과 공개 repository 기준으로 Harness-1의 큰 흐름은 다음과 같다.

  1. User question이 들어온다.
  2. Harness가 현재 search state를 budget-aware하게 render한다.
  3. Model policy가 next action을 출력한다.
  4. Harness가 action을 실행하고 state를 갱신한다.
  5. Candidate documents, curated evidence, evidence links, verification records가 축적된다.
  6. Stop action 이후 final curated evidence set과 answer 관련 metric을 평가한다.

3-2. Module breakdown

1) Stateful retrieval harness

Stateful retrieval harness는 Harness-1의 중심 모듈이다. 이 harness는 검색 trajectory에서 반복적으로 등장하는 구조적 정보를 model 밖에서 관리한다.

대표적으로 다음 정보를 관리한다.

  • Candidate documents: 검색 결과로 발견된 후보 문서 목록.
  • Curated evidence: 현재까지 answer를 지지한다고 판단한 evidence set.
  • Evidence links: evidence가 어떤 claim 또는 answer component와 연결되는지 나타내는 link.
  • Verification records: evidence나 claim에 대한 검증 결과.
  • Context budget metadata: 다음 step에서 model에 어떤 상태를 보여줄지 결정하기 위한 budget 정보.

중요한 점은 harness state가 단순 cache가 아니라 agent action의 대상이라는 것이다. Agent는 이 state를 보고 다음 action을 선택하고, action은 다시 state를 바꾼다.

2) Search and inspect interface

Search agent는 query를 만들고 retrieval backend를 통해 후보 문서를 얻는다. 이후 어떤 문서를 inspect할지 결정한다. Transcript-only agent에서는 검색 결과 전체가 prompt에 붙거나 요약으로만 남는 경우가 많지만, Harness-1에서는 후보 문서가 candidate pool에 들어가고 이후 selection 대상이 된다.

이 구조는 two-stage retrieval과 비슷해 보일 수 있지만, 차이는 agent가 여러 turn 동안 candidate pool을 갱신하고 evidence를 curate한다는 점이다. 즉, one-shot retriever가 아니라 stateful search policy다.

3) Evidence curation

Curated evidence는 Harness-1 평가에서 핵심이다. Search agent의 목표가 “답을 생성하는 것”에만 있다면 좋은 evidence를 찾고도 최종 답에 제대로 반영하지 못하는 경우를 놓칠 수 있다. 반대로 curated evidence를 별도 object로 관리하면, search subagent가 실제로 필요한 근거를 찾았는지 더 직접적으로 평가할 수 있다.

Harness-1은 final curated evidence set이 gold evidence를 얼마나 포함하는지 보는 curated recall을 중요하게 둔다. 이 지표는 agent가 final answer를 생성하기 전에 retrieval subtask를 얼마나 잘 수행했는지 보여준다.

4) Verification records

Verification records는 evidence가 단순히 모였는지뿐 아니라, 그 evidence가 어떤 claim을 지지하는지, 중복인지, 충분한지 확인하는 과정을 구조화한다. 공개 repository 문서에서도 verify tool과 evidence graph, content dedup, sentence compression 같은 operating point가 언급된다.

실무적으로는 이 부분이 특히 중요하다. Search agent를 서비스에 붙일 때는 “정답처럼 보이는 문장”보다 “어떤 근거가 어떤 결론을 지지하는지”가 더 중요할 때가 많다. Verification record가 없으면 debugging과 audit이 어렵다.

5) Budget-aware context rendering

Harness가 모든 state를 가지고 있더라도 model에 매번 모든 것을 보여줄 수는 없다. 그래서 현재 turn에서 필요한 state를 context budget에 맞춰 render하는 과정이 필요하다.

Harness-1의 공개 실행 설정에는 sentence compression, content deduplication, token budget marker, curated state rendering 같은 요소가 포함된다. 이는 agent에게 external memory가 생겼다고 해서 context problem이 사라지는 것이 아니라, memory를 어떻게 보여줄지가 새로운 설계 문제가 된다는 점을 보여준다.

4. Training / Data / Recipe

4-1. Data

논문 abstract는 Harness-1을 eight retrieval benchmarks에서 평가했다고 설명한다. Benchmark는 web, finance, patents, multi-hop QA 같은 다양한 retrieval setting을 포함한다.

공개 GitHub 문서 기준으로 완전히 즉시 재현 가능한 public path는 BrowseComp+ 중심으로 보인다. BrowseComp+ 실행에는 local query, qrel, answer 파일과 Chroma collection이 필요하며, 다른 in-domain corpus나 ready-made index는 모두 bundled 형태로 제공되지 않는다. 따라서 논문 수치를 그대로 재현하려면 repository의 공개 코드만 보는 것보다 data/index 준비 조건을 같이 확인해야 한다.

정리하면 데이터 관점에서 중요한 점은 다음과 같다.

Aspect Note
Evaluation scope Web, finance, patents, multi-hop QA 등 8개 retrieval benchmark
Public eval path BrowseComp+ 중심 guide 제공
Retrieval backend Chroma 기반 local collection 사용
Non-public dependency 일부 in-domain corpus와 ready-made index는 bundled 형태로 제공되지 않음
Practical implication 논문 수치 재현에는 model뿐 아니라 index, backend, reranker, hardware 조건이 중요함

4-2. Training strategy

Harness-1은 stateful search harness 안에서 RL로 search agent를 학습한다. 여기서 RL의 대상은 단순 language modeling continuation이 아니라, search environment에서 어떤 action sequence를 선택할지에 대한 policy다.

Agent가 학습하는 decision은 대략 다음과 같다.

  • Search query를 어떻게 reformulate할지.
  • 어떤 retrieved document를 inspect할지.
  • 어떤 passage를 curated evidence로 올릴지.
  • 어떤 evidence를 제거하거나 유지할지.
  • 어떤 verification step을 실행할지.
  • 언제 search를 중단할지.

이때 harness는 state update와 rendering을 담당한다. 따라서 RL은 raw transcript를 직접 관리하는 policy보다 더 구조화된 action/state space에서 진행된다.

수식으로 쓰면 다음처럼 볼 수 있다.

\[state_{t+1} = Harness(state_t, action_t)\] \[action_t = Policy(render(state_t))\]

이 두 줄이 Harness-1의 설계 철학을 잘 보여준다. Model은 render된 state를 보고 action을 고르고, harness는 그 action을 구조적 state update로 변환한다.

4-3. Engineering notes

공개 repository 기준으로 Harness-1은 단순 paper artifact보다 engineering surface가 넓다. Model serving, Chroma retrieval, vLLM, evaluation runner, query/qrel files, optional reranker, API credentials가 맞물린다.

실제로 재사용하려면 다음 포인트를 먼저 확인하는 편이 좋다.

  1. Model serving

    Hugging Face model card는 Harness-1 checkpoint가 standard Hugging Face safetensors 형태로 공개되어 있고, base가 openai/gpt-oss-20b 쪽으로 merged되어 있다고 설명한다. Serving은 vLLM 기반 guide가 제공된다.

  2. Retrieval index

    BrowseComp+ 실행에는 Chroma collection이 필요하다. Public guide는 local Chroma path를 전제로 한다. 즉, model weight만 받아서는 논문 평가를 그대로 실행할 수 없다.

  3. Evaluation variance

    Repository 문서는 Chroma backend, reranker availability, GPU kernels, context budget, model serving setting에 따라 결과가 달라질 수 있다고 설명한다.

  4. Harness configuration

    공개 guide에는 subtractive curation, importance tagging, auto-populate, evidence graph, sentence compression, content deduplication, verify tool, token budget marker, max turns 같은 operating point가 언급된다. 이 조합은 model 성능 못지않게 중요하다.

5. Evaluation

5-1. Main results

논문 abstract 기준으로 Harness-1은 8개 retrieval benchmark에서 average curated recall 0.730을 보고한다. 또한 next strongest open search subagent 대비 11.4 point 개선을 보고한다.

Result Value Interpretation
Model scale 20B search agent Frontier-scale closed model이 아닌 open 20B급 agent
Benchmarks 8 retrieval benchmarks Web, finance, patents, multi-hop QA 등 다양한 retrieval setting
Average curated recall 0.730 Final curated evidence set이 gold evidence를 얼마나 포함하는지
Gain over next strongest open search subagent +11.4 points Open search subagent baseline 대비 curated recall 개선
Public artifact Code and model checkpoint Reuse와 inspection이 가능한 release

여기서 중요한 것은 benchmark 수치 자체보다 curated recall이라는 지표 선택이다. Harness-1은 final answer를 직접 생성하는 end-to-end assistant라기보다 retrieval subagent에 가깝다. 따라서 answer accuracy보다 “필요한 evidence를 최종 curated set에 얼마나 잘 넣었는가”가 더 정직한 평가 축이다.

5-2. What really matters in the experiments

1) Curated recall이 핵심이다

Curated recall은 final answer가 맞았는지보다 search subagent가 필요한 evidence를 모았는지를 본다. 이는 Deep Research류 agent에서 중요한 분리다. 최종 답 생성기는 나중에 바꿀 수 있지만, evidence retrieval stage가 빈약하면 전체 pipeline이 무너진다.

2) Transfer result가 중요하다

논문과 공개 요약은 Harness-1이 다양한 domain에서 평가되었고, held-out setting에서도 강한 transfer를 보인다고 설명한다. 이 점은 harness가 특정 benchmark trick이 아니라 search procedure 자체를 구조화했을 가능성을 보여준다.

3) Ablation은 method의 설계 증거다

Harness-1의 주장은 “harness가 있으면 편하다”가 아니라 “harness를 state-externalizing 방식으로 설계하고 RL이 이를 사용하게 만들면 recall이 오른다”이다. 따라서 ablation에서 curation, verification, context rendering 같은 harness mechanism을 제거했을 때 성능이 어떻게 변하는지가 핵심이다. 정확한 ablation 수치는 원문 table에서 최종 확인이 필요하다.

4) Frontier 비교는 조심해서 읽어야 한다

논문은 20B agent가 much larger frontier searcher와 비교 가능한 성능을 보인다고 주장한다. 다만 이 비교는 search subagent, benchmark, harness setting, metric 정의가 맞물린 결과다. 일반 chatbot 능력이나 모든 deep research workflow를 대체한다는 의미로 읽으면 안 된다.

5) Reproducibility는 model weight보다 넓다

Harness-1은 model weight와 code를 공개했지만, retrieval benchmark를 완전히 재현하려면 index, corpus, reranker, backend, hardware setting이 같이 맞아야 한다. 특히 repository 문서가 언급하는 Chroma variance와 GPU kernel variance는 실제 수치 비교에서 주의해야 한다.

6. Limitations

  1. Harness-dependent performance

    Harness-1의 성능은 model alone의 능력으로 보기 어렵다. Model과 harness가 결합된 system의 성능이다. 따라서 다른 product environment에 그대로 넣으면 같은 성능이 나온다고 단정하기 어렵다.

  2. Public reproducibility gap

    Code와 model은 공개되어 있지만, 모든 evaluation corpus와 ready-made index가 bundled 형태로 제공되는 것은 아니다. BrowseComp+ 중심 public path와 논문 전체 benchmark 재현 사이에는 차이가 있다.

  3. Metric scope

    Curated recall은 retrieval subagent 평가에 좋지만, 최종 사용자 answer quality를 모두 설명하지는 않는다. Evidence를 잘 모아도 final synthesis, contradiction handling, citation formatting은 별도 문제다.

  4. Environment complexity

    State를 externalize하면 model 부담은 줄어들 수 있지만, harness engineering 부담은 커진다. Evidence schema, dedup policy, verification record, context rendering policy를 잘못 설계하면 오히려 system failure mode가 복잡해질 수 있다.

  5. Domain and backend sensitivity

    Search backend, corpus quality, reranker, chunking, Chroma index setting에 따라 결과가 달라질 수 있다. 특히 enterprise search 환경에서는 document permission, freshness, metadata quality가 추가 변수다.

  6. Verification is not full truth guarantee

    Verification record가 있다고 해서 final answer가 항상 사실이라는 뜻은 아니다. Verification은 evidence와 claim의 연결을 더 명시적으로 만들지만, source 자체가 틀렸거나 gold label이 불완전한 경우는 여전히 남는다.

7. My Take

7-1. Why this matters for my work

Harness-1은 agent RL을 볼 때 model architecture나 reward만 보면 안 된다는 점을 잘 보여준다. 실제 agent system에서는 environment, tool interface, state schema, logging, verification contract가 학습 가능한 behavior의 상당 부분을 결정한다.

특히 검색 기반 agent를 서비스에 넣는다면 다음 질문이 중요하다.

  • Agent가 본 문서와 버린 문서를 어디에 기록할 것인가.
  • Evidence와 claim의 link를 어떻게 남길 것인가.
  • Context budget이 부족할 때 어떤 state를 model에 보여줄 것인가.
  • Final answer 이전에 retrieval stage를 어떻게 독립 평가할 것인가.
  • RL 또는 preference tuning을 한다면 reward가 answer뿐 아니라 evidence quality를 반영하는가.

Harness-1은 이 질문들을 하나의 system design으로 묶어낸다.

7-2. Reuse potential

바로 재사용해볼 만한 아이디어는 다음과 같다.

  1. Evidence board를 먼저 설계한다.

    Search agent를 만들 때 prompt부터 쓰기보다, candidate, evidence, claim, source, verification, rejected reason 같은 schema를 먼저 정의하는 편이 좋다.

  2. Retrieval metric을 answer metric과 분리한다.

    Final answer accuracy만 보면 retrieval stage가 실제로 좋아졌는지 알기 어렵다. Curated recall이나 trajectory recall 같은 intermediate metric이 필요하다.

  3. Verification을 action으로 만든다.

    Verification을 post-processing으로만 두지 말고, agent가 언제 verify할지 결정하게 만드는 설계가 유용하다.

  4. Context rendering을 별도 모듈로 본다.

    External state가 많아질수록 model에 어떤 subset을 보여줄지가 중요해진다. 이는 prompt engineering이 아니라 memory rendering policy 문제다.

  5. Harness를 RL target의 일부로 본다.

    RL agent를 학습할 때 environment가 단순 simulator가 아니라 behavior를 shape하는 interface라는 점을 명시해야 한다.

7-3. Follow-up papers

  • Context-1: Training a Self-Editing Search Agent
  • DeepRetrieval: Hacking Real Search Engines and Retrievers with Large Language Models via Reinforcement Learning
  • Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning
  • BrowseComp and BrowseComp+: hard evidence retrieval benchmark line
  • Papers on agent trajectory evaluation and evidence attribution

8. Summary

  • Harness-1은 search agent의 state를 transcript 안에만 두지 않고 harness로 externalize하는 논문이다.
  • Candidate pool, curated evidence, evidence links, verification records, context rendering을 harness가 명시적으로 관리한다.
  • Policy는 search, inspect, curate, verify, stop 같은 semantic action에 집중한다.
  • 논문은 20B search agent가 8개 retrieval benchmark에서 average curated recall 0.730, next strongest open subagent 대비 +11.4 point를 기록했다고 보고한다.
  • 가장 중요한 메시지는 agent 성능을 model alone이 아니라 model plus harness plus metric design으로 봐야 한다는 점이다.

댓글남기기

참고