고객 문의를 한 번에 분류하는 Liquid d1 작은 결정 모델의 실무 사용법

Liquid d1의 choice·noul·score를 고객 문의 분류에 적용하는 방법과 보류·사람 검토·평가 절차를 설명하고, 8ms 측정 조건과 공개 가중치 이용 범위를 구분합니다.

고친 내용: 공식 발표·모델 카드·API 구현·Jetson 예제·라이선스를 대조하고 결정 모델의 분류·검토·평가 흐름을 작성했습니다.

고객 문의에서 결정해야 할 일을 좁히기

환불 요청인가? 어느 팀으로 보낼까? 얼마나 급한가? Liquid AI가 공개한 d1-3B는 이런 질문의 답을 생성 토큰 없이 한 번의 추론으로 돌려준다. 쇼핑몰 고객센터에 적용하는 예시를 통해 사용법과 평가 기준, 8ms 성능 수치의 조건을 살펴본다.

고객이 “결제가 두 번 됐는데 주문 내역은 하나예요. 오늘 출고되는지도 알려주세요”라고 문의했다. 상담원이 답변을 쓰기 전에 할 일이 여럿이다. 결제 담당자가 확인해야 하는지, 물류팀의 도움이 필요한지, 지금 당장 처리해야 하는지를 가려야 한다. 이런 문의를 자동으로 정리하려면 문장을 잘 읽는 능력과 함께 회사가 정한 업무 구분을 지키는 능력이 필요하다.

2026년 10월 7일 Liquid AI가 공개한 d1-3B와 d1-omni-600M은 이 지점을 겨냥한다. 두 모델은 입력과 질문을 받아 한 번의 순전파, 즉 single forward pass로 선택 결과를 계산한다. 답변 문장을 토큰 단위로 이어 쓰는 단계가 없다. 공개 가중치를 내려받아 업무 흐름 안에 넣어볼 수 있다는 점도 이번 발표의 핵심이다. Liquid AI 공식 발표

실무에서 관심을 둘 부분은 고객센터 전체를 바꾸는 거대한 계획보다 작다. 지금도 생성형 모델에 맡기고 있는 ‘담당 부서 고르기’, ‘요청 여부 확인하기’, ‘우선순위 매기기’ 같은 호출 하나가 출발점이다. 온라인 쇼핑몰의 문의 분류를 가상 사례로 삼아 공개 API를 업무에 연결하는 순서를 살펴보자.

이 절의 근거 S230

먼저 결정할 질문을 세 가지 형태로 나눈다

공식 문서가 제시하는 질문 형식은 세 가지다. `choice`는 이름 붙인 선택지 가운데 하나를 고른다. `noul`은 예·아니오 질문에 대해 ‘예’의 확률을 반환한다. `score`는 순서가 있는 평가 기준을 따라 점수를 계산한다. 고객센터라면 각각 담당 팀, 환불 의사, 긴급도에 대응시킬 수 있다. Decision Models 문서

이 구분은 데이터베이스 칼럼을 정하는 일과 비슷하다. ‘이 문의를 처리해 줘’라는 넓은 요청을 다음처럼 쪼갠다.

- 담당 팀: 결제, 배송, 기술지원, 추가 확인 가운데 어디인가

- 환불 의사: 고객이 실제로 환불을 요청했는가

- 긴급도: 일반 문의인가, 당일 확인이 필요한가, 현재 이용이 막혔는가

여기서 환불 의사가 있다는 결과는 환불을 승인한다는 뜻이 아니다. 담당 팀이 결제팀이라는 결과도 실제 결제 오류가 확인됐다는 뜻은 아니다. 모델은 입력에 나타난 문의를 분류하고 주문 시스템 조회와 환불 정책 적용은 다음 단계에서 수행하도록 경계를 정하는 것이 좋다.

예컨대 “환불 규정이 궁금합니다”와 “이번 주문을 취소하고 환불해 주세요”는 서로 다른 요청이다. 분류표를 만드는 사람이 이 차이를 질문과 기준에 담아야 한다. 모델의 크기보다 먼저 검토해야 할 설계다.

이 절의 근거 S231

두 모델 가운데 무엇으로 시작할까

텍스트 문의와 첨부 이미지를 함께 다룬다면 우선 검토할 모델은 d1-3B다. 공식 문서는 이 모델을 텍스트·이미지용 권장 모델로 안내한다. 입력이 사진이라도 출력은 미리 정의한 선택지나 점수다. 파손 사진을 보고 ‘외관 손상’, ‘구성품 누락’, ‘사진만으로 판단하기 어려움’ 가운데 고르게 하는 식의 시험을 생각할 수 있다. 모델별 역할

d1-omni-600M은 실제 파라미터 수가 5억 8,700만 개인 작은 실험적 모델이다. 텍스트에 이미지 또는 음성 클립을 붙일 수 있지만 한 요청에 이미지와 음성을 동시에 넣는 형식은 지원하지 않는다. 음성은 최대 30초이며 영어 화자와 어시스턴트 사이의 요청으로 학습됐다는 제한이 명시돼 있다. 한국어 상담 녹음을 바로 처리할 수 있다고 가정해서는 곤란하다. d1-omni-600M 모델 카드

따라서 작은 모델을 고르는 이유도 구체적이어야 한다. 텍스트 라우팅 정확도가 가장 중요하다면 두 모델을 같은 문의 묶음으로 비교한다. 음성 의도 분류를 연구하려면 omni를 별도 후보로 삼는다. 메모리 제약이 있다는 이유만으로 품질과 지원 언어를 건너뛰어 선택하지 않는다. 처음부터 텍스트·사진·음성을 한꺼번에 도입하기보다 한 종류의 입력에서 합격 기준을 세우는 편이 결과를 해석하기 쉽다.

이 절의 근거 S231 · S232

1단계 분류표와 보류 경로를 만든다

첫 실험에서는 실제 조직도를 그대로 선택지에 복사하기보다 문의를 받았을 때 수행할 행동을 기준으로 정리해 보자. ‘운영팀’처럼 업무 범위가 넓은 이름은 모델에도 사람에게도 모호하다. ‘배송 추적과 출고 일정 확인’, ‘중복 결제와 청구 내역 확인’처럼 설명을 붙이면 어느 문의가 어디로 가야 하는지 검토하기 쉽다.

보류 경로도 필요하다. 이미 주어진 선택지 가운데 하나를 고르는 시스템에 적절한 선택지가 없으면, 가장 그럴듯한 오답이 반환될 수 있다. ‘추가 확인’은 무성의한 분류가 아니라 누락된 업무와 애매한 문의를 모으는 통로다. 이 통로에 어떤 문의가 쌓이는지 보면 다음에 추가할 분류를 찾을 수 있다.

문의가 두 가지 업무를 포함할 때의 원칙도 정한다. 앞의 중복 결제·출고 문의라면 결제를 주 담당으로 배정하고 배송 확인 여부를 별도 질문으로 물을 수 있다. 한 개의 `choice`만으로 복수 담당자를 모두 표현하려고 하면 분류표가 불필요하게 복잡해진다. 어느 팀이 먼저 받아야 하는지와 어떤 추가 작업이 필요한지를 분리하는 방법이 더 관리하기 쉽다.

2단계 공식 system_one 호출로 작은 실험을 한다

d1-3B 모델 카드의 사용법은 `AutoModel`로 모델을 불러오고 `system_one`을 호출하는 방식이다. 시작할 때 필요한 패키지는 `transformers>=5.14`, PyTorch, torchvision, Pillow다. Hugging Face의 일반적인 ‘Use this model’ 영역에 표시되는 텍스트 생성 예제보다 모델 카드 본문의 전용 사용법을 따라가는 것이 정확하다. 공식 시작 코드

다음은 해당 API에 한국어 쇼핑몰 분류표를 적용한 예시다. CUDA 장치가 있으면 사용하고 없으면 CPU로 읽도록 구성했다. 모델을 내려받고 불러오는 시간은 아래의 분류 호출 자체와 별개다.

import torch
from transformers import AutoModel

device = "cuda" if torch.cuda.is_available() else "cpu"
model = AutoModel.from_pretrained(
    "LiquidAI/d1-3B",
    trust_remote_code=True,
    dtype=torch.bfloat16 if device == "cuda" else torch.float32,
).to(device)

questions = {
    "team": {
        "type": "choice",
        "instructions": "이 문의를 먼저 처리할 담당을 고르세요.",
        "criteria": {
            "payment": "중복 결제, 청구 내역, 환불 확인",
            "shipping": "출고 일정, 배송 추적, 수령 문제",
            "technical": "로그인 실패, 화면 오류, 기능 고장",
            "review": "정보 부족 또는 다른 종류의 문의",
        },
    },
    "refund": {
        "type": "noul",
        "instructions": "고객이 환불 의사를 명시했나요?",
    },
    "urgency": {
        "type": "score",
        "instructions": "문의에 드러난 현재 이용 불편을 평가하세요.",
        "criteria": ["일반 확인", "당일 확인 필요", "현재 이용 불가"],
    },
}

ticket = "결제가 두 번 됐어요. 한 건을 환불해 주세요."
answers = model.system_one(ticket, questions)["answers"]
print(answers)

이 절의 근거 S233

반환값과 운영 배포를 구분하기

반환값을 읽을 때는 각 질문의 결과를 따로 다룬다. `team`에는 선택된 이름과 확률 분포가, `refund`에는 예의 확률이 들어온다. `score`의 기준은 0부터 센다. 위처럼 세 단계라면 점수 범위는 0~2이고 확률로 가중한 값이므로 소수가 나올 수 있다. 소스 코드상 `confidence`는 가장 높은 선택지의 확률이며 실제 업무에서 검증한 정답률 자체를 뜻하지 않는다. 공개 API 구현

설치 단계에서 한 가지를 더 확인해야 한다. `trust_remote_code=True`는 저장소에 포함된 코드를 실행하도록 허용하는 설정이다. 업무용 환경에서는 의존성과 모델 코드를 검토하고 검증한 리비전을 고정해 변경 이력을 관리하는 편이 좋다. 짧은 예제가 곧바로 운영 서버의 배포 절차가 되지는 않는다.

이 절의 근거 S234

3단계 점수와 실행 규칙 사이에 검토 구간을 둔다

가상의 결과로 결제팀 0.52, 배송팀 0.44가 나왔다고 하자. 최상위 선택지만 저장하면 ‘결제팀’이라는 확정적인 기록이 남는다. 그러나 분포까지 보면 두 업무가 경쟁한다는 사실을 알 수 있다. 이 문의는 상담원 검토로 보내거나 결제팀을 주 담당으로 두고 배송 확인 작업을 함께 생성하는 후보가 된다. 여기의 숫자는 설명을 위한 가정이며 모델 실행 결과가 아니다.

반대로 결제팀의 확률이 높아도 환불 승인이나 결제 취소까지 곧장 연결할 이유는 없다. 분류 자동화와 거래 처리는 필요한 근거가 다르다. 주문 번호가 유효한지, 해당 계정이 주문자와 일치하는지, 이미 처리된 요청인지 확인하는 단계가 있어야 한다.

초기에는 모델이 추천한 담당과 상담원이 선택한 담당을 나란히 기록하는 방식이 유용하다. 실제 배정은 기존 절차대로 진행하고 차이를 모으면, 잘못된 이동을 발생시키지 않으면서 분류표를 개선할 수 있다. 이후 충분히 분명한 문의부터 자동 배정 범위를 넓힌다. 낮은 확신의 결과를 더 강한 모델이나 사람에게 넘기는 방식은 Liquid의 이관 가이드에도 제시돼 있다. Decision Model Guide

임계값은 일률적으로 정하기 어렵다. 배송팀 대신 결제팀에 보내는 실수와 긴급 장애 신고를 일반 문의로 낮추는 실수의 비용이 다르기 때문이다. 담당 부서 분류와 긴급도 분류에 같은 숫자를 적용하기보다, 각각 어떤 오류를 줄여야 하는지 먼저 적어 두자. 사람에게 넘기는 비율도 함께 본다. 정확도가 올라갔어도 대부분의 문의가 보류된다면 실제 절감 효과는 작을 수 있다.

이 절의 근거 S235

공개 예제의 배송 문의에서 배울 수 있는 것

NVIDIA의 Jetson AI Lab 가이드는 d1-3B를 Jetson에서 실행하는 절차와 예시 출력을 공개했다. 흥미로운 부분은 배치 예제다. 배송 지연 문의와 앱 오류 문의를 넣는데, 선택지는 결제·기술지원·부정 사용 세 종류다. 문서에 실린 결과는 두 건 모두 `technical`이다. 배송을 받을 선택지가 없는 상태에서 나온 결과다. Jetson AI Lab의 실행 예제

이 한 장면으로 모델의 전체 성능을 평가할 수는 없다. 다만 실무자가 흔히 겪는 문제를 잘 드러낸다. 분류 모델을 붙였다는 사실만으로 업무 구분의 빈칸이 채워지지는 않는다. 빠진 라벨, 겹치는 설명, 애매한 경계는 실제 문의를 넣어야 드러난다. 예제 코드를 가져올 때 모델 로딩 부분보다 선택지 정의를 먼저 자기 업무에 맞추어 읽어야 하는 이유다.

NVIDIA의 공개 실행 예제에서 얻을 수 있는 교훈은 분류표의 빈칸을 먼저 찾으라는 것이다. 실제 상담센터의 운영 정확도와 비용은 별도로 측정해야 한다.

이 절의 근거 S236

8ms와 48.57을 읽는 방법

성능 수치에도 실행 조건이 붙는다. 모델 카드의 RTX 4090 8ms는 warm 호출, BF16, 20회 실행 중앙값이며 해당 행에는 `model.compile(mode="reduce-overhead")`가 적용돼 있다. 컴파일 없이 단일 질문을 처리한 값은 16ms다. 새로운 입력 형태의 첫 호출에는 커널 선택이나 컴파일 시간이 든다. d1-3B 속도 측정 조건

고객센터가 확인할 값은 문의 접수부터 담당 배정이 끝날 때까지의 시간이다. 긴 상담 이력 불러오기, 첨부파일 처리, 대기열, 결과 저장을 모두 포함해 측정해야 한다. 단일 문의 응답 시간과 여러 문의를 모아 처리할 때의 처리량도 구분한다. 입력이 길어지거나 질문 수가 늘어나는 상황을 빼고 가장 짧은 요청만 비교하면 운영 성능을 예상하기 어렵다.

Decision Index 0.2.1의 48.57도 성격을 정확히 알아야 한다. Liquid AI가 공식 scorer로 측정한 공개 split 점수이며 리더보드에 제출해 얻은 결과는 아니라고 모델 카드에 명시돼 있다. 이 수치를 한국어 고객 문의의 정확도 48.57%로 해석해서는 안 된다. 평가 설명

실제 평가는 자기 문의 묶음으로 설계한다. 일반적인 배송·결제 문의 외에 오타, 짧은 구어체, 복수 요청, 사내 약어, 과거 상담을 인용한 문장도 포함한다. 특정 단어만 보면 틀리기 쉬운 사례를 따로 모으면 좋다. “환불은 필요 없고 영수증만 주세요” 같은 부정 표현, “비밀번호를 바꾸니 해결됐습니다” 같은 해결 완료 표현이 여기에 해당한다.

전체 정확도 하나에 더해 담당별 오배정, 긴급 문의 누락, 사람 검토 비율, 최종 배정까지의 시간을 보자. 모델을 바꿨을 때뿐 아니라 분류 설명 한 줄을 고쳤을 때도 같은 평가 묶음을 다시 돌려야 한다. 분류표의 변경 역시 시스템 동작의 변경이다.

이 절의 근거 S237 · S238

카메라 데모가 보여주는 범위

Liquid AI는 발표 당시 카메라 프레임, 그림, 메시지를 입력으로 쓰는 열 개의 데모를 System One Arcade로 소개했다. 현재 공개 페이지는 열한 개의 데모로 안내한다. 몇 개의 정형 질문을 한 프레임에 적용하는 방식이라 결정 모델의 입출력을 이해하는 데 도움이 된다. 공개 페이지에는 직접 실행할 수 있는 로컬 설치 안내도 있다. System One Arcade

고객센터 관점에서 여기서 가져올 아이디어는 첨부 이미지에 제한된 질문을 하는 방식이다. 예를 들어 반품 사진이 전체 제품을 보여주는지, 라벨을 읽을 수 있을 만큼 선명한지부터 분류하도록 설계할 수 있다. 이는 앞으로 시험할 응용 예시다. 데모가 있다는 사실을 반품 사유를 정확히 판정한다는 근거로 쓰면 안 된다. 사진 품질, 가려진 부위, 제품 종류에 따라 별도의 평가가 필요하다.

확인한 공개 자료의 중심은 제작사 데모와 협력사 실행 가이드다. 독립적인 고객센터 운영 성과가 필요한 팀이라면 자동 배정률이나 처리비 절감률을 이 자료에서 가져오기보다 자체 시험으로 구해야 한다.

이 절의 근거 S239

공개 가중치의 이용 조건도 확인한다

d1-3B 저장소에는 LFM Open License v1.0이 들어 있다. 이 라이선스는 연 매출 1,000만 달러를 기준으로 상업 이용 제한을 두고 재배포 시 라이선스와 관련 고지 유지 등의 조건을 규정한다. 법인 정의에는 지배·피지배 관계의 조직도 포함되므로, 작은 팀의 실험이라는 이유만으로 회사 전체의 적용 조건을 판단하면 안 된다. 실제 배포 전에는 원문의 정의와 상업 이용 조항을 확인해야 한다. 라이선스 원문

이 점을 포함하면 도입 검토가 더 현실적이 된다. 로컬 실행으로 문의를 외부 추론 API에 보내지 않는 구성을 만들 수 있더라도, 내부 로그·접근 권한·보관 기간은 여전히 정해야 한다. 공개 가중치와 운영상의 개인정보 보호는 각각 확인할 항목이다.

이 절의 근거 S240

첫 목표는 좁고 측정 가능하게 잡는다

d1을 시험하기 좋은 출발점은 답의 범위가 정해져 있고 잘못된 결과를 발견하고 되돌릴 수 있는 업무다. 최근 문의를 대상으로 담당 팀을 추천하게 하고 상담원의 판단과 비교하는 실험부터 시작할 수 있다. 그다음에 환불 의사나 긴급도 질문을 붙여 같은 입력에서 여러 판단을 얻는 이점이 실제로 있는지 본다.

자유로운 답변 작성이나 복잡한 상담은 기존 언어 모델과 상담원의 역할로 남겨둘 수 있다. Liquid의 공식 문서도 글쓰기·대화·다단계 추론에는 언어 모델을 쓰도록 구분한다. 적합한 작업의 기준

작은 결정 모델의 실용성은 운영자가 정한 질문에 필요한 형태로 답하고 그 결과를 검토 가능한 업무 흐름에 연결하는 데 있다. 먼저 줄이고 싶은 오배정 한 가지를 고르고 빠진 선택지를 채우고 애매할 때 넘길 곳을 정해 보자. 그 상태에서 측정한 속도와 정확도가 d1을 계속 쓸 이유를 알려줄 것이다.

이 절의 근거 S231