0. TMI
회사에서 자사 제품 개발 중 거진 모든 회사들이 자사만의 RAG구축을 하는 것이 유행이라고, 우리도 구축한번 해보자! 해서 제가 담당하게 됐습니다.
관련된 프로젝트 일부분을 간략하게 말씀드리면, CWE나 CERT, MISRA 혹은 과거 구축되어 있던 자사만의 판례를 RAG로 구축하여 코드 결함을 정확하게, 구축된 데이터를 통하여 좀 더 명확하고 최신화된 결함 수정 예시를 llm을 통해 제시하는 기능 구현이었습니다.
개발과정에서 RAG에 명확한 한계점과, 현재(2025/06/30) 기준 RAG는 어떤 녀석인지 면밀히 알게 되었습니다.... 이 글을 보시는 여러분은 그러한 문제를 겪지 않기를 바라면서 이 글을 시작합니다.
1. RAG란
RAG (Retrieval-Augmented Generation) : 기존의 언어 모델에 검색 기능을 추가하여, 주어진 질문이나 문제에 대해 더 정확하고 풍부한 정보를 기반으로 답변을 생성할 수 있게 해줍니다.(출처: https://wikidocs.net/231393)
RAG 구축해보며 내린 필자의 정의: 정보 저장소. 현재 RAG의 위치는 오로지 LLM에 부족한 정보 전달하는 기능 뿐. 그 이외의 기능따윈 없음.
2. 네...?
네. rag랑 llm을 연동시킨다는 것은 결국 llm이 가지고 있지 않은 정보를 그저 "텍스트" 형태로 context에 담아 넘겨주는 것 뿐입니다. 그냥 코드를 짜서 필요한 정보 .py로 저장한 후, llm에서 그대로 import해서 가져오는거랑 별반 다를게 없습니다.
3. 그럼 왜 RAG가 그렇게 각광받는 거죠?
다음의 이유들이 있습니다.
1. 인터넷에 떠돌아 다니지 않는 자사만의 고유 데이터, 혹은 기밀 데이터를 온프레미스로 구축할 수 있다. (이 의미만 있다면, 그냥 엑셀이나 한글로 저장하는거랑 하나도 다를게 없음....)
2. LLM의 정보 최신화를 도울수 있다. (이것도 사실상 웹 크롤링이나 정보 업데이트 자동 구축 등 엄밀히 말하면 RAG의 기능이 아니라 그냥 다른 기능임)
3. LLM이 좀 더 정보 기반으로 대답함. (이건 뭐 RAG없어도 만들수 있음)
3. 기존 검색이 '키워드' 기반이었다면, RAG는 '의미'기반으로 데이터를 찾아줄 수 있다. (사실상 이거원툴.....)
4. 의미기반?
RAG를 구축한다 했을 때, 뭐 데이터를 벡터화 시키고, chunking해서 벡터 DB에 저장할 뿐만아니라, 그때 쓰는 임베딩 모델 녀석도 꽤나 무거운 녀석이다 보니, 굉장히 무언가 많은 역할을 수행 할 수 있다고 생각하는 분들이 있습니다.
특히, 이 RAG의 의미기반이란 특성을 잘못알고 RAG가 만능으로(ex> 잘못된 코드와 그 이유를 줄테니, 다른 비슷한 잘못된 코드를 RAG 구축한 데이터를 적용해 고쳐줘라는 식의....) 알고 쓰려는 분들이 종종 있는데, 그 만행을 저지르기 전에 의미 기반이라는 것을 관용구를 통해 면밀히 전달해드리려 합니다.
| 키워드 기반 검색 | 의미 기반 검색 | |
| 의미 | 키워드를 통한 검색. 쉽게 말하면, 웹 이나 뭐 한글 등에서 ctrl + f 해서 찾는 방식과 동일한 로직 |
데이터 임베딩을 통해 벡터 데이터로 저장 후, 유사도를 측정해 매치되는 정보를 가져오는 로직 |
| 예시 | 안녕하세요. 오늘 날씨가 참 좋죠? 바깥 바람을 쐐면서 밥을 먹으면 기분이 굉장히 좋아질것만 같아요. 오늘 밖에서 식사를 하는건 어떤가요? ctrl + f 밥을 먹으면 안녕하세요. 오늘 날씨가 참 좋죠? 바깥 바람을 쐐면서 밥을 먹으면 기분이 굉장히 좋아질것만 같아요. 오늘 밖에서 식사를 하는건 어떤가요? |
안녕하세요. 오늘 날씨가 참 좋죠? 바깥 바람을 쐐면서 밥을 먹으면 기분이 굉장히 좋아질것만 같아요. 오늘 밖에서 식사를 하는건 어떤가요? ctrl + f 밥을 먹으면 안녕하세요. 오늘 날씨가 참 좋죠? 바깥 바람을 쐐면서 밥을 먹으면 기분이 굉장히 좋아질것만 같아요. 오늘 밖에서 식사를 하는건 어떤가요? |
즉, 키워드 기반 검색은 철자가 다 일치해야 찾아주는 것이고, 의미 기반 검색은 찾는 키워드나 입력한 값과 의미가 비슷한 것을 찾아주는 것입니다.
위의 예시를 보면 RAG에서의 의미 기반이라는 녀석이 굉장히 유용할 것으로 보입니다.
실제로도 많은 회사에서 자사의 AI를 만들때, 저 의미 기반 검색을 구현해, LLM이 회사에 대한 정보를 잘 대답 할 수 있게 데이터를 잘 넘겨줍니다.
이때, 이 의미기반 찾아준다것의 범위를 알기 쉽지 않기 때문에 그 한계를 경험을 바탕으로 명시하려고합니다.
5. 한계
RAG의 의미만 정확하게 알면 한계도 뚜렷하게 알 수 있습니다만, 예시가 있으면 편하겠죠?
1. 문서상의 내용에 링크가 포함되어 있을 경우. 그 링크를 타서 추가적인 내용을 탐색하지 않음.
-> 다만 qdrant의 벡터 db와 웹 크롤링의 경우 <a>태그를 뭐 metadata에 따로 저장하는 식으로 활용 할 수 있음. (구현 어려웠...ㅎ)
2. 특히 코드 예제에서, 틀린 코드 예제와 올바른 코드 예제가 틀린 부분만 고치고 형태는 똑같기 때문에 의미기반 검색에서 만약 예시 코드를 만들시에 문제를 야기할 수 있음.
https://wiki.sei.cmu.edu/confluence/display/c/EXP33-C.+Do+not+read+uninitialized+memory
위의 링크를 보면 웹 크롤링 후 임베딩한 다음, 의미기반으로 찾게되면, compliant와 noncompliant의 코드가 굉장히 유사함으로 찾게 됨.(태그 구분이 되어 있지 않아 분류작업이 석연치 않음. 필자는 그냥 h2 태그로 구분해서 쓰는중.)
-> 이는 chunk를 뭐 올바른 코드 따로, 올바르지 않은 코드 따로 chunking하고 title을 다르게 주는 식으로 커스터마이징하여 써야함.
6. 결론
RAG라는 녀석은 잘해봐야 관련 정보만 긁어오는 녀석이다. -끝-
FYI: RAG 쓸거면 의미 기반과 키워드 기반을 섞은 하이브리드는 알아야...
https://www.couchbase.com/blog/ko/hybrid-search/