LFM3의 d1-2B: 답변 생성 대신 문의 분류를 맡기는 법

새 모델에서 먼저 고를 것은 출력의 종류다

Liquid AI는 2026년 10월 27일 LFM3 계열을 공개했다. 텍스트·시각·음성·여러 입력을 함께 받는 omni 모델과 결정 모델을 공통 기반에서 파생시키고, 용도에 맞는 모델을 고르도록 구성했다. 이 글은 그중 텍스트 생성 모델 LFM3-1.7B와 시각·텍스트 결정 모델 d1-2B를 문의 처리에 배치하는 문제에 집중한다. Liquid AI의 공식 공개 글

발표에서 말하는 공통 기반이 모든 모델의 기능과 한계가 같다는 뜻은 아니다. 10월 29일 확인한 텍스트 모델 카드는 입력과 출력을 합친 256K 문맥을 명시한다. 반면 d1-2B 카드는 128K 문맥이며, 상태가 약 64K 토큰을 넘으면 답의 신뢰도가 낮아진다는 제한도 적었다. 사양표의 최대 길이를 그대로 권장 업무 길이로 읽어서는 안 된다. 이 글의 조사 버전은 텍스트 모델 ac2586a, d1-2B cfe5760이며 모델을 직접 실행하지 않았다. 텍스트 모델 카드 · d1-2B 모델 카드

문의 처리에 필요한 결과	먼저 비교할 방식	구체적인 질문
공개 도움말을 바탕으로 답장 작성	생성 모델과 검색	어떤 설명을 어떤 순서로 쓸까?
결제·배송·기술 담당 중 하나 선택	규칙 또는 결정 모델	누가 먼저 맡아야 할까?
문의에 포함된 여러 주제 표시	복수 선택 분류	결제와 배송 문제가 함께 있는가?
이미 입력된 주문 상태에 따른 배정	기존 프로그램 규칙	상태 코드가 어느 분기로 가는가?

마지막 행은 모델이 없어도 해결할 수 있다. 결정 모델의 후보 영역은 표현이 제각각인 문의에서 의미를 읽어 정해진 업무 질문에 답하는 부분이다. 자유로운 설명이 필요하면 생성 모델이 남고, 이미 확정된 규칙은 코드로 처리한다. 이 역할 분담은 특정 모델의 성능 순위가 아니라 이 글에서 제안하는 설계 기준이다.

LFM3-1.7B는 도구 호출·구조화 출력·분야별 조정을 목표로 하지만, 공식 카드도 작은 규모 때문에 복잡한 다단계 추론과 에이전트 코딩에는 권장하지 않는다고 적었다. 따라서 “로컬 에이전트용”이라는 설명만으로 범용 코딩 에이전트의 대체재라고 판단하기 어렵다. 권장 용도와 제한

d1은 분류 결과를 문장으로 이어 쓰지 않는다

d1-2B는 LFM3-VL-2B를 기반으로 한 약 19억 파라미터의 결정 모델이다. 공식 인터페이스는 읽을 자료인 state와 이름을 붙인 질문들인 questions를 받아 자료형이 정해진 답을 반환한다. 모델이 답변 토큰을 차례로 생성하는 대신 forward pass에서 답을 읽는 구조이며, 응답의 usage.output_tokens는 0이다. 프로그램이 받는 응답 객체가 없다는 뜻은 아니다. 입력·출력 계약

한 문의에 “담당 부서”, “포함된 주제”, “긴급 여부”를 함께 물으면 같은 자료를 바탕으로 서로 다른 답을 얻는다. 긴 답변을 생성한 뒤 부서 이름을 다시 파싱하는 절차를 줄일 수 있다는 것이 이 구조의 장점이다. 실제로 얼마나 빨라지는지는 입력 길이·질문 묶음·실행 장치에 달려 있다.

특히 출력 토큰 0은 연산 비용 0이 아니다. 입력을 읽는 계산과 메모리, 이미지가 있으면 이미지 처리도 필요하다. 카드의 set_size는 상태 뒤에서 함께 읽는 질문 묶음 크기를 조절하며, 학습된 기본값은 16이다. 더 큰 값은 빠를 수 있지만 텍스트 정확도를 일부 희생한다고 명시한다. 질문 수를 무제한으로 늘려도 비용과 정확도가 같다고 해석하지 않았다. 호출 옵션

공식 속도 표도 같은 점을 보여 준다. 컴파일 후의 준비된 호출과 긴 상태·이미지·여러 질문을 각각 나누어 제시한다. 따라서 표 맨 앞의 짧은 한 질문 지연을 앱 전체의 첫 응답 시간으로 옮기면 안 된다. 여기서는 공급자 속도 수치를 재측정하지 않았으며, 다운로드·초기화·대기열·후속 답장 작성까지 포함한 체감 속도는 미확인이다.

담당 하나와 주제 여러 개는 다른 확률이다

가상의 온라인 업무 도구 지원팀을 생각해 보자. 첫 담당은 계정, 결제, 기술, 분류 보류 중 하나로 정한다. 주제 태그는 로그인, 청구, 장애가 동시에 붙을 수 있다. 긴급 여부는 “현재 여러 사용자의 필수 업무가 막혔는가”라는 별도 질문으로 정한다. 이 분류 체계는 설명을 위해 만든 것이며 특정 회사의 운영 정책이 아니다.

출력 유형	d1 카드의 계약	문의 사례에서 읽는 방법
choice	선택 결과·confidence·선택지별 probabilities	서로 배타적인 첫 담당 중 하나를 고름
choice와 multiple: true	선택 목록·각 항목의 P(yes)	로그인과 청구 태그가 함께 해당할 수 있음
noul	예에 해당할 확률 P(yes)	정의한 긴급 조건에 해당할 가능성을 읽음
score	순서가 있는 등급의 중앙값·확률·legend	낮음·보통·높음 등 정한 순서 안에서 해석

공식 질문 유형에 따르면 복수 선택의 각 확률은 해당 태그 자체의 P(yes)다. 따라서 태그들의 확률을 합쳐 1이 되게 정규화하거나, 가장 큰 태그 하나만 남기면 원래 묻던 질문이 바뀐다. 반대로 첫 담당을 하나만 정해야 하는데 복수 태그 결과를 그대로 배정에 쓰면 책임자가 여러 명으로 갈릴 수 있다.

이 차이를 입력 단계에서 드러내는 시험 자료는 다음처럼 만들 수 있다. 아래 기대 결과는 사람이 정한 시험 기준이며 d1 응답이 아니다.

직접 만든 가상 문의	시험에서 확인할 구분
“청구서가 두 번 왔고, 오늘부터 직원 모두 로그인이 안 됩니다.”	첫 담당 하나와 청구·로그인 두 주제를 함께 표현할 수 있는가
“내일 보고서에 넣을 로그인 오류 해결 방법을 알고 싶습니다.”	‘내일’이라는 단어만으로 현재 장애라고 판단하지 않는가
“아까는 모두 접속을 못 했지만 지금은 복구됐습니다. 원인을 알려 주세요.”	과거 장애와 현재 긴급 상태를 구분하는가
“안 돼요. 빨리 봐 주세요.”	사용자 수·영향·현재 상태가 부족함을 별도 처리하는가

마지막 문의에는 확률만으로 해결할 수 없는 정보 공백이 있다. 분류 보류를 선택지에 포함하거나, 필수 정보가 없으면 추가 질문으로 넘기는 규칙을 둘 수 있다. 이는 모델이 제공하는 모든 불확실성 문제를 해결하는 장치가 아니라, 질문에 답할 자료가 부족한 경우를 업무에서 표현하는 방법이다.

확률이 0.8이면 그 문의는 80%만 긴급한가

확률 보정은 비슷한 확률을 받은 여러 사례에서 실제 비율이 그 값과 맞는지를 보는 개념이다. 예를 들어 긴급 확률을 약 0.8로 받은 사례들을 모았을 때 실제 긴급 사례가 약 80%인지 확인한다. 개별 문의가 “80%짜리 장애”라는 뜻도, 이번 판단이 반드시 맞다는 뜻도 아니다. scikit-learn의 확률 보정 설명

Liquid AI는 d1을 보정된 답을 내는 모델로 설명하지만, 카드에서도 업무 자료로 임계값을 보정하라고 명시한다. 한국어 지원 언어 목록에 들어 있다는 사실만으로 우리 회사의 줄임말·과거 장애·복합 문의에서도 같은 보정 상태가 유지된다고 볼 수 없다.

가령 전체 문의의 대부분이 평상시 사용법이라면 높은 전체 정확도만으로 긴급 분류의 품질을 알기 어렵다. 도입 평가는 실제 긴급을 놓친 건수, 정상 문의를 긴급으로 올린 건수, 검토로 보낸 양을 나누어야 한다. 확률 구간별 실제 긴급 비율도 함께 보되, 각 구간의 표본 수가 적으면 보정이 좋다거나 나쁘다고 성급히 단정하지 않는다. 이는 아래 비용 계산을 실제 정책으로 바꾸기 위한 전제다.

같은 확률이라도 실수의 비용이 다르면 행동이 바뀐다

다음은 임계값의 의미를 이해하기 위한 가상 비용 계산이다. d1 측정 결과나 보편적인 권장 기준이 아니다. 긴급 확률을 p라 하고, 올바르게 분류한 추가 비용은 0이라고 놓는다. 정상 문의를 긴급으로 올리면 2, 실제 긴급을 일반 대기열로 보내면 18의 비용이 든다고 가정한다. 단위는 원이나 분이 아닌 비교용 비용 점수다.

• 긴급 대기열로 보내는 기대 비용: 2 × (1 - p)
• 일반 대기열로 보내는 기대 비용: 18 × p

두 비용이 같아지는 곳은 p = 2 ÷ (2 + 18) = 0.1이다. 두 행동만 있다면 0.5가 아니라 0.1부터 긴급 분류를 선택할 이유가 생긴다. 긴급을 놓치는 비용이 더 크기 때문이다. 반대로 긴급 대기열이 과부하돼 잘못 올리는 비용이 커지면 경계는 높아진다.

여기에 “사람이 검토하면 항상 맞게 분류하고 비용은 1”이라는 단순한 가정을 추가해 보자. 세 비용 중 가장 작은 것을 고르면 일반 분류는 p ≤ 1/18, 긴급 분류는 p ≥ 1/2, 그 사이는 사람 검토가 유리하다. 경계에서는 비용이 같으므로 동점 처리 규칙을 별도로 정한다.

가정한 긴급 확률 p	긴급 비용	일반 비용	검토 비용	이 가정에서 가장 낮은 비용의 행동
0.02	1.96	0.36	1	일반
0.08	1.84	1.44	1	검토
0.20	1.60	3.60	1	검토
0.60	0.80	10.80	1	긴급

이 표는 “확률이 낮으면 검토, 높으면 자동”이라는 막연한 방식을 구체화한다. 특히 p=0.08은 두 행동만 비교하면 일반 분류지만, 검토를 허용하면 판단이 바뀐다. 분류 모델의 출력이 같아도 팀의 처리 방식이 달라지면 최선의 행동이 달라질 수 있다. 식과 표는 Python의 유리수 계산으로 검산했으며 가정과 계산 결과에 입력을 함께 남겼다.

실제로 사람도 틀리고 검토가 지연된다. 한 사람이 하루에 볼 수 있는 문의 수가 제한되면 고정 비용 1도 성립하지 않는다. 긴급 확률이 잘못 보정됐거나, 현재 처리량에 따라 오류 비용이 달라져도 위 숫자를 그대로 사용할 수 없다. 이 경우에는 대표 자료에서 비용·대기·오류를 함께 평가하고 기준을 다시 정해야 한다. 위 계산이 주는 것은 배포할 숫자가 아니라 무엇을 비교해야 하는지 보여 주는 식이다.

먼저 분류 한 단계만 바꿔 비교한다

도입 첫 시험에서는 기존 규칙이나 기존 생성 모델 분류와 d1에 같은 문의 묶음을 주는 편이 좋다. 첫 담당·태그·현재 긴급 여부의 정답을 따로 만들고, 정보 부족 문의는 억지로 정답 부서를 붙이지 않는다. 기준을 조정하는 자료와 마지막 평가 자료도 분리한다. 같은 문의의 표현만 조금 바꾼 사본이 양쪽에 섞이면 처음 보는 문의에 대한 평가가 아니다.

출력은 담당자 이름 하나만 저장하지 않고 질문 정의의 버전과 선택지별 확률까지 남긴다. 긴급 누락과 잘못된 승격, 검토량을 함께 세면 “더 많이 자동 처리했지만 놓친 장애도 늘었다” 같은 교환관계를 볼 수 있다. 답장 생성은 같은 경로로 유지해야 분류기를 바꾼 효과를 구분하기 쉽다. 이 절차는 아직 실행하지 않은 도입 제안이다.

운영 환경에서는 모델 ID와 가중치 버전뿐 아니라 공식 카드가 요구하는 사용자 정의 모델 코드·Transformers 경로도 확인해야 한다. 단순히 일반 채팅 endpoint에 이름을 넣는 것과 system_one의 결정 결과를 받는 것은 같은 실행 검증이 아니다. 로컬 가중치를 이용할 수 있다는 사실도 연결된 검색·로그·도구까지 모두 로컬에서 처리한다는 보장은 아니다.

라이선스 역시 확인할 항목이다. 두 조사 모델은 LFM Open License v1.0을 사용하며, 이 라이선스에는 매출 기준에 따른 상업 사용 제한과 재배포 조건이 있다. 공개 가중치라는 설명을 무제한 상업 이용 허가로 바꾸지 말고, 도입 주체와 사용 방식에 대해 원문 조건을 대조해야 한다. 조사 버전의 라이선스

다음 기록을 채우면 모델의 장점과 팀의 운영 부담을 같은 표에서 검토할 수 있다. 빈칸은 아직 관측하지 않은 값이다.

모델/가중치 버전 · 실행 장치/라이브러리 · 질문 정의 버전:
자료 기간/언어/중복 제외 기준 · 기준 조정용/최종 평가용 구분:
첫 담당 정확/오류 · 태그별 누락/오탐 · 정보 부족 처리:
실제 긴급 누락 __건 · 정상의 긴급 승격 __건 · 검토 __건:
확률 구간별 건수/실제 긴급 비율:
오류 비용 가정 · 검토 오류/대기/처리 용량:
초기 응답/준비된 호출 시간 · 전체 문의 처리 시간:
유지할 기존 경로 · 부분 도입 범위 · 되돌릴 조건:

d1의 실용적인 후보 영역은 답의 종류가 분명하고 반복해서 판정해야 하는 단계다. 고객에게 설명할 문장까지 필요하면 생성 모델을 함께 쓰고, 정확한 규칙이 이미 있으면 규칙을 남긴다. 작은 모델을 도입할지는 공급자의 최고 점수보다 같은 문의에서 얻은 분류 품질·검토량·전체 처리 비용으로 결정할 수 있다.

문서의 값을 읽는 일과 미래를 추정하는 일의 차이는 Clairic의 값 추출 분석에서, 분류 뒤 답장·루틴·중단 복구를 잇는 업무 흐름은 Grok Bot 문의 처리 분석에서 이어 읽을 수 있다. 위 비용식과 기록을 다시 쓸 때는 글 상단의 저장 기능을, 다른 모델 분석을 찾을 때는 AI 시스템 모음과 RSS를 이용할 수 있다.