출처: GPT-4o
2023년 벡터 검색과 벡터 데이터베이스가 큰 주목을 받았지만, 지난 한 해 동안 수많은 모델 출시 소식에 묻혀 검색 기술은 다소 뒷전으로 밀려난 감이 있습니다. 하지만 좋든 나쁘든, 검색은 여전히 거의 모든 B2B AI 애플리케이션의 중심에 있습니다.
요즘 ‘단순한 RAG 애플리케이션’이라는 말은 마치 18개월 전 ‘GPT 래퍼’라고 불리는 것과 비슷한 모욕으로 여겨지곤 합니다. 만약 당신이 하는 일이 ‘단지’ 검색뿐이라면, 이를 복제하는 것이 얼마나 어려울까요? 결론부터 말하면, 생각보다 훨씬 어렵습니다.
이번 글에서는 FrontierAI에서 RunLLM을 개발하면서 얻은 실무 경험을 바탕으로, AI 애플리케이션에서 검색 시스템이 얼마나 복잡하고 중요한지, 그리고 어떻게 제대로 된 검색 시스템을 구축할 수 있는지 살펴보겠습니다.
RAG가 ‘단순하다’는 착각
많은 사람들이 RAG(Retrieval-Augmented Generation)를 단순한 기술로 여기는 이유는 겉보기에는 간단해 보이기 때문입니다. 임베딩을 생성하고, 유사도 검색을 수행한 후, 문서를 GPT-4에 입력하는 것 – 이것이 전부라고 생각하기 쉽습니다. 하지만 이런 방식으로는 방어 가능한 차별화된 제품을 만들 수 없을 뿐만 아니라, 결과 품질도 그리 좋지 않습니다.
실제로 제대로 된 검색을 구현하려면 벡터 데이터베이스보다 훨씬 많은 것이 필요합니다. 우수한 검색 프로세스에는 세 가지 핵심 요소에 대한 깊은 이해가 필요합니다:
- 수집하는 데이터에 대한 이해: 어떤 형태의 데이터를 다루고 있는지
- 데이터 활용 방식에 대한 이해: 이 데이터가 어떻게 사용될 것인지
- 상황별 데이터 유용성에 대한 이해: 언제 어떤 종류의 데이터가 가장 유용한지
RunLLM의 경우, 현재 사용하는 검색 파이프라인의 핵심 부분은 2023년 가을부터 2024년 여름까지 5-7년 상당의 엔지니어링 작업의 결과입니다. 이 작업의 초점은 단순히 쿼리가 들어올 때 어떻게 처리할 것인가에만 있지 않았습니다. 다양한 형태의 텍스트 데이터를 정제하고, 효과적인 검색을 위한 모든 관련 데이터와 메타데이터를 포함하는 우수한 인덱스 세트를 구축하며, 결과 품질을 점진적으로 개선하는 작은 최적화(예: 코드 예제 감지 및 추출) 작업들도 포함되었습니다.
단일 검색 기법의 한계
출처: Unsplash
복잡성의 일부는 AI 애플리케이션에 충분히 좋은 단일 검색 기법이 존재하지 않는다는 사실에서 비롯됩니다. 이는 기술적 제약이 아니라 UX 제약입니다.
구글은 수십 년 동안 검색 분야에서 뛰어난 성과를 보여왔는데, 왜 우리는 이를 재현할 수 없을까요? 역설적이게도, 이는 사용자 인터페이스의 한계 때문입니다.
구글은 (지식 그래프와 AI 답변이 도입되기 전까지) 찾고 있는 것에 대한 ‘정답’을 제공한다고 주장한 적이 없습니다. 대신 올바른 답을 찾는 것을 극적으로 쉽게 만들어주었습니다. 대부분의 사람들은 구글이 상위 5-10개 결과에서 올바른 답을 제공할 만큼 충분히 좋다고 기대했고, 여러 결과를 클릭해보는 것에 익숙했습니다.
반면 AI 애플리케이션은 단일 답변 또는 기껏해야 몇 개의 대안을 제시합니다. 이는 질문에 답하기 위한 올바른 데이터를 찾는 것이 매우 중요하다는 의미입니다. 잘못된 데이터를 사용하면 단순히 틀린 답을 제공하게 됩니다.
텍스트 검색(BM25)과 벡터 검색 같은 기법들은 ‘올바른 지역’에 도달하는 데는 좋습니다. 올바른 문서는 대개 상위 20-30개 안에 있지만, 어떤 단일 검색 기법으로도 상위 5개 안에 신뢰성 있게 들어가지는 않습니다.
다층적 검색 전략: 모든 것을 동원하는 접근법
RunLLM에서는 이 문제에 ‘모든 것을 동원하는’ 접근법을 사용합니다:
- 질문 분석 및 재작성: 파인튜닝된 모델을 사용하여 질문을 분석하고 재작성
- 다중 검색 기법: 텍스트 검색과 벡터 검색을 동시에 수행
- 필터링: 불린 술어와 그래프 검색을 사용하여 데이터 필터링
- 휴리스틱 적용: 각 질문에 어떤 데이터가 가장 관련성이 높은지에 대한 휴리스틱 사용
- LLM 재순위: 질문에 답하기 전에 LLM으로 결과를 재순위화
단일 기법만으로는 충분하지 않습니다. 고품질 검색 결과를 생성하는 것은 이 모든 것의 조합입니다.
LLM 재순위: 차원의 벽을 넘다
검색 기법들이 우리를 ‘올바른 지역’으로 인도하는 동안, 답변하려는 질문의 맥락에서 각 문서를 읽고 관련성 점수를 부여하는 LLM의 재순위 작업이 어떤 문제를 해결하는 데 있어서 성공과 가장 높은 상관관계를 보입니다.
이는 직관적으로 이해가 됩니다. 텍스트 검색이 어려운 이유는 텍스트의 차원이 엄청나게 높기 때문입니다. 대부분의 검색 기법은 문제를 다루기 쉽게 만들기 위해 차원을 줄이지만, 그 과정에서 정확도를 잃습니다. LLM 역시 텍스트 처리를 위해 임베딩에 의존하지만, 추가적인 처리를 통해 다른 어떤 기법도 따라올 수 없는 방식으로 텍스트를 이해하고 생성할 수 있다는 것이 명확합니다.
결과적으로, LLM이 전체 문서를 실제로 읽고 질문과의 관련성을 분석하도록 하는 것은 엄청나게 가치가 있습니다. 이 기법은 질문 답변의 기초 역할을 할 뿐만 아니라 RunLLM의 다양한 다른 기능에도 사용됩니다. 문서 격차 찾기부터 질문 주제 분류까지 모든 것에 활용됩니다.
도메인별 특화: 맞춤형 접근의 필요성
지금까지는 모든 애플리케이션에 잘 작동할 것으로 생각되는 일반적인 기법들을 다뤘습니다. 하지만 품질에는 중요하지만 일반화하기 어려운 도메인별 검색 측면들도 있다는 것이 사실입니다.
Cursor 같은 제품이 어떻게 개선되었는지 관찰해본다면, 코드별 검색 능력이 매우 중요하다는 것이 분명할 것입니다. LLM 이전에도 전통적인 검색 기법은 대규모 코드베이스에서 매우 부족한 성능을 보였고, 이것이 Sourcegraph 같은 제품들이 많은 견인력을 얻을 수 있었던 이유입니다.
코드는 검색하기 어려운 텍스트 형태의 극단적인 예일 수 있지만, 다른 많은 도메인에서도 마찬가지입니다.
RunLLM의 경우 다음과 같은 작업들을 수행해야 합니다:
- 코드 예제 추출: 문서에서 코드 예제를 추출하여 일반 텍스트 임베딩에서 손실되지 않도록 함
- 지식 그래프 활용: 다양한 제품 기능들이 서로 어떻게 연결되는지 이해하여, GCP를 사용하는 사용자에게 AWS 기능에 대한 답변을 잘못 제공하지 않도록 함
- 휴리스틱 적용: 새로운 기능이 오래된 것보다 더 관련성이 높다는 휴리스틱과 사용자 요청(예: 코드 예제 보여주기) 활용
- 지식 베이스 정확성 유지: 기능 변경, 버그 수정, 해결 방법 제안에 따라 지식 베이스를 정확하게 유지
이 모든 것들이 RunLLM에서 검색을 수행하는 방식에 영향을 미치며, 이들 중 많은 부분이 다른 애플리케이션에는 적용되지 않을 수도 있습니다. 하지만 필요한 특수성을 이해하는 것이 중요합니다.
동적 데이터 처리: 실시간의 도전
위의 요점들은 필요한 모든 데이터를 사용할 때 훨씬 미리 읽고, 분석하고, 인덱싱할 수 있다는 암묵적 가정에 기반합니다. 그런 경우라면 좋겠지만, 그것이 불가능한 경우들이 많이 있습니다.
RunLLM이 해결하려고 면밀히 살펴보고 있는 것 중 하나는 사용자별 데이터입니다. 예를 들어, 로그 데이터, 플랜/결제 정보, 구성 매개변수 등입니다. 이 모든 정보를 미리 인덱싱하는 것은 의미가 없거나 (많은 경우에) 불가능하므로, 제공하는 가이드를 더 잘 알려주기 위해 관련 데이터를 동적으로 찾는 지원을 추가하고 있습니다.
주요 변화는 각각의 관련 데이터 소스를 미리 분석하고 미리 읽을 수 없다는 것이므로, 어떤 데이터를 사용할 수 있는지 아는 것과 올바른 데이터에 접근하는 것이 가장 중요한 작업이 됩니다. 로그 같은 것들의 문제는 분석하기 전에 관련 비트로 필터링해야 하는 엄청난 양의 데이터를 얻을 수 있다는 것입니다.
분류, 필터링, 읽기에 대한 핵심 접근법은 공유될 것이지만, 이런 경우들에서 정확도 대비 지연 시간을 최적화하는 방법에 대해 더 배워야 할 것들이 있을 것입니다.
맞춤형 검색의 중요성
검색이 지난 한 해 동안 일부 빛을 잃었을 수 있지만, 여전히 거의 모든 LLM 애플리케이션의 중요한 측면입니다. 이 글을 통해 이해했으면 하는 것은 검색이 AI 애플리케이션의 성공에 얼마나 중요한지, 그리고 특정 애플리케이션에 맞게 검색 기법을 얼마나 많이 맞춤화해야 하는지입니다.
일반적인 RAG 시스템(또는 심지어 RAG-as-a-Service 제품들)에 대한 블로그 게시물에서 설명된 기법들은 HR 헬프데스크 같은 고수준 작업에는 아마 합리적으로 잘 작동할 것이지만, 더 복잡한 작업에는 잘 확장되지 않을 것입니다.
성공적인 AI 애플리케이션을 구축하려면 검색이 단순한 기술적 구성 요소가 아니라 제품의 핵심 차별화 요소라는 점을 인식해야 합니다. 도메인에 특화된 데이터 처리부터 다층적 검색 전략, 그리고 LLM을 활용한 지능적 재순위까지 – 모든 것이 조화롭게 작동해야 진정한 가치를 제공할 수 있습니다.
AI 애플리케이션의 미래는 단순한 RAG 구현을 넘어서, 각 도메인과 사용 사례에 최적화된 정교한 검색 시스템을 구축하는 것에 달려 있습니다. 이는 단순히 기술적인 도전이 아니라, 사용자에게 진정한 가치를 제공하기 위한 전략적 투자인 것입니다.
참고자료:
Comments