DevCode : IT 개발 기술 아카이브

RAG 성능 고도화 — Self-RAG: 스스로 검열하는 RAG이 글은 Self-RAG를 정리한 기록이다. 검색·생성·평가의 각 단계에 LLM이 개입해 스스로 검열하는 구조를, 라이브러리 없이 작은 루프로 직접 구현해보며 짚는다. 책과 Gemini의 도움을 빌려 궁금증을 해소해가며 쌓았다.일반 RAG의 맹점 — 관련 없어도 일단 답을 만든다검색 알고리즘에 리랭킹까지 얹으면 RAG 성능은 확실히 올라간다. 거기까지는 앞에서 정리한 그대로다. 그런데 이 모든 걸 다 적용해도 끝까지 남는 구조적인 약점이 하나 있다. 전통적인 RAG는 사용자가 문서와 아무 상관 없는 질문을 던져도, 어떻게든 뭔가를 찾아서 답을 만들어내려고 한다는 점이다.일단 가장 비슷해 보이는 문서를 끌어오고, 생성 모델은 그 엉뚱한 자료를 ..

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 시스템을 처음 설계할 때 가장 단순한 접근은 "그냥 문서를 통째로 LLM에 넣어서 처리하면 되지 않나?"라는 생각이 든다. 하지만 실제로 해보면 두 가지 벽에 부딪힌다.첫째는 토큰 한계다. LLM은 한 번에 처리할 수 있는 텍스트 양이 정해져 있어서, 문서가 길면 아예 입력 자체가 불가능하다. 둘째는 정확도 문제다. 설령 들어간다 해도, 방대한 문서 속에서 관련 없는 내용까지 한꺼번에 읽어야 하는 LLM은 핵심을 놓치거나 엉뚱한 부분에 집중하기 쉽다.그래서 문서를 적절한..