Fastino, GLiNER2.5 공개…개체 추출 길이 제한 없애

GLiNER2.5는 구간을 나열하는 대신 토큰 경계에서 시작과 끝 점수를, 토큰 내부에서는 내부 점수를 예측해요. 공유 인코더가 텍스트와 스키마 질의를 한 번에 처리하는 건 그대로지만, 그 다음 단계가 달라졌어요. 희소 제안 단계가 질의마다 가장 유력한 시작·끝 지점을 골라 거리 제한 없이 짝짓고, 재순위 결정 단계가 경계 증거와 구간 내용을 함께 봐서 최종 점수를 매기는 구조예요. 관계 추출 후보도 같은 풀에서 뽑아 쓰기 때문에 별도 경로를 안 타요.

이 변화 하나로 개체 길이의 상한이 사라졌고, Fastino 팀은 고정된 스키마와 후보 예산 안에서는 연산량이 문장 길이에 비례해 선형으로 늘어난다고 설명했어요.

새로 생긴 다섯 가지 기능

구간을 명시적으로 나열하지 않으니 메모리 여유가 생겼고, 그 덕에 최대 4,096단어까지 학습·추론이 가능해졌어요. 긴 문서를 처리하는 청킹 도구(extract_entities_long, extract_long 등)도 함께 들어왔는데, 잘린 조각에서 찾은 구간을 원문 문서의 문자 위치로 다시 매핑해줘요.

개체 길이 제한도 없어졌어요. 이전에는 열두 단어 안팎이 한계였다면, 이번에는 첫 토큰에서 열려 마지막 토큰에서 닫히는 구간도 두 단어짜리 이름과 같은 비용으로 찾아내요. 여기에 개체 타입과 관계, unique_head=True 같은 구조 규칙을 선언하면 빔 서치가 스키마에 어긋나지 않는 그래프를 조립해주는 결합 추출 기능도 붙었고요.

C.implies와 C.excludes 같은 규칙으로 서로 다른 작업의 라벨을 디코딩 단계에서 묶는 제약 분류도 새로 들어왔어요. Fastino의 가드레일 모델 GLiGuard를 예로 들면, 제약이 없을 때는 프롬프트 하나가 '안전'과 '프롬프트 인젝션 탐지'로 동시에 라벨링되는 모순이 생길 수 있는데, 이 기능이 그걸 막아줘요. 감정 같은 속성 그룹을 특정 개체 타입에 붙여 같은 순전파 안에서 함께 디코딩하는 구간 속성 기능도 함께 나왔어요.

세 가지 체크포인트, 벤치마크는 이렇게 나왔다

Fastino는 74M·194M·287M 파라미터의 체크포인트 3종을 Apache 2.0 라이선스로 허깅페이스에 올렸어요. 허깅페이스는 메타나 알리바바 같은 회사가 만든 공개 모델이 올라오는 유통 장터인데, Fastino도 여기에 자체 개발 체크포인트를 얹은 거예요.

모델	파라미터	인코더	언어
gliner2.5-small-v1	74M	DeBERTa-v3-xsmall	영어
gliner2.5-base-v1	194M	DeBERTa-v3-base	영어
gliner2.5-multi-v1	287M	mDeBERTa-v3-base	다국어

16개 제로샷 벤치마크 결과를 GLiNER2와 같은 크기끼리 비교했는데요, 다국어 모델의 전체 평균 macro F1은 56.17로 GLiNER2의 56.09보다 소폭 올랐고, 베이스 모델은 54.87로 53.34에서 뛰었어요.

항목	GLiNER2	GLiNER2.5
전체 평균(다국어)	56.09	56.17
전체 평균(베이스)	53.34	54.87
XNLI(다국어)	37.55	62.30
Few-NERD(베이스)	47.22	55.14

가장 큰 폭으로 오른 항목은 XNLI로, 다국어 모델이 37.55에서 62.30으로 24.75포인트 뛰었어요. 학습 데이터에 없던 언어인 루마니아어 RONEC 벤치마크도 두 크기 모두에서 개선됐다고 해요.

어떻게 써보나

체크포인트는 pip install "gliner2[local]" 명령으로 설치하는 로컬 패키지로 받을 수 있고, Python 3.10 이상 환경에서 CPU·CUDA·MPS 중 어느 쪽으로도 추론이 돌아가요. 다만 지금은 이 체크포인트를 대신 서빙해주는 추론 호스팅 서비스가 없어서, 직접 서버를 띄워 운영하는 자체 호스팅이 유일한 배포 경로예요.

모델을 불러올 때는 예전 GLiNER2의 구간 로더가 아니라 새로운 AutoExtractor를 써야 하는데요, 세 체크포인트 모두 같은 공개 API를 공유해요. 조직 규모에 따라 쓰임새도 갈리는데, 74M·194M 모델은 일반 CPU 서버에서 돌아가니 GPU 예산이 없는 소규모 팀도 추출 기능을 바로 붙일 수 있고, 규모가 큰 조직은 파인튜닝이 가능한 사내 호스팅 대안으로 볼 수 있어요. Fastino는 법무·계약 검토, 의료·임상 문서, 금융 서비스, 보험 청구, 고객 지원, AI 안전 도구 분야를 적용 산업으로 꼽았고, 개인정보 탐지·비식별화, 계약 조항 추출, 에이전트 메모리용 지식 그래프, 모델 라우팅, 가드레일 분류, 부정어와 용량 속성을 포함한 임상 개체 추출을 구체적 활용 예로 들었어요.

에디터의 시선

이번 발표에서 눈여겨볼 대목은 벤치마크 점수 자체보다 '무엇에 비용을 안 쓰게 됐는가'예요. 대형 언어 모델로 정보 추출을 돌리면 문서 한 장, 토큰 하나마다 비용이 붙는데, GLiNER2.5는 그 비용 구조를 아예 다른 축으로 옮겼어요. 개체 길이가 계산량과 무관해졌다는 건, 실무에서 마흔 단어짜리 계약 조항과 두 글자 이름을 똑같은 비용으로 처리할 수 있다는 뜻이고, 이건 대형 모델을 통째로 돌리는 팀 입장에서는 무시하기 어려운 차이예요.

이런 크기의 오픈 모델을 실무에 붙여 보면 결론이 늘 비슷해요. 벤치마크 평균 점수는 한두 포인트 차이로 요란하지 않지만, 실제 업무에 쓰이는 특정 유형(긴 조항, 다국어 문서)에서만 골라보면 체감 차이가 훨씬 크다는 점이에요. XNLI에서 24.75포인트가 뛴 것도 '평균'만 보면 지나치기 쉬운 숫자지만, 다국어 문서를 다루는 팀이라면 이건 모델을 갈아탈 만한 근거가 돼요.

국내 팀 입장에서 실무 기준선을 잡자면, GPU 예산이 없는 2~3인 규모 팀이라면 74M·194M 체크포인트로 CPU만으로 개인정보 탐지나 계약 조항 추출을 먼저 붙여보는 게 합리적이에요. 다국어 문서, 특히 한국어가 섞인 문서를 다룬다면 287M 다국어 체크포인트의 실제 정확도를 자체 데이터로 먼저 검증해보는 편이 낫고요. 다만 지금은 별도 호스팅 서비스가 없어서 인프라팀 없이 바로 서비스에 붙이기는 아직 이르다는 점도 함께 봐야 해요.

앞으로 몇 주 안에는 추론 제공업체 쪽에서 이 체크포인트를 호스팅 옵션으로 올릴지가 관전 포인트예요. 자체 호스팅 부담이 줄어드는 순간, 소규모 팀의 채택 속도가 확실히 빨라질 거예요.