
AI 에이전트가 복잡한 질문에 답하려면 단순히 한 번 검색하는 것만으로는 부족합니다. 질문을 여러 단계로 나누고, 필요한 정보를 반복해서 검색한 뒤 결과를 종합하는 다중 홉 검색이 중요해지고 있습니다.
문제는 검색 과정이 복잡해질수록 비용과 지연 시간도 함께 증가한다는 점입니다. 프런티어 모델을 검색 과정마다 반복 호출하면 요청 하나를 처리하는 데 10초 이상이 걸리고 약 0.03달러의 비용이 발생할 수 있습니다.
이런 상황에서 주목받는 접근 방식이 소형 오픈 모델에 검색 작업에 특화된 강화학습 후처리를 적용하는 방법입니다. 제공된 내용에 따르면 Castform으로 강화학습 후처리한 4B 오픈 소스 모델은 GPT-5.6 Sol과 같은 수준의 검색 정확도를 달성하면서 요청 비용을 100분의 1 수준으로 낮추는 것을 목표로 합니다.
이 글에서는 단순 임베딩 검색에서 에이전트 검색으로 발전한 배경부터 Castform과 Neon의 Lakebase Search를 활용한 강화학습 파이프라인, 기업 데이터를 학습 작업으로 전환하는 방법, 대규모 검색 부하와 상태 변경 에이전트를 처리하는 구조까지 살펴보겠습니다.
단일 임베딩 검색에서 에이전트 검색으로 변화
RAG를 구축할 때 가장 널리 사용되는 방법 가운데 하나가 임베딩 기반 검색입니다.
2022년 무렵부터 데이터베이스 업체들이 임베딩 검색을 적극적으로 도입하기 시작했고, 개발자들도 LLM에 필요한 컨텍스트를 제공하기 위해 직접 RAG 파이프라인을 구축했습니다. 이 과정에서 핵심적으로 활용된 방식이 임베딩 유사도 검색입니다.
사용자의 질문을 벡터로 변환하고 관련성이 높은 문서를 찾아 LLM에 전달하는 구조입니다.
하지만 에이전트가 확산되면서 검색 방식에도 변화가 생겼습니다.
복잡한 질문은 한 번의 검색으로 필요한 정보를 모두 찾기 어렵습니다. 따라서 모델이 문제를 여러 단계로 나누고, 필요한 정보를 판단한 뒤 검색하고, 검색 결과를 바탕으로 다시 다음 검색을 수행하는 방식이 등장했습니다.
이를 다중 홉 검색이라고 볼 수 있습니다.
예를 들어 단순한 질문이라면 다음과 같이 처리할 수 있습니다.
질문 → 검색 → 관련 문서 → 답변
반면 복잡한 질문에서는 다음과 같은 흐름이 필요합니다.
질문 → 계획 → 검색 → 결과 분석 → 추가 검색 → 결과 분석 → 최종 답변
즉, 검색 자체가 하나의 작업이 아니라 에이전트가 반복적으로 판단하고 실행하는 과정으로 바뀐 것입니다.
다중 홉 검색의 핵심은 모델과 검색 환경
좋은 검색 에이전트를 만들기 위해서는 모델만 좋아서는 충분하지 않습니다.
두 가지 요소가 함께 필요합니다.
첫 번째는 무엇을 검색할지 판단하는 모델입니다.
두 번째는 필요한 데이터를 실제로 찾아주는 검색 도구와 컨텍스트입니다.
제공된 구조에서 이 역할은 각각 Castform과 Neon의 검색 환경으로 나뉩니다.
Neon과 Search 확장은 에이전트가 필요한 데이터를 찾을 수 있는 환경을 담당하고, Castform은 모델이 검색 도구를 어떻게 사용해야 하는지 학습할 수 있도록 지원합니다.
문제는 여기에서 비용이 발생한다는 것입니다.
다중 홉 검색에서는 모델이 한 번만 호출되는 것이 아니라 검색 과정에서 여러 차례 호출될 수 있습니다. 특히 프런티어 모델을 반복해서 사용하면 요청당 비용과 지연 시간이 빠르게 증가합니다.
제공된 내용에서는 GPT-5.6 Sol을 활용한 일반적인 다중 턴 검색이 종단 간 10초 이상 걸리고 약 0.03달러의 비용이 발생할 수 있다고 설명합니다.
반면 소형 오픈 가중치 모델은 훨씬 저렴하게 사용할 수 있습니다.
하지만 기본 상태에서는 폐쇄형 API 모델보다 성능이 낮을 수 있습니다.
그래서 등장하는 방법이 특정 검색 작업에 맞춘 강화학습 후처리입니다.
작은 오픈 모델에 검색 능력을 학습시키는 Castform
소형 모델의 장점은 비용입니다.
문제는 성능입니다.
모델 자체의 크기를 키우는 대신 특정 작업을 잘하도록 학습시키는 접근이 가능하다면 이야기가 달라집니다.
Castform이 지향하는 방식이 여기에 해당합니다.
Castform은 검색 도구와 보상 함수를 결합해 오픈 소스 모델이 검색 작업을 반복적으로 수행하고, 그 결과에 대한 피드백을 받으면서 검색 능력을 높이도록 합니다.
핵심 구조는 비교적 명확합니다.
- 모델이 질문을 받습니다.
- 검색 도구를 사용해 필요한 정보를 찾습니다.
- 검색 결과를 바탕으로 답변을 만듭니다.
- 보상 함수가 결과를 평가합니다.
- 평가 결과를 바탕으로 모델을 강화합니다.
- 이 과정을 반복하면서 검색 능력을 높입니다.
여기에서 중요한 것은 단순히 정답을 맞혔는지만 평가하는 것이 아닙니다.
검색해야 할 문서를 제대로 찾았는지, 적절한 출처를 인용했는지, 최종 답변이 정확한지를 함께 평가할 수 있습니다.
결국 모델이 단순히 답을 생성하는 능력이 아니라 어떤 정보를 어떻게 찾아야 하는지를 학습하게 만드는 것입니다.
기업 데이터를 강화학습 작업으로 바꾸는 방법
기업에는 이미 AI 학습에 활용할 수 있는 데이터가 상당히 많이 존재합니다.
예를 들면 다음과 같습니다.
- 내부 문서
- 제품 기록
- 지원 문서
- 고객 상호작용
- 위키
- 운영 데이터베이스
문제는 이런 데이터가 그대로 강화학습 데이터셋이 되는 것은 아니라는 점입니다.
강화학습 후처리를 진행하려면 크게 세 가지가 필요합니다.
1. 작업
모델이 수행해야 하는 목표입니다.
예를 들어 기업 지식 베이스에서 사용자의 질문에 대한 답을 찾는 작업을 만들 수 있습니다.
2. 에이전트 실행 환경
모델이 실제로 작업을 수행할 수 있는 도구입니다.
검색 에이전트라면 기업 데이터 말뭉치에서 관련 정보를 찾을 수 있는 검색 도구가 여기에 해당합니다.
3. 보상 함수
모델이 수행한 결과가 얼마나 좋은지를 평가하는 기준입니다.
검색 결과가 올바른지, 출처가 적절한지, 최종 답변이 정확한지를 평가할 수 있습니다.
모델은 도구를 사용해 작업을 수행하고, 보상 함수는 그 결과를 평가합니다. 이후 이 피드백을 활용해 모델이 더 나은 방향으로 학습하도록 만드는 것입니다.
기존에는 기업 데이터를 이러한 학습 작업으로 전환하려면 상당한 데이터 엔지니어링과 수작업 라벨링이 필요했습니다.
Castform이 주목받는 이유도 여기에 있습니다.
기존 기업 말뭉치를 활용해 학습 작업을 만들고, 오픈 소스 모델이 해당 데이터를 검색에 효과적으로 활용하도록 강화학습 반복 과정을 관리하는 구조를 제공하기 때문입니다.
기업 문서에서 질문과 정답을 자동으로 생성
기업의 문서를 학습 작업으로 전환할 때 핵심적인 과정 중 하나가 질문과 정답을 만드는 것입니다.
예를 들어 기업의 여행 관련 규정 문서에 다음과 같은 내용이 있다고 가정해보겠습니다.
Navan으로 예약한 열차 비용을 GitLab 여행 카드로 결제할 수 있고, 일반 객실을 선택해야 하며, 예약은 14일 전에 해야 한다는 내용입니다.
이 문서에서 학습에 필요한 정답 정보를 추출할 수 있습니다.
- 좌석 등급: 일반 객실
- 예약 시점: 14일 전
그리고 이 정보를 바탕으로 모델이 풀어야 할 질문을 만들 수 있습니다.
예를 들어 예약 시점과 좌석 등급을 묻는 질문을 생성하는 방식입니다.
이렇게 만들어진 질문과 정답 데이터에 에이전트가 사용할 검색 도구와 보상 함수를 연결하면 강화학습 실행을 구성할 수 있습니다.
여기서 보상 함수의 역할이 중요합니다.
단순히 최종 답변이 맞는지만 보는 것이 아니라 다음과 같은 능력을 평가할 수 있습니다.
- 올바른 문서 조각을 검색했는가?
- 적절한 출처를 인용했는가?
- 최종 답변이 정확한가?
이렇게 평가 기준을 구성하면 모델은 단순히 그럴듯한 답을 생성하는 것이 아니라 정확한 정보를 검색하고 근거를 제시하는 과정 자체를 학습하게 됩니다.
Neon의 Lakebase Search가 담당하는 전체 파이프라인
Castform의 강화학습 과정은 Neon의 Lakebase Search를 활용해 하나의 환경에서 구성할 수 있습니다.
전체 흐름은 다음과 같습니다.
원본 문서 저장 → 질문·정답 생성 → 강화학습 롤아웃 → 검색 도구 호출 → 모델 학습 → 프로덕션 추론
각 단계에서 Neon 환경을 활용합니다.
원본 문서는 Neon의 Postgres에 저장합니다.
합성 데이터 생성 단계에서는 lakebase_text와 lakebase_vector를 활용해 학습 작업을 작성합니다.
강화학습 과정에서는 각각의 롤아웃이 검색 도구를 호출할 때 Lakebase Search를 사용합니다.
학습이 완료된 모델도 프로덕션 환경에서 동일한 검색 도구를 호출할 수 있습니다.
이 구조의 핵심은 학습과 실제 서비스에서 사용하는 검색 환경을 연결할 수 있다는 점입니다.
즉, 모델을 학습할 때 사용했던 검색 환경과 실제 추론에서 사용하는 검색 환경 사이의 차이를 줄이는 구조로 볼 수 있습니다.
강화학습 과정에서 관측성과 디버깅이 중요한 이유
강화학습에서는 모델이 학습되고 있다는 사실만 확인해서는 충분하지 않습니다.
왜 성능이 좋아졌는지, 혹은 왜 제대로 동작하지 않는지를 확인할 수 있어야 합니다.
Castform에서는 강화학습 실행 중 보상의 변화를 단계별로 확인할 수 있고, 개별 작업과 프롬프트를 살펴보며 모델의 수행 과정을 확인할 수 있습니다.
이를 통해 다음과 같은 문제를 찾아낼 수 있습니다.
- 검색 도구가 제대로 동작하지 않는 문제
- 모델이 잘못된 검색 전략을 사용하는 문제
- 보상 함수의 허점을 모델이 이용하는 보상 해킹 문제
특히 보상 함수는 모델의 학습 방향을 결정하기 때문에 중요합니다.
평가 기준이 잘못 설계되면 모델이 실제로 원하는 능력을 배우는 대신 평가 점수만 높이는 방향으로 움직일 수 있습니다.
따라서 강화학습에서는 모델의 점수뿐 아니라 실제 작업 수행 과정까지 함께 관찰할 필요가 있습니다.
수천 개의 검색 요청이 동시에 발생한다면
검색 에이전트의 학습에서는 또 다른 문제가 발생합니다.
모델 하나가 검색을 한 번 하는 것이 아니라 수천 개의 에이전트 롤아웃이 동시에 실행될 수 있습니다.
각 롤아웃은 충분한 컨텍스트를 확보할 때까지 Lakebase Search를 반복 호출할 수 있습니다.
결국 짧은 시간에 검색 요청이 폭발적으로 증가할 수 있습니다.
이런 상황에서는 항상 최대 규모의 데이터베이스 컴퓨팅 자원을 확보해두는 방식보다 필요할 때 컴퓨팅 자원을 늘리고 사용량이 줄어들면 다시 축소하는 방식이 효율적일 수 있습니다.
Neon의 동적 컴퓨팅 확장은 이러한 급격한 검색 부하를 처리하는 역할을 합니다.
수요가 증가하면 낮은 지연 시간으로 검색을 처리하고, 유휴 상태에서는 컴퓨팅 자원을 축소하는 구조입니다.
즉, 강화학습 과정에서 발생하는 일시적인 검색 부하를 위해 평소부터 최대 용량을 유지할 필요를 줄이는 접근입니다.
상태를 변경하는 에이전트에는 격리 환경이 필요하다
검색만 하는 에이전트라면 비교적 단순합니다.
하지만 에이전트가 데이터까지 변경하기 시작하면 문제가 달라집니다.
예를 들어 여러 에이전트가 동시에 학습하면서 데이터의 상태를 변경한다면 한 롤아웃에서 발생한 작업이 다른 롤아웃에 영향을 미칠 수 있습니다.
더 중요한 문제는 학습 중인 에이전트가 실제 프로덕션 데이터에 영향을 주어서는 안 된다는 것입니다.
따라서 각 롤아웃마다 독립적인 데이터베이스 상태를 제공할 수 있는 격리 환경이 필요합니다.
Neon branching은 이러한 상황에서 롤아웃별로 격리된 데이터베이스 상태를 제공할 수 있습니다.
또한 시간 여행 쿼리를 활용하면 에이전트가 특정 시점에 접했던 데이터 상태를 다시 구성하고 확인할 수 있습니다.
여기에 브랜칭과 자동 확장, 제로 스케일링을 결합하면 수천 개의 환경을 계속 실행하지 않고도 대규모 상태 유지형 에이전트 롤아웃을 학습시키는 구조를 만들 수 있습니다.
검색 에이전트의 핵심은 더 큰 모델만이 아니다
이번 사례에서 주목할 부분은 단순히 작은 모델이 큰 모델보다 좋다는 이야기가 아닙니다.
핵심은 특정 작업에 필요한 능력을 모델에 학습시킬 수 있다는 점입니다.
프런티어 모델을 반복 호출하는 방식은 높은 성능을 제공할 수 있지만, 다중 홉 검색이 복잡해질수록 호출 횟수와 비용, 지연 시간이 함께 증가할 수 있습니다.
반대로 소형 오픈 모델은 기본 성능이 부족할 수 있지만 특정 검색 작업에 맞춰 강화학습 후처리를 적용하면 비용을 크게 낮추면서 높은 검색 성능을 목표로 할 수 있습니다.
이 과정에서 기업이 보유한 데이터도 중요한 역할을 합니다.
내부 문서와 제품 기록, 지원 자료, 고객 상호작용, 위키, 운영 데이터베이스 등은 단순한 저장 데이터가 아니라 에이전트가 실제 업무를 수행하는 데 필요한 지식이 될 수 있습니다.
이를 질문과 정답, 검색 도구, 보상 함수가 결합된 학습 작업으로 전환한다면 기업의 데이터 자체가 AI 에이전트의 검색 능력을 높이는 학습 자원으로 활용될 수 있습니다.
AI 검색은 단순히 관련 문서 하나를 찾아주는 단계에서 여러 번 계획하고 검색하며 결과를 조합하는 에이전트 검색으로 발전하고 있습니다.
하지만 검색 단계가 늘어나면 프런티어 모델의 반복 호출로 인해 비용과 지연 시간이 함께 커질 수 있습니다.
Castform과 Neon이 제시하는 접근 방식은 이러한 문제를 소형 오픈 모델의 강화학습 후처리와 검색 인프라의 결합으로 풀어가는 데 초점을 맞춥니다.
구조를 정리하면 다음과 같습니다.
기업 데이터 → 질문·정답 합성 → 검색 도구 구성 → 보상 함수 설계 → 강화학습 → 검색 특화 모델 → 프로덕션 추론
여기에 Neon의 동적 컴퓨팅 확장을 적용하면 학습 과정에서 갑자기 증가하는 검색 부하에 대응할 수 있고, branching과 시간 여행 쿼리를 활용하면 상태를 변경하는 에이전트도 격리된 환경에서 학습할 수 있습니다.
결국 중요한 변화는 모델의 크기만으로 AI 검색 성능을 높이는 접근에서 벗어나 데이터, 검색 도구, 보상 함수, 학습 환경을 함께 설계해 특정 업무에 최적화된 모델을 만드는 방향으로 확장되고 있다는 점입니다.
특히 기업이 이미 보유한 내부 데이터를 AI 에이전트의 학습 자원으로 활용할 수 있다는 점은 의미가 있습니다. 고가의 프런티어 모델을 모든 검색 과정에서 반복 호출하는 대신, 업무에 맞춰 학습한 오픈 모델을 활용한다면 검색 비용과 지연 시간을 낮추면서도 필요한 검색 능력을 확보하는 새로운 선택지가 될 수 있기 때문입니다.
앞으로 검색 에이전트가 단순한 RAG를 넘어 복잡한 업무를 직접 수행하는 방향으로 발전할수록, 어떤 모델을 선택하느냐뿐만 아니라 어떤 데이터를 학습시키고, 어떤 도구를 제공하며, 무엇을 보상할 것인지를 설계하는 역량이 더욱 중요해질 것으로 보입니다.
https://neon.com/blog/how-castform-neon-beats-frontier-models-on-price-and-efficiency
Training 100x Cheaper Retrieval models Neon and Castform - Neon
A 4B open-source model post-trained with Castform retrieved search results as accurately as GPT-5.6 Sol, while costing 100x less.
neon.com

'인공지능' 카테고리의 다른 글
| 생성형 AI와 소프트웨어 엔지니어링에 대한 8가지 오해, 개발 생산성의 진짜 의미 (0) | 2026.08.07 |
|---|---|
| Seedance 2.5·MiniMax H3 영상 생성 모델 비교, 같은 프롬프트에서 드러난 결과 차이 (0) | 2026.08.07 |
| Uber 검색 플랫폼의 진화: Elasticsearch에서 OpenSearch까지 (0) | 2026.08.07 |
| Qwen3.8-Max, 16일 동안 스스로 코딩했다: 265개 커밋이 보여준 AI 자율 개발의 현재 (0) | 2026.08.07 |
| Muse Code와 Muse Spark 1.2 공개, 장시간 복잡한 개발 작업을 수행하는 AI 코딩 에이전트 (0) | 2026.08.06 |