LFM2.5 다국어 리트리버의 엣지 검색 설계

2026년 6월 Liquid AI는 LFM2.5-Embedding-350M과 LFM2.5-ColBERT-350M을 공개했다. 두 모델은 LFM 계열에서 처음으로 양방향(Bidirectional) 아키텍처를 채택한 다국어 검색 리트리버다. 아랍어, 독일어, 영어, 스페인어, 프랑스어, 이탈리아어, 일본어, 한국어, 노르웨이어, 포르투갈어, 스웨덴어를 포함한 11개 언어의 다국어·교차언어 검색을 지원하며, 엣지 디바이스까지 배포 범위를 넓혔다.

단일 벡터 검색과 토큰 단위 검색의 차이

두 리트리버는 LFM2.5-350M-Base를 공통 기반으로 사용하지만, 검색 품질과 인프라 비용을 다루는 방식은 다르다. 하나는 문서를 단일 벡터로 압축하고, 다른 하나는 토큰별 벡터를 유지한다.

LFM2.5-Embedding-350M: 빠른 후보 검색

Dense Bi-Encoder는 CLS 스타일 풀링으로 쿼리와 문서를 각각 단일 고밀도 벡터로 만든다. 검색 시에는 코사인 유사도 또는 내적(Dot Product)을 계산한다.

문서당 벡터가 하나이므로 벡터 데이터베이스 인덱스를 작게 유지할 수 있다. 대규모 컬렉션에서도 ANN(Approximate Nearest Neighbor) 검색에 유리하며, Liquid AI 엔터프라이즈 스택 기준 엔드투엔드 검색 지연시간은 1.5ms 수준이다.

LFM2.5-ColBERT-350M: 정밀한 토큰 매칭

ColBERT 방식은 문서 토큰을 각각 벡터로 인코딩한다. 질의 토큰 벡터와 문서 토큰 벡터의 MaxSim(Maximum Similarity) 연산으로 관련도를 계산하는 Late-Interaction 구조다.

이 방식은 단어 수준의 정밀한 매칭을 제공해 동일 기반 임베딩보다 높은 검색 정확도와 도메인 일반화(Generalization)를 목표로 한다. 반면 문서당 벡터 수가 토큰 수에 비례하므로, Dense 방식보다 인덱스와 스토리지 비용이 커진다.

학습 파이프라인과 배포 포맷

두 모델은 공통된 학습 과정을 거친 뒤, 각기 다른 인코딩 헤드로 분기한다.

⤢✕

초기 단계에서는 영어 중심의 대규모 대조 학습(Contrastive Learning)으로 임베딩 공간을 만든다. 이어 강력한 Teacher 모델에서 11개 언어의 다국어·교차언어 지식을 증류(Distillation)한다. 마지막으로 하드 네거티브(Hard Negative)를 사용한 파인튜닝을 적용해 경계 사례의 변별력을 높인다.

Liquid AI는 두 모델의 GGUF 양자화 버전도 Hugging Face에 공개했다. llama.cpp와 호환되는 GGUF 포맷은 CPU 전용 추론, 랩톱, 스마트폰, 임베디드 디바이스처럼 GPU가 없는 환경에서도 실행할 수 있다. BGE-M3 570M, E5-multilingual-large 560M 같은 대형 임베딩 모델이 엣지 배포에서 마주하는 메모리와 연산 제약을 줄이는 배포 경로다.

검색 품질과 운영 제약에 따른 선택

항목	LFM2.5-Embedding-350M	LFM2.5-ColBERT-350M
인코딩 방식	문서당 단일 벡터(CLS 풀링)	토큰당 개별 벡터(MaxSim)
인덱스 크기	최소 (소)	토큰 수 비례 (대)
검색 지연시간	매우 낮음 (1.5ms 급)	상대적으로 높음
정확도	높음	더 높음 (토큰 수준 매칭)
적합 유스케이스	제품 카탈로그, FAQ, 실시간 추천	법률·의료 문서, 복잡 질의응답
엣지 배포 적합성	최상	양호 (GGUF 사용 시)

모바일이나 IoT에서 즉시 응답해야 하는 검색은 LFM2.5-Embedding-350M 쪽이 맞는다. llama.cpp 백엔드에서 GGUF 모델을 구동하고, FAISS 또는 HNSW 기반 로컬 인덱스에 문서 임베딩을 캐시하는 구성이 가능하다. 지원 언어를 감지해 교차언어 쿼리를 처리하고, 실시간 단일 쿼리 처리에는 inference batch=1 설정을 사용한다.

반대로 복잡한 질의와 토큰 수준의 정밀 매칭이 중요하고 스토리지를 확보할 수 있다면 LFM2.5-ColBERT-350M이 적합하다. 두 방식을 분리하지 않고 결합할 수도 있다. 엣지 레이어에서 LFM2.5-Embedding-350M으로 1차 후보 검색(Recall)을 수행한 뒤, 클라우드 레이어에서 LFM2.5-ColBERT-350M 또는 크로스인코더(Cross-Encoder)로 재순위화(Reranking)하는 구조다. 이 구성은 전체 지연시간을 낮추면서 최종 검색 품질을 높인다.

외부 API 호출이 어려운 GDPR, 개인정보보호법 준수 환경에서는 온프레미스 배포가 직접적인 선택지가 된다. 350M 모델의 소형 풋프린트는 단일 CPU 서버에서 사내 문서 검색, 다국어 고객지원, 글로벌 규정 준수 문서 검색을 구성하는 데 사용할 수 있다. 모델은 LFM Open License v1.0으로 공개돼 상업적 활용도 가능하다.

경쟁 모델과 배포 관점 비교

모델	파라미터	다국어 지원	NanoBEIR 평균	MKQA-11 평균	엣지 배포
LFM2.5-ColBERT-350M	350M	11개 언어	최상위	최상위	GGUF 지원
LFM2.5-Embedding-350M	350M	11개 언어	상위	0.691 (상위)	GGUF 지원
Qwen3-Embedding-0.6B	600M	다국어	하위	하위	제한적
BGE-M3	570M	100+ 언어	상위	최상위급	제한적
E5-multilingual-large	560M	94개 언어	중상위	중상위	어려움

LFM2.5는 350M 파라미터 설계로 600M급 Qwen3-Embedding-0.6B보다 우수한 성능을 달성했다. NanoBEIR 다국어 검색과 MKQA-11 교차언어 개방형 QA에서 경쟁 모델을 앞서며, GGUF 양자화 지원은 엣지 환경에서 실용적인 선택지를 제공한다.

BGE-M3는 100개 이상 언어와 Dense·Sparse·ColBERT를 한 모델에서 지원하는 하이브리드 검색(Hybrid Search)이 강점이다. MTEB·C-MTEB 벤치마크에서도 최강 수준을 유지하지만, 570M 파라미터와 GGUF 미지원은 엣지 배포에 제약이 된다.

E5-multilingual-large는 94개 언어를 지원하고 생태계가 성숙했다. 다만 560M 파라미터에 엣지 최적화가 없어 온프레미스와 엣지 환경에서는 LFM2.5보다 불리하다.

엣지·모바일·IoT에는 GGUF와 최소 풋프린트를 갖춘 LFM2.5-Embedding-350M이 맞다.
정확도를 우선하고 스토리지 여유가 있다면 LFM2.5-ColBERT-350M을 선택한다.
100개 이상 언어와 하이브리드 검색이 필요하면 BGE-M3를 검토한다.
광범위한 언어 커버리지와 클라우드 환경이 중심이면 E5-multilingual-large가 대상이다.

엣지 우선 RAG로 향하는 흐름

2026년은 파라미터 규모 경쟁보다 효율성 경쟁이 부각되는 시기다. LFM2.5처럼 350M 모델이 600M급 경쟁 모델을 능가하는 사례는 경량 특화 모델의 가능성을 보여준다. 엣지 AI 칩(NPU, 모바일 SoC) 성능 향상과 함께 다국어 검색 리트리버의 온디바이스 배포는 2026년 하반기 이후 폭발적으로 확산될 것으로 전망된다.

클라우드 중심 RAG도 엣지-퍼스트(Edge-First) 구조로 옮겨갈 수 있다. 모바일 앱 내장형 다국어 검색, 오프라인 지원 글로벌 고객지원, 프라이버시 보존형 기업 문서 검색은 그 대상이다.

공식 지원 언어에 한국어가 포함된 점도 의미가 있다. 한국어는 교착어(Agglutinative Language)라 토큰화 복잡성이 높고 교차언어 검색에서 취약한 편이었다. ColBERT의 토큰 수준 MaxSim은 이 특성에 특히 효과적으로 작용하며, 국내 기업의 다국어 검색 도입 장벽을 크게 낮출 것으로 기대된다.

GGUF 포맷 표준화, llama.cpp 생태계 확장, Hugging Face 중심의 오픈소스 공개는 경량 다국어 리트리버 생태계를 빠르게 성숙시키고 있다. 향후 LFM2.5 계열에는 Sparse(BM25 스타일) 검색 결합, Reranker 통합, 멀티모달 검색 확장이 이루어질 것으로 예측된다.