9월 22일 화요일
오늘의 두 시스템은 더 큰 모델보다 경계를 선명하게 나눈다. 검색은 반복 루프 전체로 평가하고, 빠른 구조화 판단은 추론이 필요 없는 분기점에만 배치해야 한다.
검색 품질은 점수 함수가 아니라 에이전트의 전체 궤적에서 결정된다
BM25를 에이전트 검색의 기반으로 쓸 때 모델, 하니스, 엔진, 작업공간, 평가를 한 시스템으로 묶어 봐야 하는 이유를 구현 관점에서 정리한다.
BM25를 붙인 검색 도구가 아니라, 끝까지 답을 찾아가는 에이전트 검색 시스템을 어떻게 설계하고 검증해야 하는가?
에이전트 검색에서 BM25는 완제품이 아니라 정확한 문자열을 싸고 설명 가능하게 찾는 기본 프리미티브다. 실제 품질은 세 층의 결합에서 나온다. 모델은 엔티티·날짜·식별자 같은 배경지식을 긴 질의와 검색 문법으로 바꾸고, 하니스는 search 호출이나 코드 모드로 검색·파일 읽기·문맥 관리를 노출하며, 엔진은 대규모 문서에서 상위 결과를 효율적으로 반환한다. 에이전트는 결과 스니펫을 읽은 뒤 단서를 추가하거나 표현을 바꿔 다시 질의하므로, 사람의 짧은 단발 검색과 다른 워크로드를 만든다. 이 구조에서 어휘 매칭은 SKU·우편번호·제품 코드·고유명사처럼 한 글자 차이가 중요한 항목을 직접 보존하고, 무엇이 매칭됐는지 다음 질의에 사용할 근거도 제공한다. 다만 ‘BM25를 썼다’는 사실은 품질 보증이 아니다. 인덱싱, 실행 전략, top-K 가속, 하드웨어, 긴 문서 처리, 두 주요 하이퍼파라미터의 선택에 따라 처리량·지연시간·종단간 정확도가 크게 달라진다. 따라서 검색 엔진의 오프라인 순위 점수만 최적화하기보다, 모델이 여러 번 질의하고 증거를 읽어 최종 과업을 끝내는 전체 경로를 제품 단위로 다뤄야 한다.
- 01
질의-읽기-재질의 루프
호출 한 번의 검색 API보다 중요한 것은 궤적이다. 모델은 검색어를 만들고, 반환된 스니펫에서 증거가 충분한지 판단하고, 새 엔티티나 다른 표현을 다음 질의에 반영한다. 종료 조건도 답을 찾았는지, 더 읽을 가치가 있는지, 컨텍스트 한도에 닿았는지로 설계해야 한다. 긴 질의와 site·구문 검색 같은 연산자를 활용할 수 있다는 장점은 호출 횟수와 문맥 소비를 함께 관리할 때만 성능으로 이어진다.
- 02
하니스와 작업공간의 경계
검색 결과를 모두 컨텍스트에 밀어 넣는 대신 제목과 스니펫을 파일시스템형 작업공간에 놓고 가치 있는 문서만 점진적으로 읽게 할 수 있다. grep·ripgrep은 정확 문자열로 범위를 줄이고, sed·awk는 필요한 부분을 추출하며, 셸과 가상 파일시스템은 검색 후보를 코드 에이전트가 익숙한 방식으로 다루게 한다. 검색 엔진의 후보 선별과 모델의 파일 탐색을 분리하면 컨텍스트를 외부화하면서도 도구 사용 능력을 재활용할 수 있다.
- 03
기본 파라미터가 만드는 착시
BrowseComp Plus의 초기 BM25 기준선은 긴 문서 워크로드에 맞지 않는 기본값 때문에 매우 낮은 결과를 냈다. 이런 기준선과 고급 랭커를 비교하면 새 기법의 이득이 과장될 수 있다. 두 주요 하이퍼파라미터가 문서 길이와 용어 빈도를 어떻게 반영하는지 확인하고, 실제 코퍼스의 길이 분포와 에이전트가 만드는 긴 질의에 맞춰 튜닝해야 한다. 엔진 이름이 아니라 구현과 파라미터 조합을 실험 단위로 기록해야 비교가 재현된다.
- 04
평가는 랭킹에서 과업 성공으로
단일 질의의 순위 목록에 NDCG를 계산하는 평가는 여러 질의와 파일 도구를 조합하는 에이전트 동작을 다 담지 못한다. 약 820개 질문과 약 10만~10만 5천 개 웹 문서를 쓰는 BrowseComp Plus의 관찰처럼, 필요한 증거를 문맥에 직접 넣었을 때와 search 도구로 찾아야 할 때의 격차는 모델 추론만이 아니라 하니스·질의 작성·검색 품질의 병목을 드러낸다. 최종 답 정확도나 과업 완료율을 중심에 두고 검색 궤적, 지연시간, 문맥 소비를 함께 측정해야 한다.
구현 순서는 단순하다. 먼저 정확 매칭이 필요한 데이터와 의미 검색이 필요한 데이터를 구분하고, 모델에 노출할 search 인터페이스와 종료 조건을 정한다. 다음으로 결과를 파일형 작업공간에 단계적으로 펼쳐 불필요한 컨텍스트 유입을 막고, BM25 파라미터와 엔진 구현을 실제 긴 문서·긴 질의 분포에서 튜닝한다. 마지막으로 단일 랭킹 점수와 엔진 처리량만 보지 말고, 고정된 과업 묶음에서 최종 정답률·검색 횟수·지연시간·문맥 사용량을 함께 검증한다. 제시된 Hornet 단일 노드 비교도 웹 문서 1억 개와 같은 조건에서 구현 효율을 보여주지만, 세로축 설명이 QPS에서 지연시간으로 정정됐다는 점까지 포함해 수치를 읽어야 한다. 핵심은 오래된 함수를 채택하는 것이 아니라, 더 강한 사용자가 그 함수를 반복적으로 쓰는 전체 시스템을 검증하는 데 있다.
빠른 구조화 판단을 안전한 분기점으로 만드는 다섯 경계
타입이 맞는 JSON과 높은 처리량만으로 자동화가 완성되지는 않는다. 입력 상태, 신뢰도 임계값, 에스컬레이션, 기억의 필요성을 함께 설계해야 한다.
타입 안전한 구조화 결정 모델을 제품에 넣을 때 무엇을 고정하고, 어떤 판단은 더 느린 추론 경로로 넘겨야 하는가?
- 1
1. 입력 상태와 출력 스키마
이 모델은 자유 텍스트를 길게 생성하는 대신 애플리케이션 상태를 받고 정의된 JSON 구조 안에서 다음 선택을 반환한다. 형식이 결정론적이어도 내용은 확률적이므로, 스키마 준수와 판단 정확도를 같은 지표로 취급하면 안 된다. 입력에 필요한 상태가 빠졌다면 올바른 형식의 오답도 가능하다.
- 2
2. 신뢰도와 임계값
각 분류에 0~1 점수를 받고 임계값을 조정하면 자동 처리와 보류의 경계를 운영할 수 있다. 실제 채팅 분류에서 ‘범위 확장’은 80% 기준일 때 22%였지만 90%에서는 6.8%로 줄었다. 임계값은 정확도 장식이 아니라 처리량·누락·사람 검토량을 바꾸는 제품 파라미터다.
- 3
3. 잘 맞는 실행 경로
분류, 정렬, 짧은 랭킹, 모더레이션, 검증처럼 모든 정보가 들어온 뒤 사람이 약 10초 안에 답할 수 있는 문제는 적합성이 높다. 이메일 100개를 워커 8개로 처리한 사례는 평균 200밀리초, P95 240밀리초, 초당 38개를 기록해 고빈도 1차 필터의 경제성을 보여준다.
- 4
4. 장기 상태가 필요한 실패 구역
코드 변경 계획, 여러 모델 답안 심사, 대화 전체 압축처럼 긴 문맥과 인과관계, 도구 결과를 합성해야 하는 문제에는 맞지 않는다. 체커와 Doom 데모에서도 현재 상태에는 빠르게 반응했지만 이전 선택을 기억하지 않아 방향이 진동하거나 장기 계획을 세우지 못했다. 빠른 반사를 계획 능력으로 해석해서는 안 된다.
- 5
5. 실패 시 넘길 다음 경로
낮은 신뢰도, 스키마 밖 상태, 긴 문맥 요구, 판단에 10초 이상 걸리는 문제를 감지하면 범용 모델이나 사람 검토로 넘겨야 한다. 구조화 모델은 하네스를 대체하는 에이전트가 아니라 소프트웨어 내부의 빠른 분기 부품이다. 자동 실행 전에는 임계값별 정밀도와 누락뿐 아니라 에스컬레이션 비용도 함께 측정해야 한다.
배치 위치는 ‘얼마나 똑똑한가’보다 ‘실패를 얼마나 빨리 감지하고 어디로 보낼 수 있는가’로 정해야 한다. 출력 형식 준수, 분류 신뢰도, 임계값별 포함률, 장기 상태 필요 여부를 각각 관측하고, 불확실한 건 자동 실행하지 않는 경로를 둔다. 벤치마크의 큰 속도·가격 차이는 높은 쪽의 이득이며 전문이 공개되지 않았고 참조 답 자체가 틀릴 수 있다는 한계도 남는다. 따라서 제품 적합성은 공개 수치가 아니라 자체 데이터에서의 보정, 실패 분포, 사람 검토 경계로 확인해야 한다.
아직 못 읽은 북마크
북마크를 고르는 중…