100배 저렴한 오픈 모델로 retrieval에서 GPT-5.6 Sol 겨냥하기 (Neon + Castform)
Beating GPT-5.6 Sol on retrieval with 100x cheaper open models
TL;DR Highlight
Postgres 데이터로 4B 오픈 모델을 RL 후학습해 검색 에이전트 비용을 낮춘다
Who Should Read
멀티턴 검색 에이전트의 비용·지연 때문에 frontier 모델 호출을 줄이고 싶은 백엔드 개발자
Core Mechanics
- 멀티턴 검색은 비싸고 느리다
- 원문은 gpt-5.6-sol로 멀티턴 검색 요청 하나가 end-to-end 10초 넘게 걸리고 약 $0.03라고 쓴다.
- 루프를 돌 때마다 frontier 모델을 다시 호출하기 때문이라고 설명한다.
- 작은 오픈 모델은 100배 싸지만 기본 성능이 모자라다
- 원문은 작은 open-weights 모델이 100x 저렴하다고 한다.
- 기본 상태에서는 closed API 모델보다 성능이 뒤처진다고 한다.
- RL 후학습으로 특정 작업의 격차를 메운다
- RL(강화학습)은 시도하고 점수를 받으며 모델을 개선하는 방식이다.
- 원문은 검색 같은 특정 작업에서 후학습한 오픈 모델이 frontier 모델과 맞먹거나 능가한다고 주장한다.
- 학습에는 태스크·환경·보상 함수 3가지가 필요하다
- 태스크는 질문에 답하기, 환경은 코퍼스용 검색 도구, 보상 함수는 정답 여부 채점이다.
- Castform은 기존 문서에서 질문과 정답을 합성해 태스크를 만들어 준다.
- 보상은 검색·인용·정답 세 가지를 합산한다
- 원문 예시는 올바른 출처를 찾았는지, 올바른 청크를 인용했는지, 정답에 도달했는지를 더한다.
- 검색 도구는 BM25와 벡터 검색 결과를 rrf_merge로 합치는 하이브리드 검색이다.
Community Reactions
- retrieval 접근은 세 갈래라는 의견
- 좋은 retrieval 자체, 생성기·평가기 하니스, retrieval용으로 학습한 모델로 나뉘며 이 글은 세 번째라는 의견이 있었다.
- SID.ai, Glean의 Waldo 모델도 같은 계열이라는 언급이 있었다.
- 비교 대상과 지표가 부족하다는 지적
- Luna나 DSFlash 같은 더 싼 모델과의 비교, 속도 비교가 없다는 의견이 있었다.
- browsecomp plus 같은 공통 벤치마크와 보고 지표가 없어 의심스럽다는 의견도 있었다.
- 작은 모델이 문서 사실 검색에서 더 나았다는 경험
- 직접 테스트해 보니 작은 모델이 큰 모델보다 낫더라는 댓글이 있었다.
- 큰 모델이 과하게 생각해서일 것이라는 추측이었고, 큰 데이터셋으로 검증하진 않았다고 한다.
- 데이터 민감도와 코퍼스 품질 우려
- 민감한 데이터를 클라우드에 올릴 수 없어 렌탈 GPU와 오픈소스로 할 수 있는지 묻는 댓글이 있었다.
- 코퍼스에 오래되거나 틀린 내용이 많으면 코퍼스로 만든 보상 함수가 어떻게 되는지 묻는 댓글도 있었다.
How to Apply
- 지금 쓰는 에이전트 검색 호출의 비용과 지연부터 재기
- 오늘 멀티턴 검색 요청 20건을 골라 호출 횟수, 총 지연, 비용을 로그로 뽑는다.
- 요청당 10초·$0.03 수준과 비교해 후학습 후보인지 판단한다.
- 하이브리드 검색 도구를 에이전트 도구 하나로 묶기
- BM25 결과와 벡터 검색 결과를 RRF(순위 합치기)로 합쳐 search 도구 하나로 노출한다.
- 학습 때와 추론 때 같은 도구를 쓰도록 맞춘다.
- 사내 문서에서 질문·정답 쌍을 만들어 보상 함수 초안 쓰기
- 문서 한 조각마다 질문과 정답을 LLM으로 생성해 검증 세트를 만든다.
- 출처 검색, 인용, 정답 세 항목을 합산하는 채점 함수를 작성한다.
Try It
# Claude나 ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 합성 QA와 보상 채점 설계)
아래 문서 조각들로 검색 에이전트 평가용 데이터를 만들어 줘.
{{문서}}
각 조각마다 다음 JSON을 만들어 줘.
- question: 문서를 보지 않은 사람이 물을 법한 질문. 문서 표현을 그대로 쓰지 말 것
- ground_truth: 문서에 근거한 한 문장 정답
- source_id: 근거가 된 조각 번호
그다음 채점 기준을 만들어 줘. 점수는 retrieval(올바른 출처를 찾았나), citation(올바른 청크를 인용했나), correctness(정답에 도달했나)를 각 0 또는 1로 매기고 합산한다.
이어서 해 볼 것: 지금 쓰는 에이전트의 답변 10개를 이 기준으로 채점해 달라고 하고, 점수가 낮은 질문의 공통점을 정리해 달라고 해 봐.Terminology
관련 논문
같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나
긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복
가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격
가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)
Harness Engineering 101: LLM은 뇌, harness는 몸
에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다
Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크
모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다
해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유
경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다
tmux와 Claude Code: 세션, send-keys, 그리고 한계선
tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다
Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트
잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓