DEVOCEAN

작년에 이어 올해에도 정말 많은 LLM 모델이 나왔고, 유료와 무료 모델을 두루 사용해본 결과

확실히 유료모델이 성능이나 속도측면에서 가성비가 좋았고, 당연하게도 비싼 모델일수록 결과가 매우 좋았습니다.

특히, 글 이해 분야에서는 이제 LLM의 성능이 사람을 능가하고 특히 속도측면에서 더욱 강점을 가지는 것으로 보입니다.

그럼에도 사람이 모든 세상의 지식을 알고 있지 못하듯이, LLM도 비슷한 한계가 있고, 이로 인해 RAG라는 방식이 대안으로 등장하였는데,

올해는 거의 대부분의 작업이 RAG를 기반으로 이루어질 만큼 성능과 활용도가 뛰어나고 앞으로도 현업에서는 필연적으로 사용할 수밖에 없는 방식이라고 봅니다.

Vector DB 및 프레임워크

저는 개인적으로 다양한 툴 중에서 Qdrant 백터 디비와 llamaindex 패키지를 활용하여 python을 통한 작업을 진행하였는데, 너무 만족스러웠습니다.

Qdrant 디비의 경우에는 docker나 k8s에 helm 차트로 쉽게 배포가 가능하며, 이를 통해 다양한 config값의 변경이 쉬웠으며 대시보드 UI도 제공되며 특히 llamaindex와의 결합이 좋았습니다.

llamaindex의 경우에는 자체적으로 다양한 임베딩 방식을 내재하며, huggingface 모델의 적용이 쉽고, 기본 세팅으로는 단 3줄로도 RAG를 구성할 수 있다는 극강의 효율을 보여줍니다.

이를 통해 코딩의 시간을 줄이고, 실무에서 다양한 임베딩 모델을 테스트해보고, 모델을 최적화하는데 초점을 맞출 수 있다는 점이 좋았고, 개발 속도가 매우 빨랐습니다.

다만, 이게 또 단점이 될 수 있는게, 그냥 잘 된다고 믿으면 편하지만, 뒷단의 작동방식을 파고 들면 들수록 복잡한 코드를 모두 다 찾아봐야되는...

당연하면서도 지난한 작업이 필요하고, 커스터마이징을 하려면 결국 이 지난한 과정이 필요하다는 점이였습니다.

나름 커스터마이징을 위한 튜토리얼도 제공되긴 하지만, 구체적으로 어느 단계에서 수정이 이루어져야 원하는 커스터마이징이 될지는 코드를 다 까봐야 알 수 있습니다...

더불어 최신의 기술들이 바로바로 반영이 되지는 않아서 직접 만들어야하는 부분이 있고, 이때는 기존 프레임워크의 이점을 크게 가져갈 수 없다는 단점이 있었습니다.

성능 평가

RAG의 성능은 Vector 디비에서 연관된 문서 추출과 이를 이용한 prompt 설계 그리고 최종 사용할 llm 모델 이 세 파트에서 결정된다고 보는데,

그 중에서도 연관된 문서 추출이 가장 중요하다고 봅니다.

실제로 다양한 개선된 모델들은 이 부분에서 최적의 문서 추출을 위한 다양한 기법들이 나와있고, 이는 문서의 수가 늘어날수록 더욱 중요해진다고 봅니다.

그리고 임베딩 모델의 선택도 중요한데, 임베딩 모델별로 특화된 언어가 있고, cross lingual에 성능이 천차만별이라 어느 한 모델이 가장 좋다고 하기 어렵습니다.

상황에 맞게 최적의 임베딩 모델을 사용해야합니다.

그리고 문서에 일부러 중복이 되도록 chunk를 나누는 기법이 있는데, 문서가 방대해질수록 이렇게 설계해서 디비에 저장하는것이 성능 향상에 큰 도움이 되는 것으로 보입니다.

개인적으로는 디비에서 문서 추출한 이후 다른 데이터를 결합해서 순위를 조절하는 방식을 커스터마이징해서 사용했는데,

이 부분에서는 아직 모든 경우에 최선이 되는 정답이 나와있지는 않아서 상황에 맞게 최적화하는 부분이 필요합니다.

RAG의 성능 평가는 사실상 비싼 gpt 모델을 이용하는 방식도 있지만,

개인적으로는 추천 모델에서 사용하던 metric으로 평가를 하는게 유용하다고 생각되었고(사실상 연관된 문서를 추출하는게 추천하고 비슷한 느낌이라), 저는 이것을 사용했습니다.

소회

RAG는 사실 크게 사용하기 어려운 기술이 아니고, 작업에 소요되는 시간도 적은 반면 얻을 수 있는 이점이 많은게 정말 큰 장점이라고 생각합니다.

개인적으로 많은 분들이 RAG를 각자의 업무 분야에 사용하여 검색의 최적화 및 업무 시간 단축?등의 이점들을 누리시면 좋겠습니다.