#RRF
4개의 포스트
조건이 둘, 셋이 되면 — 질문을 쪼개는 검색과 Jev의 조건별 판정, 한국어 실측 (한국어 검색 스택 10편)
8편이 풀지 못한 숙제가 있었습니다. 'AWS 보안 글', 'Claude Code에서 MCP를 쓰는 글'처럼 두 주제를 모두 만족해야 하는 질문입니다. 이 글은 조건 1개·2개·3개짜리 한국어 질문 52개와 조건 순서만 바꾼 쌍둥이 질문 40개로, 조건이 늘 때 검색이 어떻게 무너지는지와 그것을 어떻게 막는지를 쟀습니다. 질문을 한 번에 임베딩하면 nDCG@10이 조건 1개 0.940에서 2개 0.519, 3개 0.387로 떨어졌습니다. 질문을 조건별로 쪼개 따로 찾고 합치기만 해도 3개에서 0.592로 버텼고, 그 후보를 Jev가 판정하면 2개와 3개 모두 0.725였습니다. Jev는 한 호출에 질문을 여러 개 받으므로 조건마다 따로 물어도 조건 하나당 토큰 90개, 지연 2ms만 늘었고, 어느 조건이 빠졌는지까지 알려 줬습니다. 의외의 발견도 있었습니다. 판정할 문장 자체가 바뀌는 탓에 'Jev 한 질문'이 조건 순서에 가장 민감했고, 조건별로 묻자 그 흔들림이 사라졌습니다. Jev 9,544회 호출에 0.27달러. 인터랙티브 4개와 삽화 7장.
키워드와 의미, 둘 다 쓴다 — BM25·벡터·RRF·리랭커, 논문과 실측으로 보는 하이브리드 검색 (한국어 검색 스택 2편)
원문 메모의 그림은 이랬습니다. BM25와 벡터 검색을 나란히 돌리고, 결과를 RRF로 합치고, 리랭커로 다시 고른다. 이 글은 그 그림의 각 칸을 논문과 실측으로 채웁니다. 2009년 SIGIR의 두 쪽짜리 논문이 제안한 RRF는 점수 대신 등수만 쓰는 단순한 공식인데 왜 통하는지, k=60은 어디서 왔는지, 2023년 TOIS 논문은 왜 '점수 융합이 RRF보다 낫다'고 했는지, 2025년의 '약한 고리' 발견은 무엇인지. 그리고 1편의 한국어 코퍼스로 직접 재 보니, 등가중 RRF는 벡터 단독보다 오히려 나빴고 이유는 BM25가 약한 고리였기 때문이었습니다. 반면 강한 임베딩 둘(Qwen3-8B + BGE-M3)을 RRF로 합치자 어느 쪽 단독보다 좋아졌습니다. 리랭커는 '따로 읽고 비교'하는 바이 인코더와 '같이 읽고 판정'하는 크로스 인코더의 차이로 풀고, 로컬 LLM을 리랭커로 써서 상위 10개의 순서가 얼마나 바뀌는지 잽니다. 인터랙티브 5개와 삽화 8장.
질문마다 다른 검색기, 다른 모델, 다른 예산 — 동적 라우팅과 DRAG (RAG 특집 3편)
HotpotQA 질의의 22%는 BM25만으로 검색해도 정답이 나온다. 가장 비싼 구성이 꼭 필요한 질의는 15.6%다. 그런데 대부분의 RAG는 모든 질의에 같은 검색기와 같은 모델을 쓴다. 2026년 9월 15일 공개된 DRAG는 검색기 4단계 × 생성기 추론 강도를 전부 조합해 잰 뒤 두 가지를 보여 줬다 — 더 강한 검색이 더 많은 추론보다 크게 이기지만 단조롭게 좋아지지는 않는다는 것, 그리고 정답을 아는 오라클 라우터는 최고 정적 구성보다 정확하면서 지연은 절반이라는 것. 이 특집은 1편의 5경로 라우팅을 8경로로 확장하고, 라우터가 경로와 함께 정해야 하는 8가지 결정, 오라클 대비 손실(router regret)을 재는 법, 그리고 같은 날 나온 추론형 임베딩(CoFree)·추론형 재랭커(MERIT-Rank)가 라우터의 선택지를 어떻게 늘렸는지를 위젯 5종으로 따라간다. 결론은 하나다 — 추론형 부품은 맨 위 한 단이고, 대부분의 질의는 아래에서 끝나야 한다.
하루 15,000개의 질문에 답하는 사내 AI — Cerebras는 지식 베이스를 어떻게 만들었나
"그거 어디 있죠?" "이거 누가 담당이죠?" — 회사가 커질수록 정보는 흩어지고, 같은 질문이 반복된다. Cerebras는 Slack·코드·문서를 하나의 임베딩 테이블로 모아 하루 15,000개 질문에 답하는 사내 지식 베이스를 만들었다. 그 안에는 반세기 검색의 역사가 응축돼 있다. 키워드 검색에서 BM25, 임베딩, HNSW, 하이브리드, 그리고 에이전트 검색까지 — 왜 이런 개념들이 하나씩 필요해졌는지, 인터랙티브하게 만져보며 이해한다.