osFoundry / Platform
MMR 다양성
Maximal Marginal Relevance가 상위 일치 항목뿐 아니라 다양한 각도를 포괄하는 결과를 선택합니다.
개요
MMR 다양화는 지식 베이스를 쿼리할 때 Maximal Marginal Relevance를 적용하는 osFoundry의 검색 단계입니다. 순수하게 관련도만으로 매기는 순위에는 잘 알려진 약점이 있습니다. 상위 결과가 서로 거의 중복되기 쉽다는 점입니다. 모두 같은 방식으로 쿼리에 매치되기 때문입니다. 다섯 개의 청크가 같은 문단을 되풀이하면 그중 넷은 컨텍스트 윈도우 공간을 낭비하고, 모델은 질문의 두 번째나 세 번째 관점을 끝내 보지 못합니다. MMR은 각 후보를 두 가지 기준으로, 즉 쿼리와의 관련도와 이미 선택된 청크와의 비유사도로 채점한 뒤, 관련도가 높으면서 *동시에* 서로 다른 결과를 골라 이 문제를 해결합니다.
osFoundry에서 MMR은 osStudio에서 채팅 Path별로 구성하는 맞춤 RAG 파이프라인의 한 단계입니다. 쿼리는 먼저 하이브리드 검색(임베딩 검색과 BM25 키워드 검색)을 거칩니다. 이어서 필터와 리랭크 단계를 추가하고 그 뒤에 MMR을 두면, 이미 품질이 높은 후보 집합을 다양화할 수 있습니다. 이 단계는 표준 MMR 제어 항목을 제공합니다. 순수 관련도와 순수 다양성 사이를 오가는 lambda 파라미터, 후보를 뽑아 오는 후보 풀의 크기, 그리고 프롬프트로 내보내는 청크 수입니다. 모든 단계가 버전 관리되고 JSON Schema로 검증되는 설정이므로, 코드 채팅 Path와 고객 성공 Path가 서로 다르게 다양화할 수 있고, 소스 코드를 건드리지 않고도 변경을 롤백할 수 있습니다.
이 효과는 폭넓거나 모호한 질문, 그리고 어휘가 겹치는 코퍼스에서 가장 큽니다. 이런 경우 상위 임베딩 히트가 한곳에 빽빽이 몰리기 때문입니다. MMR은 top-1의 순수 관련도를 조금 양보하는 대신 커버리지를 얻습니다. 모델이 지식 베이스에 실제로 담긴 내용의 폭을 보게 되므로, 대개 더 근거 있는 답변으로 이어집니다. 이는 osFoundry의 BYOK, 로컬 우선 기조와도 일관됩니다. 검색과 다양화는 여러분의 workspace에서 실행되고, 임베딩은 관리형 Voyage 프록시나 자신의 키를 거치며, 어떤 좌석당 요금도 파이프라인을 가로막지 않습니다.
주요 기능
- 검색 파이프라인에 관련도와 중복을 저울질하는 MMR(Maximal Marginal Relevance) 단계를 추가하여, 상위 결과가 최상위 매치를 되풀이하는 대신 서로 다른 관점을 아우르게 합니다
- osStudio에서 Path별로 MMR을 구성하세요. 관련도와 다양성 사이의 lambda 절충값, 후보 풀 크기, 그리고 최종적으로 프롬프트에 전달되는 청크 수를 지정합니다
- retrieve, filter, rerank 단계 뒤에 이어지므로, MMR은 원본 임베딩 히트가 아니라 이미 순위가 매겨진 후보 집합을 다양화합니다
- 하이브리드 임베딩과 BM25 검색의 결과에 대해 동작하며, Voyage 임베딩은 관리형 프록시나 BYOK로 제공되는 자신의 키를 통해 이용할 수 있습니다
- 모든 MMR 설정은 JSON Schema로 검증되고 버전 관리되며 롤백이 가능한 osStudio 설정이므로, 서로 다른 채팅 화면이 소스 코드 변경 없이 각기 다르게 다양화할 수 있습니다
활용 사례
- 지원 엔지니어: 폭넓은 문제 해결 질문이 거의 동일한 청크 다섯 개를 돌려줄 때, MMR이 각 자리를 서로 다른 원인으로 채워 답변이 하나 이상의 실패 모드를 아우르게 합니다
- 연구자: 대규모 문서 집합을 쿼리할 때 상위 임베딩 히트가 한 섹션에 몰리는 경우, MMR이 코퍼스의 여러 부분에서 구절을 끌어와 더 충실한 종합을 만듭니다
- osStudio 파이프라인 구축자: 코드 채팅 Path에서는 MMR의 lambda를 엄격한 관련도 쪽으로 조정하고 탐색용 Path는 더 다양하게 두며, 이 모두를 롤백 가능한 버전 관리 설정으로 처리합니다
자주 묻는 질문
Maximal Marginal Relevance(MMR)란 무엇이며, 왜 RAG에 추가하나요?
MMR은 후보 구절을 쿼리와의 관련도로 순위를 매기되, 이미 선택된 구절과의 유사도에는 페널티를 주는 선택 방법입니다. 상위 검색 결과가 거의 중복되기 쉬울 때 추가합니다. MMR이 없으면 폭넓은 질문이 같은 말을 하는 청크 다섯 개를 돌려줄 수 있고, 모델은 한 관점만 보게 됩니다. MMR은 가장 관련도 높은 청크는 남기되, 나머지 자리는 서로 구별되고 보완적인 구절로 채웁니다.
osFoundry에서 MMR 다양화를 어떻게 켜나요?
MMR은 osStudio에서 채팅 Path별로 구성하는 맞춤 RAG 파이프라인의 한 단계입니다. retrieve, filter, 그리고 선택적 rerank 단계 뒤에 MMR 단계를 추가한 다음, lambda(관련도 대 다양성 절충값), 후보를 끌어오는 후보 풀, 최종 청크 수를 설정합니다. 설정은 JSON Schema로 검증되고 버전 관리되므로, 조정하고 한 Path에서 시험한 뒤 필요하면 롤백할 수 있습니다.
MMR은 리랭커와 어떻게 다른가요?
리랭커는 각 후보가 쿼리에 얼마나 잘 맞는지만으로 다시 점수를 매겨 top-k 정밀도를 높입니다. MMR은 다른 목표를 최적화합니다. 선택된 집합 전체에서 관련도를 최대화하면서 중복을 최소화하는 것입니다. 둘은 상호 보완적입니다. osFoundry에서는 보통 먼저 리랭크해 가장 잘 맞는 후보를 얻은 뒤 MMR을 적용하여, 통과하는 청크가 단 하나의 최적 매치를 되풀이하지 않고 서로 다른 측면을 아우르도록 합니다.