DevCode : IT 개발 기술 아카이브

RAG 성능 고도화 — 리랭킹: 검색 결과를 한 번 더 거른다이 글은 RAG 검색 결과의 정확도를 끌어올리는 '리랭킹(문서 후처리)'을 정리한 기록이다. 검색이 1차로 추려준 문서를 더 정교한 기준으로 다시 줄 세우는 단계 — 크로스 인코더와 3단계 깔때기 전략을 다룬다. 책과 Gemini의 도움을 빌려 궁금증을 해소해가며 작성되었다.검색이 끝이 아니다 — 한 번 더 거르는 후처리직전 편에서 희소·밀집·앙상블로 문서를 골라내는 검색 단을 정리했다. 그런데 검색기가 뽑아준 결과를 그대로 LLM에 넘기다 보면 한 가지가 계속 걸린다. 상위에 올라온 문서가 생각보다 질문과 안 맞는 경우가 종종 섞여 있다는 점이다. 검색은 통과했는데 정작 답이 되긴 어려운 문서들이다.이유는 단순하다. 앞 단의 검색 알고리즘은 ..

RAG 성능 고도화 — 검색 알고리즘: 희소·밀집·앙상블이 글은 RAG의 '검색단'을 책으로 공부하며 정리한 기록이다. 키워드로 찾는 희소검색, 뜻으로 찾는 밀집검색, 그리고 둘을 섞는 앙상블까지 — 검색 알고리즘 선택이 RAG 정확도를 어떻게 가르는지 짚는다. 책과 Gemini의 도움을 빌려 궁금증을 해소해가며 쌓았다.키워드냐 의미냐, 아니면 둘 다냐검색 알고리즘이라고 거창하게 부르지만, 하는 일은 단순하다. 사용자가 던진 질문과 내가 가진 참조 문서들을 비교해서 "이 질문에 가장 잘 맞는 문서가 어떤 거냐"를 골라내는 로직이다. 그런데 이 '잘 맞는다'를 무엇으로 판단하느냐에 따라 결과가 완전히 갈린다. 글자가 똑같이 생겼는지를 볼 수도 있고, 글자는 달라도 뜻이 통하는지를 볼 수도 있다. RAG 시..

RAG 성능 고도화 — HyDE, 가상의 답을 지어내 검색하기이 글은 RAG 검색 정확도를 끌어올리는 'HyDE(가상 문서 임베딩)'를 탐구하며 정리한 기록이다. 책과 Gemini의 도움을 빌려 궁금증을 해소해가며 쌓았다.질문을 그대로 검색하지 말고, '답변'을 먼저 지어내서 검색한다앞 글에서 다중 질의로 질문을 여러 갈래로 늘려 검색망을 넓히는 방법을 정리했는데, 같은 '질의 변형' 계열인데도 발상이 완전히 다른 기법이 하나 더 있다. HyDE(Hypothetical Document Embeddings), 우리말로 옮기면 '가상 문서 임베딩'이다. 질문을 더 잘 다듬어서 검색하는 게 아니라, 아예 그 질문에 대한 가상의 답변을 LLM에게 먼저 지어내게 한 다음, 그 답변으로 DB를 서칭하는 방식이다.처..

RAG 성능 고도화 — 질의 변형과 다중 질의 생성이 글은 RAG 검색 단의 정확도를 끌어올리는 '질의 변형'을 직접 적용해보며 정리한 기록이다. 청킹으로 문서를 어떻게 자를지 고민한 데 이어, 이번엔 검색에 들어가는 '질문' 그 자체를 손보는 이야기다. 책과 Gemini의 도움을 빌려 궁금증을 해소해가며 쌓았다.사용자의 질문을 그대로 검색하면, 왜 자꾸 헛소리만 늘어놓을까?RAG를 어느 정도 굴려보고 나서 가장 먼저 부딪힌 벽은, 사람들이 생각보다 질문을 엉성하게 한다는 사실이었다. 검색 단에서 청킹이고 임베딩이고 다 잘 깔아놨는데도 엉뚱한 문서가 올라오길래 한참을 들여다봤더니, 문제의 절반은 시스템이 아니라 입력으로 들어온 질문 그 자체에 있었다.벡터 검색은 단어가 똑같으냐가 아니라 뜻이 비슷하냐를 ..

RAG 성능 고도화 — 청킹 전략 깊게 파기이 글은 RAG 기반 시스템을 실제로 구축하면서 마주쳤던 청킹 전략의 선택 문제를 정리한 내용이다. 책과 Gemini의 도움을 빌려 궁금증을 해소해가며 쌓은 기록이다. 청킹이 왜 필요한가?RAG 시스템을 처음 설계할 때 가장 단순한 접근은 "그냥 문서를 통째로 LLM에 넣어서 처리하면 되지 않나?"라는 생각이 든다. 하지만 실제로 해보면 두 가지 벽에 부딪힌다.첫째는 토큰 한계다. LLM은 한 번에 처리할 수 있는 텍스트 양이 정해져 있어서, 문서가 길면 아예 입력 자체가 불가능하다. 둘째는 정확도 문제다. 설령 들어간다 해도, 방대한 문서 속에서 관련 없는 내용까지 한꺼번에 읽어야 하는 LLM은 핵심을 놓치거나 엉뚱한 부분에 집중하기 쉽다.그래서 문서를 적절한..