RAG 구축 시 고려해야 할 것들

 

현재 온디바이스(On-Device) 환경에서 사용할 RAG 솔루션을 개발 중에 있다.

 

매번 하드웨어의 제약이 사실상 없는 클라우드 환경에서만 개발하다가, 리소스 제약이 심한 온디바이스 환경으로 넘어와 초기 RAG 시스템을 개선하려다 보니 고민해야 할 부분들이 정말 많았다.

 

전체 구조를 도식화하면 다음과 같다.

 

https://www.chitika.com/building-end-to-end-rag/

 

이 그림이 대부분의 RAG 시스템을 설명해준다. 그림을 보고 다시 생각해보니 사실 안 중요한 부분이 없긴 한데...

그래도 그 중에서 조금 더 중요하다고 생각하는 부분부터 하나씩 정리해보자.

 

1. 임베딩을 하기 위한 데이터 정제

현재는 사내에서 자체 개발한 문서 분석 툴을 사용하고 있다. 데이터 정제 과정이 중요한 이유는, 이 전처리를 얼마나 잘하느냐에 따라 표나 이미지에 포함된 정보에 대한 질문을 처리할 수 있는지 여부가 갈리기 때문이다. 또한, 다양한 비즈니스 환경을 고려했을 때 문서 종류(포맷)를 어디까지 커버할 수 있느냐도 매우 중요한 문제다.

2. 임베딩 모델

임베딩 기법도 다양해졌고, 언어 특화 모델도 우후죽순 쏟아져 나오고 있다. 단순히 성능 지표가 높은 모델을 고르면 되는 서버 환경과 달리, 온디바이스에서는 모델의 크기(Size)와 추론 속도(Latency)까지 고려해야 하니 선택이 더욱 까다롭다. 결국 어떤 임베딩 모델을 채택하느냐가 검색 품질의 상한선을 결정짓고, 이것이 곧 RAG 전체 시스템의 성능을 가른다고 해도 틀린 말이 아니다.

 

여러 스타일(언어, 질의의 종류)로 임베딩해두는게 가장 좋긴한데 온디바이스 환경에서는 선택권이 많지 않다.

3. 벡터 데이터베이스

사실 벡터 데이터베이스가 크게 중요하진 않은 것 같다. 벤더마다 특화된 검색 알고리즘을 내세우긴 하지만, 결국 내부적으로는 코사인 유사도(Cosine Similarity)를 기반으로 동작하기 때문에 결과 품질은 대동소이하다.

 

대규모 분산 환경이라면 샤딩이나 복제 같은 인프라 이슈 때문에 DB 선택이 중요하겠지만, 로컬 단일 환경에서는 DB의 기능적 차이보다는 얼마나 가볍게 구동되는지가 더 관건이다.

4. 질의 강화 (Query Augmentation)

보통 사용자의 질문은 그대로 검색에 사용할 수 없는 경우가 대부분이다. 질문이 너무 짧거나, "그거", "지난번 문서" 같이 대명사를 남발하여 모호하기 때문이다.

 

따라서 LLM을 통해 질문의 의도를 명확히 하거나, 이전 대화 맥락을 포함하여 검색하기 좋은 완전한 문장으로 재구성해주는 과정이 필수적이다.

5. HyDE 및 구조적 키워드 추출

이것들도 사실상 넓은 범위의 질의 강화에 속한다. 단순 벡터 검색만으로는 부족한 부분을 채우기 위한 전략들이다.

 

HyDE는 질문에 대한 가상 답변을 생성해 의미적 유사도를 좁히는 방식이고, 구조적 키워드 추출은 질문에서 날짜, 고유명사 같은 메타데이터를 뽑아내 하이브리드 검색(필터링)을 하기 위함이다. 특히 정확도가 생명인 비즈니스 도메인에서는 키워드 필터링이 없으면 원하는 문서를 찾기 힘들다.

6. 리랭커 (Reranker)

1차 검색으로 가져온 문서들의 순위를 다시 매기는, 일종의 '최종 채점관'이다. 벡터 검색이 속도를 위해 정확도를 일부 희생했다면, 리랭커는 속도는 좀 느려도 문맥을 꼼꼼히 따져 진짜 정답을 상단으로 올린다. 다만 온디바이스 환경에서는 리랭커 자체가 연산 비용(Latency)을 잡아먹는 주범이 될 수 있다. 그래서 무거운 모델을 쓰기보단 아주 가벼운 Cross-Encoder를 쓰거나, 리랭킹할 후보 문서의 개수를 적절히 타협하는 것이 중요하다.

7. 모델의 양자화 (Quantization)

앞서 언급한 과정들을 통해 아무리 좋은 문서를 찾아와도, 결국 사용자와 대화하는 건 LLM이다. 하지만 온디바이스 기기에서 수 기가바이트가 넘는 모델을 원본 그대로 띄우는 건 사실상 불가능하다. 메모리가 터져나가거나, 답변 한 줄 듣는데 세월아 네월아 걸릴 테니까.

 

그래서 양자화는 선택이 아니라 생존을 위한 필수 조건이다. 모델의 가중치를 압축해 용량과 연산량을 줄여야 한다. 문제는 "얼마나 압축할 것인가"다. 너무 줄이면 모델이 멍청해지기 때문에, 기기 스펙에 딱 맞는 최적의 경량화 지점을 찾는 것이 중요하다.

마치며

지금 위에 정리한 내용만 다시 훑어봐도, 시스템 하나를 위해 띄워야 할 LLM과 딥러닝 모델이 대체 몇 개인지 모르겠다. 문서 분석 모델, 임베딩 모델, 질의 생성을 위한 sLLM, 그리고 리랭커까지...

 

과연 이 무거운 파이프라인이 한정된 리소스의 온디바이스 환경에서 원활하게 돌아갈 수 있을지 솔직히 의문이 든다. 

 

제약이 심할수록 해결했을 때의 성취감도 클 테니, 일단 묵묵히 부딪혀 봐야겠다.