100배 저렴한 오픈 모델, 검색에서 GPT-5.6 Sol을 능가하기

“대부분 팀이 보유한 최고의 학습 데이터는 이미 데이터베이스에 잠들어 있음. 문제는 원시 데이터를 쓸 만한 형태로 만들기 어렵고, 에이전트가 대규모로 데이터를 저렴하게 읽고 검색하고 변경하려면 고급 인프라가 필요하다는 점임. Castform을 Neon에 연결하면 두 문제를 모두 건너뛸 수 있음.” Castform 공동 창업자 Ying Hang Seah

• 좋은 에이전트에는 적절한 데이터를 찾는 도구와 검색 대상을 판단하는 모델이 모두 필요함

  • Neon의 Lakebase Postgres와 새 Search 확장 기능이 컨텍스트 제공을 맡고, Castform이 무엇을 검색할지 판단하는 모델을 만듦

에이전트 검색의 변화

• 검색은 임베딩 기반 단발성 RAG에서 모델이 여러 번 계획하고 탐색하는 에이전트형 검색으로 이동함

  • 2022년경에는 데이터베이스 업체들이 임베딩 검색을 앞다퉈 추가했고, pgvector가 Neon에서 가장 많이 다운로드된 확장 기능이 됐으며, 엔지니어들은 임베딩 유사도 검색을 중심으로 RAG 파이프라인을 직접 구축했음

  • 2025년경부터는 큰 문제를 작은 문제로 나누는 multi-hop 검색이 확산됐고, 모델이 한 번 질의하는 대신 반복해서 계획하고 검색하게 됨

    • 반복할 때마다 frontier 모델 호출이 추가돼 사용자 요청당 비용과 지연 시간이 늘어남

• 일반적인 multi-turn 검색은 gpt-5.6-sol에서 10초 넘게 걸리고 전체 비용이 약 $0.03에 달함

  • 작은 open-weights 모델은 비용이 100배 저렴하지만 기본 성능은 closed API 모델보다 뒤처짐

  • RL post-training을 적용하면 검색처럼 범위가 특정된 작업에서 오픈소스 모델도 frontier 모델과 대등하거나 더 나은 성능을 내면서 요청당 비용을 몇 자릿수 낮출 수 있음

• Castform은 머신러닝과 GPU 내부 구현을 다루지 않고도 RL post-training을 수행하도록 만들어짐

  • post-training을 prompt engineering만큼 쉽게 접근할 수 있게 하는 것이 목표임

Neon을 활용하는 학습 파이프라인

• Castform은 학습부터 운영 추론까지 Neon의 Lakebase Search를 일관되게 사용함

이미 보유한 데이터로 만드는 학습 과제

• 효과적인 RL post-training에는 과제, 에이전트 실행 환경, 보상 함수가 필요함

  • 예를 들어 사용자 질문에 답하는 과제, 자체 코퍼스를 탐색하는 검색 도구, 답이 맞는지 판정하는 보상 함수를 함께 구성함

  • 모델이 도구로 과제를 시도하면 보상 함수가 결과를 채점하고, 피드백 신호가 시행착오를 거쳐 성능을 최적점으로 끌어올림

• 기업에는 필요한 지식이 있지만 학습용 과제와 보상 함수로 정리된 데이터셋은 대체로 없음

  • 내부 문서, 제품 기록, 지원 문서, 고객 상호작용, 위키, 운영 데이터베이스에는 에이전트가 사용할 지식이 축적돼 있음

  • 이를 효과적인 학습 데이터셋으로 바꾸려면 보통 상당한 데이터 엔지니어링과 수작업 라벨링이 필요해, 많은 팀이 “학습 데이터가 없다”거나 “fine-tuning은 너무 어렵고 필요한 인프라도 없다”고 판단함

• Castform은 기존 코퍼스에서 과제를 만들고 오픈소스 모델을 가르치는 RL 반복 과정을 관리함

  • 기존 코퍼스를 학습 과제로 변환해 데이터 준비와 학습 인프라 문제를 함께 다룸

Castform 사용 방식

• 회사 지식 베이스의 문서에서 정답과 질문을 생성해 모델 학습 데이터로 바꿀 수 있음

  • 예시 변환 과정은 다음과 같음

    • 문서: Navan으로 예약한 열차는 GitLab 법인 여행 카드로 결제하며, 일반 객실을 이용하고 14일 전에 예약해야 함

    • 정답: 열차는 일반 객실을 이용하고 14일 전에 예약해야 함

    • 합성 질문: Navan에서 철도 여행을 예약할 때 얼마나 일찍 예약해야 하며 어떤 좌석 등급을 선택해야 하는가?

• 생성된 질의응답 데이터셋에 에이전트가 사용할 도구와 보상 함수를 지정해 학습 실행을 구성함

  • 보상 함수는 모델이 익힐 목표를 정의하며, 여기서는 올바른 chunk 검색, 정확한 출처 인용, 올바른 최종 답변을 함께 평가함

def run_tool(tool, tool_args):
    """Single tool: hybrid search over Lakebase."""
    if tool == "search":
        query = tool_args["query"]
        bm25 = neon.lakebase_text(query, k)
        vector = neon.lakebase_vector(query, k)
        return rrf_merge(bm25, vector, k)

def reward(trace, ground_truth):
    """Grade a trace against the ground-truth answer."""
    answer = parse_trace(trace)
    retrieval =... # did it retrieve the right source
    citation =... # did it cite the right chunk
    correctness =... # did it land on the right answer
    return retrieval + citation + correctness

• 전체 구현은 종합 코드 예제에서 확인 가능함

학습 관찰과 디버깅

• Castform은 RL 실행의 보상 변화와 개별 과제·prompt의 수행 과정을 모두 보여줌

  • 단계별 보상 상승을 확인하는 데 그치지 않고 개별 실행을 정성적으로 살펴보며, 고장 난 도구나 reward hacking 같은 문제를 디버깅할 수 있음

  • 자세한 모니터링 방법은 Castform 블로그, 실제 결과는 학습 실행 예제에서 확인 가능함

평균 보상

Neon이 학습 부하를 처리하는 방식

• 수천 개의 병렬 rollout이 각각 수십 차례 검색하면 짧은 시간에 부하가 몰림

  • 에이전트는 답변에 충분한 컨텍스트를 얻을 때까지 Lakebase Search를 반복 호출함

###

• Neon의 동적 컴퓨팅 확장이 최대 부하에 맞춘 상시 프로비저닝 없이 검색량 급증을 흡수함

  • 수요가 치솟을 때는 낮은 지연 시간으로 검색하고, 유휴 시간에는 컴퓨팅 자원이 축소됨

• 에이전트가 검색을 넘어 데이터를 변경하면 저렴하게 만들고 초기화할 수 있는 격리 환경이 필요함

  • 상태를 가진 에이전트를 학습할 때 rollout 하나의 작업이 다른 rollout이나 운영 환경에 영향을 주지 않아야 함

  • Neon branching은 rollout마다 격리된 데이터베이스 상태를 제공하고, time-travel query는 에이전트가 마주한 상태를 재구성하고 조사할 수 있게 함

  • autoscaling과 scale-to-zero를 결합하면 수천 개의 환경을 계속 실행하지 않고도 상태를 가진 에이전트 rollout 수천 개를 학습할 수 있음

^{source https://neon.com/blog/how-castform-neon-beats-frontier-models-on-price-and-efficiency}

HN에서는 검색처럼 범위가 분명하고 반복 호출이 많은 작업에 거대 범용 모델을 계속 써야 하느냐는 문제의식이 두드러졌다. 검색과 재정렬, 추론, 생성을 알맞은 모델에 맡기고 전환 비용을 낮춘다면 작은 특화 모델도 실용적인 선택이 될 수 있다는 시각이다. 문서에서 사실을 찾을 때 작은 모델이 불필요한 추론에 빠지지 않고 지시한 범위에 집중했다는 경험도 나왔다.

그러나 가벼운 모델을 쓰는 것과 특정 작업에 최적화한 모델을 쓰는 일은 구분해야 한다. 작은 모델은 필요한 정보를 놓칠 수 있고, 강한 범용 모델이 같은 작업을 충분히 잘한다면 미세조정과 운영 부담만 늘어날 수 있다. 반복성이 매우 높다면 모델 대신 일반 프로그램으로 처리하는 편이 나을 수도 있다. 중요한 것은 크기가 아니라 검색 대상을 정확히 고르고 결과를 빠짐없이 전달하는 능력이다.

성능 주장에는 검증이 더 필요하다는 반응이 많았다. 널리 쓰이는 검색 벤치마크와 명확한 평가 지표가 보이지 않았고, 더 저렴한 모델이나 실제 처리 속도와의 비교도 빠졌다. 데이터가 커져도 묻힌 정보를 찾아내는지, 첫 단서로 다음 단서를 찾아야 하는 다단계 검색에서도 성능을 유지하는지가 핵심이다. 오래됐거나 잘못된 원천 자료로 보상 기준까지 만들면 기존 오류를 되풀이할 수 있다는 우려도 제기됐다.

실무에서는 동일한 데이터와 과제로 정확도, 누락률, 지연 시간을 직접 비교해야 한다. 여기에 모델 선택과 미세조정 파이프라인의 유지비도 포함해야 한다. 특화 모델의 가치는 단순히 작고 싼 데 있지 않다. 강한 모델의 호출을 줄이면서도 복합 검색에 필요한 맥락과 신뢰도를 지킬 수 있는지가 중요하다.