Liquid AI LFM2.5 엣지 다국어 검색: Dense와 ColBERT 선택 기준

엣지 검색을 겨냥한 LFM2.5 리트리버

Liquid AI는 2026년 6월 LFM2.5-Embedding-350M과 LFM2.5-ColBERT-350M을 공개했다. 두 모델은 아랍어·독일어·영어·스페인어·프랑스어·이탈리아어·일본어·한국어·노르웨이어·포르투갈어·스웨덴어를 지원한다. 350M 파라미터로 고속 다국어 검색과 엣지 기기의 온디바이스 추론을 함께 겨냥한 모델이다.

이 리트리버들은 2026년 3월 공개된 LFM2.5-350M-Base에서 출발한다. 기반 모델은 28조 토큰으로 사전학습됐으며, 검색 작업에 맞춘 파인튜닝을 거쳐 두 변형으로 나뉘었다. 같은 패밀리에는 1.2B Instruct 모델도 포함돼 있어 리트리버와 리더를 분리한 검색-생성 파이프라인을 구성할 수 있다.

Embedding 모델은 문서 하나를 고정 차원의 벡터 하나로 압축하는 Dense Bi-Encoder다. 인덱스가 작고 검색 지연을 낮추기 쉽다. 반면 ColBERT 모델은 문서의 각 토큰을 벡터로 표현하는 Late-Interaction 구조다. 쿼리와 문서를 단어 수준에서 대조할 수 있어 정확도와 일반화 성능에 유리하다.

두 모델은 Liquid AI의 하이브리드 LFM(Liquid Foundation Model) 아키텍처를 적용한 첫 양방향 검색 모델이다. 공개 발표에서 Liquid AI 엔터프라이즈 스택의 종단 간 검색 지연은 1.5ms 수준까지 가능하다고 밝혔다.

컨볼루션과 어텐션을 섞은 내부 구조

LFM2.5 리트리버는 Transformer 블록만 쌓은 모델과 구성이 다르다. 전체 17개 레이어에는 이중 게이트 단거리 LIV 컨볼루션 블록 10개, 그룹 쿼리 어텐션(GQA) 블록 6개, 풀링 또는 Dense 레이어 1개가 배치된다.

레이어 유형	개수	담당 기능
이중 게이트 단거리 LIV 컨볼루션 블록	10	지역 시퀀스 패턴 포착과 효율적인 CPU 연산
그룹 쿼리 어텐션(GQA) 블록	6	장거리 의존성과 문맥 처리
풀링 / Dense 레이어	1	모델 유형에 따른 문서 벡터 집계

컨볼루션 블록은 가까운 범위의 패턴을 처리하고 GQA 블록은 더 긴 문맥 의존성을 맡는다. 이 혼합 구조는 순수 어텐션 구조보다 CPU 프리필·디코드 속도를 최대 2배 높인다. GPU를 쓰기 어려운 모바일·IoT 환경에서 의미 있는 차이다.

GGUF 포맷과 llama.cpp를 통한 CPU 전용 실행을 지원하며, 캐싱을 적용하면 p50 쿼리 지연이 10ms 미만으로 측정된다.

⤢✕

다국어 검색 성능을 만드는 학습 과정

학습은 영어 대조 사전학습, 다국어·교차언어 지식 증류, 하드 네거티브 파인튜닝의 세 단계로 진행된다.

먼저 대규모 영어 코퍼스에서 컨트라스티브 러닝을 수행한다. 쿼리와 관련 문서로 구성한 양성 쌍, 그리고 배치 안의 음성 샘플을 이용해 의미론적 임베딩 공간의 기초를 만든다. 영어 검색 성능의 상한선이 이 과정에서 결정된다.

다음에는 교사 모델의 지식을 11개 지원 언어에 증류한다. 같은 언어 안에서의 검색뿐 아니라 한국어 쿼리로 영어 문서를 찾는 교차언어 검색도 이 단계에서 학습한다. 이 과정은 MKQA-11 성능을 뒷받침한다.

마지막 파인튜닝에는 하드 마이닝한 음성 샘플을 사용한다. 모델이 쉽게 구분할 수 있는 문서 대신 의미는 비슷하지만 실제로는 관련 없는 문서를 학습에 넣어 검색 결과의 변별력을 높인다.

벤치마크에서 드러난 Dense와 ColBERT의 차이

NanoBEIR ML과 MKQA-11 결과에서는 ColBERT 변형이 Embedding 변형보다 앞선다.

모델	파라미터	NanoBEIR ML	MKQA-11 (Recall@20)
LFM2.5-ColBERT-350M	350M	0.605	0.694
LFM2.5-Embedding-350M	350M	0.577	0.691
Qwen3-Embedding-0.6B	600M	(하회)	(하회)
LFM2-ColBERT-350M (구버전)	350M	0.540	-

LFM2.5-ColBERT-350M의 NanoBEIR ML 점수는 이전 LFM2-ColBERT-350M의 0.540에서 0.605로 약 12% 향상됐다. 파라미터가 600M인 Qwen3-Embedding-0.6B도 350M 모델로 상회한다.

NanoBEIR는 BEIR 전체 벤치마크의 실용적 대리 지표로 사용된다. 두 벤치마크 사이에는 높은 상관관계가 있으며, NanoBEIR 점수가 약 15% 높은 일정한 오프셋이 존재한다.

정확도만으로 리트리버를 고를 수는 없다. 두 방식은 인덱스 구조와 배포 조건에서 뚜렷한 차이를 보인다.

판단 항목	Dense Bi-Encoder	ColBERT Late-Interaction
인덱스 크기	작음, 문서당 1벡터	큼, 토큰당 1벡터
검색 지연	더 낮음	상대적으로 높음
검색 정확도	높음	더 높음
일반화 성능	보통	우수
엣지 적합성	매우 적합	인덱스 크기로 인해 제한적
적합한 환경	모바일·IoT 실시간 검색	정확도 우선 기업 검색

BGE-M3와 multilingual-e5 사이에서 고르기

BGE-M3는 약 570M 파라미터로 Dense, Sparse, Multi-vector 검색을 한 모델에서 지원한다. 지원 언어도 100개 이상이어서 언어 범위가 넓고, MTEB 다국어 리더보드에서 일관된 강세를 보여 왔다.

비교 항목	LFM2.5-Embedding-350M	LFM2.5-ColBERT-350M	BGE-M3 (~570M)
파라미터	350M	350M	~570M
지원 언어	11개	11개	100개 이상
검색 방식	Dense only	Late-Interaction	Dense + Sparse + Multi-vector
엣지 배포	GGUF 공식 지원	GGUF 공식 지원	제한적
특화 강점	속도·경량성	정확도·일반화	광범위한 언어 커버리지

LFM2.5가 BGE-M3와 구별되는 지점은 GGUF 기반 CPU 추론과 1.5ms 지연이다. 100개 언어 지원이 필요하면 BGE-M3가 우세하다. 대상이 LFM2.5가 지원하는 11개 언어이고 엣지 배포가 우선이라면 LFM2.5 쪽이 더 적합하다.

Microsoft의 multilingual-e5 시리즈는 109개 언어를 지원하는 Dense Bi-Encoder 계열이다. 범용 다국어 임베딩 작업에서 안정적인 성능을 제공하지만, 엣지 최적화와 Late-Interaction 지원은 포함하지 않는다. LFM2.5의 언어 범위는 더 좁지만, 해당 11개 언어에서는 학습 방식과 아키텍처 최적화를 바탕으로 경쟁력 있는 성능을 보인다.

기기 제약부터 모델을 고른다

엣지 배포에서는 정확도보다 먼저 메모리와 저장 공간을 확인해야 한다. 350M 모델은 FP16 기준 약 700MB의 메모리를 사용한다. GGUF Q4_K_M 양자화를 적용하면 약 200MB 수준으로 줄어 메모리가 1GB 미만인 저사양 기기에서도 실행할 수 있다.

인덱스 크기도 선택을 가른다. Dense Bi-Encoder는 문서 수와 임베딩 차원에 비례하는 인덱스가 필요하다. ColBERT는 문서의 토큰 수와 임베딩 차원에 따라 인덱스가 커지므로 같은 코퍼스에서도 크기가 수십 배에 이른다. 저장 공간이 크게 제한된 IoT 기기에는 Embedding 모델이 맞는다.

응답 지연이 중요한 모바일 인터페이스에서는 CPU 온디바이스 추론과 캐싱을 적용했을 때 p50 기준 10ms 미만이라는 결과를 판단 근거로 삼을 수 있다. 언어 범위도 별도로 확인해야 한다. 태국어·힌디어처럼 지원 11개 언어 밖의 언어가 필요하면 BGE-M3 또는 mE5를 검토해야 한다.

모바일과 IoT에 검색 인덱스를 배포하는 방식

온디바이스 검색에서는 문서 인덱스를 서버에서 만들고 쿼리만 기기에서 처리하는 구성이 가능하다.

서버는 LFM2.5-Embedding-350M으로 문서 벡터를 생성한 뒤 FAISS 또는 SQLite-VSS 형식으로 패키징해 기기에 배포한다. 사용자가 검색하면 기기의 llama.cpp 또는 GGUF 런타임이 쿼리 벡터를 실시간으로 만들고, 로컬 벡터 인덱스에서 ANN(Approximate Nearest Neighbor) 검색을 수행한다. 새 문서는 서버에서 배치 처리한 후 전체 인덱스 대신 인덱스 패치만 동기화한다.

이 구조는 연결이 불안정해도 로컬 코퍼스를 검색할 수 있다는 점에서 오프라인 우선 애플리케이션에 맞는다.

엣지 검색과 클라우드 재랭킹의 결합

로컬 처리만으로 모든 검색 요구를 충족하기 어렵다면 Embedding과 ColBERT의 역할을 분리할 수 있다.

[기기 / 엣지]
  LFM2.5-Embedding (경량·빠름)
  → 로컬 코퍼스 ANN 검색
  → 오프라인 우선 동작

[클라우드 / 온프레미스]
  LFM2.5-ColBERT (고정확·재랭킹)
  → 전체 코퍼스 정밀 검색
  → 네트워크 가용 시 폴백

기기에서는 LFM2.5-Embedding으로 빠르게 로컬 후보를 찾는다. 네트워크를 사용할 수 있을 때는 클라우드나 온프레미스의 LFM2.5-ColBERT가 전체 코퍼스를 정밀 검색하거나 결과를 재랭킹한다.

이 패턴은 Azure Edge RAG 아키텍처와 유사하다. GDPR이나 PIPA처럼 데이터 프라이버시 규정이 강한 환경에서는 민감한 데이터를 기기 밖으로 내보내지 않는 구성에도 활용할 수 있다.

기업 문서 검색으로 확장하는 순서

기업 내부 검색에 적용할 때는 먼저 주요 언어 2-3개의 문서 코퍼스에서 LFM2.5-Embedding 기반 Dense 검색을 구축하고, 기존 BM25와 검색 품질을 A/B 테스트한다.

그다음 범위를 11개 언어 전체 코퍼스로 넓혀 교차언어 검색을 검증한다. 정확도를 더 높여야 한다면 LFM2.5-ColBERT를 재랭킹 레이어로 추가해 Precision을 개선한다. 생성 단계까지 필요할 때는 LFM2.5-1.2B-Instruct를 연결해 Retriever-Reader RAG 파이프라인으로 확장할 수 있다.

이 모델을 이해하려면 현대 정보검색의 계보도 함께 볼 필요가 있다. Boolean 모델, VSM(Vector Space Model), 확률적 검색 모델을 거쳐 Dense Retrieval, Learned Sparse, Late-Interaction으로 발전한 흐름에서 LFM2.5는 Dense와 Late-Interaction을 각각 별도 배포 옵션으로 제공한다.

FAISS·HNSW·IVF 같은 ANN 인덱스는 리트리버가 만든 벡터를 실제 검색 시스템에 연결한다. 다국어 검색 품질은 대조 학습, 지식 증류, 하드 네거티브 학습에서 만들어지며, 엣지 운영에서는 양자화·GGUF·온디바이스 추론과 엔드포인트 보안까지 함께 다뤄야 한다.

저장 공간과 지연이 우선이면 LFM2.5-Embedding-350M이 출발점이다. 더 큰 인덱스를 감수할 수 있고 검색 정확도와 일반화가 중요하면 LFM2.5-ColBERT-350M이 맞는다. 두 모델을 엣지와 클라우드에 나눠 배치하면 로컬 프라이버시, 오프라인 검색, 고정확 재랭킹을 하나의 파이프라인에서 조합할 수 있다.