5강. 검색(Search)은 RAG의 보조가 아니라 핵심이다

🤔 Question

👉 “RAG를 쓰니까 검색은 그냥 벡터 DB로 대충 하면 되는 거 아닌가요?”

이 생각이 RAG 품질을 바닥으로 떨어뜨리는 가장 빠른 길입니다.

 

🎯 RAG에서 검색이 차지하는 비중

👉 많은 사람들이 이렇게 오해합니다.

“검색은 그냥 문서 가져오는 단계고, 결국 답변은 LLM이 하는 거잖아”

하지만 실무에서는 정반대입니다.

RAG 결과의 70~80%는 검색 단계에서 이미 결정됩니다.

LLM은 잘 찾아온 정보로만 잘 판단할 수 있습니다.

 

🎯 검색이 없는 RAG는 왜 실패하는가

👉 벡터 DB만으로 RAG를 구성하면 다음과 같은 문제가 바로 드러납니다.

• 질문의 의도를 잘못 해석한다
• 비슷해 보이지만 틀린 문서를 가져온다
• 중요한 키워드를 놓친다

벡터 검색은 “의미가 비슷한 것”을 찾는 데는 강하지만 “정확한 것”을 찾는 데는 약합니다.

그래서 실무 RAG에서는 검색(Search)이 반드시 먼저 등장합니다.

 

🎯 실무에서 사용하는 검색 구조

👉 실무 RAG에서 가장 많이 쓰이는 구조는 다음과 같습니다.

 질문 → 키워드 검색 (ElasticSearch) → 벡터 검색 (Vector DB) → 후보 문서 압축 → Context 구성 → LLM 

이 구조의 핵심은 검색을 한 번만 하지 않는다는 점입니다.

• 키워드 검색: 정확성 확보
• 벡터 검색: 의미 확장

두 검색은 경쟁 관계가 아니라 역할 분담입니다.

 

🎯 키워드 검색이 반드시 필요한 이유

👉 실무 질문에는 이런 특징이 있습니다.

• 정책명, 코드값, 용어가 정확하다
• 숫자, 날짜, 버전 정보가 중요하다
• “비슷한 말”이 아니라 “같은 말”을 원한다

이 영역은 벡터 검색이 절대 이길 수 없습니다.

그래서 ElasticSearch 같은 전통적인 검색 엔진이 여전히 핵심입니다.

RAG는 최신 기술이지만, 검색은 여전히 고전 기술입니다.

 

🎯 벡터 검색은 언제 강력해지는가

👉 벡터 검색은 이런 상황에서 빛을 발합니다.

• 질문이 추상적일 때
• 표현이 애매할 때
• 사용자가 정확한 용어를 모를 때

즉, 벡터 검색은 “의도를 넓히는 역할”을 담당합니다.

그래서 실무에서는 키워드 → 벡터 순서가 가장 안정적입니다.

 

🎯 검색 품질을 높이지 않으면 RAG는 반드시 망한다

👉 검색 품질이 낮으면 아무리 좋은 LLM을 써도 결과는 같습니다.

• 틀린 문서를 근거로
• 그럴듯한 답변을 생성

이건 버그가 아니라 설계 문제입니다.

실무에서는:

• 검색 결과 스코어 검증
• Top-K 튜닝
• 필터링 조건 설계

에 가장 많은 시간을 씁니다.

RAG는 검색 시스템 위에 세워진 서비스입니다.

 

☔ 정리

👉 검색(Search)은 RAG의 보조가 아니라 심장입니다.

• 검색이 틀리면
• Context가 망가지고
• LLM은 반드시 틀립니다

이걸 이해해야 “RAG를 쓴다”가 아니라 “RAG를 설계한다”고 말할 수 있습니다.

 

 

다음 글에서는 벡터 DB를 도입하면 왜 새로운 문제가 생기는지를 다뤄봅니다.

 

If I was of any help to you, please buy me coffee 😿😢😥

If you have any questions, please leave them in the comments

Buy me a coffee

▶ Youtube Sub

🧭 References

[1] reference : https://doctorson0309.tistory.com/

[2] Ads : https://apps.apple.com/us/app/beluga-classic-film-filters/id6744041061