아프니까 개발자다 아프니까 개발자다

Context7 분석 시리즈(1) 문서 특화 청킹 전략(2) 코드 스니펫 vs 정보 스니펫(3) 서버 사이드 리랭킹 ← 현재 글(4) 5단계 품질 파이프라인(5) 다층 품질 스코어링RAG의 고질적 문제: 검색 결과가 너무 많다RAG(Retrieval-Augmented Generation)의 기본 흐름은 간단합니다. 질문이 들어오면 벡터 데이터베이스에서 관련 문서를 검색하고, 검색 결과를 LLM의 컨텍스트에 넣어서 답변을 생성하는 방식이죠.문제는 벡터 검색이 "대충 비슷한" 결과를 많이 가져온다는 것입니다. "Next.js 미들웨어 인증"을 검색하면, 정확히 관련된 3개의 청크 외에도 "Next.js 라우팅", "Express 미들웨어", "OAuth 인증 일반론" 같은 약간 관련 있지만 핵심은 아닌 청크..

왜 벡터 검색만으로는 부족한가?"6개월 전에 정리한 Kubernetes 노트"와 "어제 작성한 Kubernetes 노트"가 있다고 합시다. 벡터 유사도(Vector Similarity)만으로 검색하면 둘 다 비슷한 점수를 받습니다. 의미적으로 비슷하니까요. 하지만 실제로는 어제 작성한 노트가 더 가치 있을 가능성이 높습니다.이것이 바로 Multi-Stage Retrieval(다단계 검색)이 필요한 이유입니다. 벡터 검색으로 후보를 넓게 뽑고, 시간 감쇠(Time Decay)로 오래된 문서의 점수를 깎고, 마지막으로 Cross-Encoder로 정밀하게 재순위를 매기는 3단계 파이프라인을 만들면, 단순 벡터 검색보다 훨씬 정확한 결과를 얻을 수 있습니다.실생활 활용 시나리오시나리오 1: 개인 지식 관리 시스..

이 글을 왜 읽어야 하나?RAG(Retrieval-Augmented Generation, 검색 증강 생성)를 공부하다 보면 "Bi-Encoder로 후보를 뽑고 Cross-Encoder로 Reranking한다"는 말을 자주 만납니다. 그런데 둘 다 "두 텍스트가 얼마나 관련 있는지" 점수를 매기는 건데, 왜 하나로 안 되고 굳이 두 개가 필요할까요?이 질문에 답하려면, 이 두 방식이 어떤 근본적인 문제를 풀기 위해 나왔는지부터 이해해야 합니다. 결론부터 말하면, 둘은 같은 문제의 서로 다른 면을 해결합니다. 그래서 둘 다 필요합니다.실생활 비유: 도서관에서 책 찾기비유를 하나 들어보겠습니다.Bi-Encoder는 도서관의 분류 시스템입니다. 모든 책에 미리 분류 번호를 매겨두고, 당신이 원하는 주제의 번호만..