Clairic: 추출 전용 모델을 앞에 세운 단계별 파이프라인으로 청구 처리 비용 49% 절감

영수증·청구서·고객 메일처럼 반복되는 문서 업무는 큰 LLM 하나에 다 맡기는 것보다, 값을 뽑는 모델과 고르는 모델을 앞에 세우고 LLM은 마지막 글쓰기에만 쓰는 편이 싸고 빠릅니다. Cloudflare의 시험에서는 비용이 절반, 시간이 3분의 1로 줄었습니다. 우리 업무에 옮기려면 뽑을 필드를 타입과 함께 정의하고, confidence로 자동 처리와 사람 검토를 가르는 기준을 먼저 정해야 합니다.

요약

Cloudflare의 Workers AI 팀(Alex Reneau, Michelle Chen, Kevin Flansburg)은 2026년 10월 19일 글에서 새 모델 Clairic을 미리보기로 공개했습니다. Clairic은 extraction model(추출 모델)입니다. 비정형 텍스트와 이미지를 넣고 “주문번호, 결제 금액, 배송 후 경과일”처럼 뽑고 싶은 필드를 타입과 함께 정의하면, 필드마다 타입에 맞는 값 하나 또는 null을 돌려줍니다. 글을 쓰지 않습니다. LLM이 토큰을 하나씩 만드는 대신 한 번의 forward pass(모델을 한 번 통과시키는 계산)로 모든 필드를 동시에 계산하므로 보통 1초 안에 답이 오고, 출력 토큰이 없어 요금은 입력 토큰에만 붙습니다. 저자들은 이를 Kahneman의 System One(빠르고 직관적인 사고)에 빗댑니다. 한 달 앞서 나온 TypeSafe의 Jev와 Cloudflare의 Clef가 “선택지 가운데 고르는” decision model(결정 모델)이라면, Clairic은 “값을 읽고 계산하고 추정하고 예측하는” 쪽을 맡습니다.

Clairic은 글을 쓰지 않고 정해진 타입의 값만 돌려줍니다. 요금은 입력 토큰에만 붙습니다.

중심 시험은 파손 상품 보험 청구 처리입니다. 고객 메일에서 사실을 뽑고(추출), 환불인지 수리인지 정하고(판단), 답장을 쓰는(생성) 세 단계를 두 방식으로 돌렸습니다. 하나는 세 단계 모두 LLM(GLM-5.3)에, 다른 하나는 추출은 Clairic, 판단은 Clef, 답장만 GLM-5.3에 맡겼습니다. 결과는 청구 100만 건당 11,740달러 대 6,032달러로 단계별 쪽이 49% 적게 들었고, 한 건 처리 시간은 61.7초 대 19.3초로 69% 짧았습니다. 두 방식 모두 사실과 결정은 매번 맞혔지만, LLM이 추정한 수리비는 실행마다 달랐고 Clairic의 추정은 매번 같았습니다. 추출과 판단 단계가 1초 아래로 내려가고 출력 토큰이 사라지니, 남는 비용은 마지막 답장 한 단계뿐입니다. 아래에서는 추출 모델이 값을 돌려주는 방식과 안정적인 이유를 풀고, 우리 청구·정산·영수증 업무에 옮길 때 정할 것을 덧붙였습니다.

청구 100만 건당 비용(원문 수치). 단계별 파이프라인이 49% 적게 듭니다.

핵심 메커니즘

System One Extraction Model: 글을 쓰지 않고 값만 돌려주는 모델

추출 모델은 입력을 읽고 타입이 정해진 값을 내놓습니다. LLM은 다음 토큰을 하나씩 뽑으며 문장을 만들어 느리고 출력 길이에 비례해 비용이 붙습니다. 추출 모델은 회귀와 추출 문제로 틀을 잡아, 입력 전체와 필드 정의를 한 번에 넣으면 한 번 계산해 모든 필드의 값을 동시에 냅니다. 필드가 한 번에 담기지 않으면 서버가 나눠 병렬로 돌리고 합칩니다. 그래서 필드 30개의 비용이 3개와 거의 같습니다.

저자들은 세 종류의 모델을 역할로 나눕니다. 추출 모델은 원본을 값으로, 결정 모델은 값을 결정으로, LLM은 결정을 말로 바꿉니다. 어떤 단계가 “읽어서 숫자나 날짜를 내는 일”이면 추출 모델, “정해진 선택지 중 고르는 일”이면 결정 모델, “사람이 읽을 글을 쓰는 일”이면 LLM이 맞습니다. 요약이나 설명처럼 열린 글이 필요한 단계에는 추출 모델을 쓸 수 없습니다.

세 종류 모델의 역할. 추출 모델은 값을, 결정 모델은 선택을, LLM은 문장을 만듭니다.

Typed Fields와 null: 타입이 맞는 값 아니면 비워 두는 출력

요청은 두 부분입니다. state에 읽을 텍스트(이미지 최대 4장 포함)를, fields에 필드마다 타입과 선택 사항(단위, 소수 자릿수, 지시문)을 적습니다. 타입은 text(원문 위치 span과 함께), number, date, time, datetime, duration, list, estimate, forecast입니다. 답은 요청한 타입의 값이거나 null입니다. 입력에 근거가 없으면 모델은 값을 지어내지 않고 null을 돌려주며, 그때 어떤 값을 후보로 봤는지(guess)와 그 확신도(confidence), 비어 있을 확률(p_null)을 함께 줍니다. 원문 예시에서는 운송장 번호를 물었을 때 null이 돌아오고, 후보로 본 “$52.10”이 confidence 0.416으로 기각됐습니다.

운영에서 뜻하는 바는 두 가지입니다. 타입이 틀린 답이 없으니 파싱 실패 처리가 사라지고, confidence와 p_null을 임계값과 비교해 자동 처리할 건과 사람이 볼 건을 코드에서 나눌 수 있습니다. 저자들도 답이 형식은 맞지만 꼭 옳은 것은 아니라며 이 숫자들로 자동화 범위를 정하라고 권합니다. 가상 예시로, 결제 금액 필드는 confidence 0.99 이상만 자동 승인하고 그 아래는 검토 큐로 보냅니다.

답마다 붙는 confidence와 p_null을 임계값과 비교해 자동 처리·검토·보류로 나눕니다. 임계값은 운영자가 정합니다.

Estimate와 Forecast: 숫자 하나가 아니라 분포를 돌려주는 추정

입력에 답이 적혀 있지 않은 값도 요청할 수 있습니다. estimate 타입은 min, max, step(필요하면 로그 스케일)으로 범위와 눈금을 정해 주면 그 안에서 분포를 계산해 중앙값과 80% 구간(p10~~p90), 요청 시 99개 백분위를 돌려줍니다. 원문은 주변 거래 사례(면적, 방 수, 건축 연도, 거래가)를 넣고 대상 주택의 가격을 5만~~500만 달러 범위에서 추정합니다. 결과는 중앙값 415,000달러, 80% 구간 370,000~~470,000달러였습니다. 같은 입력으로 “매물 기간”을 물으면 구간이 24~~148일로 넓어지는데, 저자들은 이를 입력에 근거가 적다는 신호로 읽습니다.

forecast 타입은 시계열을 넣고 몇 단계 앞을 볼지 정하면 단계마다 추정값과 80% 구간을 돌려줍니다. 추정은 입력에 근거가 있을 때만 믿을 수 있습니다. 비교 사례나 이력이 없으면 분포는 돌아오지만 뜻이 없습니다. 저자들은 전용 시계열 모델을 대신하는 것이 아니라 중요도가 낮은 패턴 예측에 맞는다고 선을 긋습니다. 가상 예시로, 구매팀이 공급사 메일에서 “실제 입고까지 걸릴 일수”를 estimate로 요청하려면 과거 납기 이력을 state에 함께 넣어야 구간이 좁아집니다.

집값 추정 예시(원문 수치). 중앙값과 80% 구간을 함께 받아 구간 폭으로 자동화 여부를 가릅니다.

Cascaded Pipeline: 추출 → 판단 → 생성으로 나눈 세 단계

고객 메일이 들어오면 Clairic이 고객 이름, 주문번호, 결제 금액, 배송 후 경과일, 손상 목록, 수리비 추정의 여섯 필드를 뽑습니다. 결제 금액은 가격과 세금을 더한 계산값이고, 경과일은 두 날짜의 차이입니다. 그 값들과 정책 규칙(“배송 30일 안이면 환불, 수리비가 가격의 60% 미만이고 제품이 작동하면 수리 우선”)을 Clef에 넘기면 환불과 수리 두 선택지에 확률을 매겨 하나를 고릅니다. 마지막에 GLM-5.3이 주문번호, 손상, 다음 단계만 받아 60단어 이내 답장을 씁니다. LLM은 원문 메일을 보지 않습니다.

효과는 세 가지입니다. 비용은 출력 토큰이 있는 단계가 하나로 줄어 절반이 됩니다. 시간은 추출 0.46초, 판단 0.22초로 앞 두 단계가 거의 사라집니다. 안정성은 숫자를 다루는 단계가 매번 같은 값을 내는 모델로 옮겨 가면서 좋아집니다. 반면 LLM 단독 구성은 작은 모델로 바꾸면 무너졌습니다. 저자들에 따르면 Gemma 4와 Qwen은 수리비 같은 값을 끌어내지 못했습니다. 단계를 나누면 단계마다 맞는 작은 모델을 쓸 수 있고, 나누지 않으면 큰 모델이 필요합니다.

추출 → 판단 → 답장. LLM은 마지막 단계에서 정리된 값만 받아 글을 씁니다. 시간은 원문 시험의 단계별 처리 시간.

통념과 다른 주장

흔히 이렇게 봅니다LLM에 JSON 스키마를 주고 구조화 출력을 켜면 문서에서 값을 뽑는 문제는 해결된다.

저자는 이렇게 봅니다LLM은 토큰을 하나씩 만들기 때문에 형식이 항상 유효하다는 보장이 없고, 같은 입력에서 숫자가 실행마다 달라질 수 있습니다. 추출 모델은 타입이 맞는 값 아니면 null만 내고, 같은 입력에는 같은 값을 냅니다.

근거보험 청구 시험에서 GLM-5.3이 추정한 수리비는 실행마다 250달러, 250달러, 220달러로 범위까지 달라졌고, Clairic의 추정은 매번 같았습니다.

JSON 모양이 맞는 것과 값이 안정적인 것은 다른 문제입니다.

흔히 이렇게 봅니다뽑을 필드가 늘면 비용도 비례해 늘어나니 필드를 아껴야 하고, 단계를 나누는 것보다 큰 모델 하나에 맡기는 쪽이 단순하고 결국 싸다.

저자는 이렇게 봅니다추출 모델은 모든 필드를 한 번에 병렬로 계산하므로 필드 30개의 비용이 3개와 거의 같습니다. 그리고 추출·판단·생성을 나눠 각 단계에 맞는 모델을 쓰는 쪽이 더 빠르고 더 쌉니다.

근거단계별 파이프라인이 LLM 단독보다 시간 69%, 비용 49%를 줄였고, 두 방식 모두 사실과 결정은 매번 맞혔습니다.

추출 모델에서는 필드를 넉넉히 정의해도 비용이 거의 늘지 않습니다.

저자가 든 사례

파손 상품 보험 청구: 단계별 파이프라인 대 LLM 단독

상황: 고객이 보낸 파손 신고 메일에서 사실을 뽑고, 정책에 따라 환불 또는 수리를 정하고, 답장을 써야 하는 청구 처리.
한 일: 같은 세 단계를 GLM-5.3 단독과 Clairic(추출) → Clef(판단) → GLM-5.3(답장) 두 방식으로 돌렸습니다.
결과: 비용은 청구 100만 건당 11,740달러 대 6,032달러(49% 절감). 시간은 61.7초 대 19.3초(69% 단축). 입력 토큰은 390 대 701로 단계별 쪽이 많았지만, 출력 토큰이 2,544 대 1,329로 줄어 비용을 결정했습니다. 사실과 결정은 두 방식 모두 매번 맞혔습니다. 실행 횟수는 원문에서 밝히지 않았습니다.
연결: Cascaded Pipeline과 Typed Fields의 사례이자, 실제 고객 사례가 아닌 저자들의 시험 시나리오입니다.

청구 1건 처리 시간(원문 수치). 추출과 판단이 1초 아래로 내려가 전체가 약 3분의 1이 됩니다.

TSA 승객 수 예측: 21일 동안 매일 다음 날을 맞히기

상황: 미국 공항 보안 검색대를 통과한 하루 승객 수(TSA 공개 데이터)를 다음 날 분량만큼 예측하는 일.
한 일: 21일 동안 매일 아침, 그날까지의 이력만 넣고 forecast 타입으로 다음 날 값을 요청했습니다.
결과: 평균 오차 3.3%, 21일 중 17일의 실제값이 80% 구간 안에 들었습니다. 요일별 패턴은 잡았지만, 빗나간 4일 중 3일은 Columbus Day 연휴 주말이었습니다. 입력 시계열에 없는 연휴와 행사는 모델이 알 수 없습니다.
연결: Estimate와 Forecast의 사례이고, 추정은 입력에 있는 근거만큼만 믿을 수 있다는 원칙을 보여 줍니다.

TSA 승객 수 예측(원문 수치). 요일 패턴은 잡았지만 입력에 없는 연휴는 알 수 없었습니다.

영수증 사진: 기울어진 이미지에서 8개 값 뽑기

상황: 글자가 완전하지 않고 각도도 기울어진 영수증 사진 한 장.
한 일: 이미지를 입력으로 넣고 주문번호, 구매 시각, 수량, 단가, 소계, 세금, 팁, 할인의 8개 필드를 요청했습니다.
결과: 주문번호 77245(confidence 0.776), 구매 시각 2026-07-01 13:34(0.831), 수량 2, 단가 7.99, 소계 15.98, 팁 2.39가 돌아왔고, 영수증에 없던 할인은 null(p_null 약 0.999)로 비워졌습니다.
연결: Typed Fields와 null의 사례입니다. 없는 값을 비워 두는 동작이 이미지 입력에서도 같았습니다.

영수증 사진 추출(원문 수치). 없는 항목은 지어내지 않고 null로 돌아왔습니다.

기술 디테일: 우리 문서 업무에 이 구조를 옮기려면

아래는 글의 구조를 우리 청구·정산·영수증 업무에 대입할 때 필요한 설계로, AX Review가 새로 작성했습니다. 숫자는 가상 예시입니다.

Typed Fields를 우리 업무로 정의하려면 담당자가 문서를 보고 손으로 옮겨 적는 칸을 모두 필드로 적고, 칸마다 타입, 단위, 소수 자릿수, “어디서 어떻게 읽는지” 한 문장 지시문을 붙입니다. 날짜 계산이 들어가는 필드는 기준 날짜를 reference_date나 지시문에 명시합니다. 모델이 오늘 날짜를 알 거라고 가정하지 않습니다. 두 단계가 넘는 산식(여러 행 합산, 환율 적용 뒤 세금 계산)은 필드로 요청하지 않고 원재료 값만 뽑아 코드에서 계산합니다. 아래는 보험 청구를 국내 손해 접수에 맞춰 바꾼 가상 예시입니다.

{
  "state": "<고객 접수 메일 전문>",
  "reference_date": "2026-10-25",
  "fields": {
    "claim_no":        { "type": "text",     "instructions": "접수번호 또는 주문번호" },
    "paid_amount_krw": { "type": "number",   "decimals": 0, "unit": "KRW", "instructions": "상품가와 배송비의 합" },
    "delivered_on":    { "type": "date" },
    "days_since_delivery": { "type": "duration", "unit": "days", "integer": true },
    "damage":          { "type": "list",     "items": "text", "instructions": "손상 부위를 원문 표현대로" },
    "repair_cost_krw": { "type": "estimate", "unit": "KRW", "min": 10000, "max": 2000000, "step": 10000, "scale": "log" }
  }
}

confidence 임계값으로 자동 처리 범위를 정하려면 필드마다 세 구간을 둡니다. 자동 처리, 사람 검토, 보류·재요청입니다. 임계값은 표본 300건을 사람이 라벨링한 뒤 confidence 구간별 정답률을 재서 정합니다. 금액 필드에서 0.99 이상 구간의 정답률이 99.5%면 자동 처리, 0.90~0.99 구간이 94%면 검토입니다. estimate 필드는 confidence 대신 80% 구간의 폭을 봅니다. 수리비 구간 폭이 상품 가격의 20% 안이면 자동, 넘으면 검토입니다. 임계값은 월 1회 표본 100건으로 다시 재고, 정답률이 기준 아래로 내려오면 그 필드만 검토 비율을 올립니다.

필드별 임계값(가상 예시). 금액처럼 돈이 걸린 필드는 기준을 더 높게 둡니다.

단계별 파이프라인의 비용을 미리 계산하려면 단계마다 토큰과 단가를 따로 셉니다. Clairic은 입력 토큰에만 100만 토큰당 0.10달러가 붙고 출력 토큰은 없습니다(Workers AI 모델 문서 기준, 컨텍스트 65,536토큰). 필드 정의도 입력 토큰에 포함되므로(schema_tokens) 필드를 넉넉히 적어도 비용 변화는 작습니다. LLM 단계는 입력과 출력 토큰 모두에 단가가 붙으니 답장 길이 제한(원문은 60단어)이 곧 비용 통제입니다. 여기에 검토로 넘어가는 건의 비율과 건당 검토 인건비를 더해 건당 총비용을 냅니다. 가상 예시로 월 20만 건 업무에서 건당 모델 비용이 15원에서 8원으로 내려가면 월 140만 원이 줄고, 검토 비율이 15%에서 8%로 내려가면 그만큼의 인건비가 더 줄어듭니다. 자동 처리 비율이 50%를 넘지 못하면 검토 인건비가 모델 비용 절감을 역전시킬 수 있으므로, 비용 모델에는 검토 비율을 변수로 둡니다.

비용 계산 흐름. 추출 모델은 출력 토큰이 없어 입력 토큰 수만 세면 됩니다.

실패하는 경우와 대응. 저자들이 밝힌 약점은 넷입니다. 첫째, 한두 단계 계산(합계, 차이, 단위 변환, 날짜 계산)은 믿을 수 있지만 더 긴 연쇄 계산과 표 여러 행의 집계는 아직 약합니다. 값은 뽑고 계산은 코드가 합니다. 둘째, 추정은 입력에 근거가 있을 때만 뜻이 있습니다. 비교 사례나 이력을 state에 함께 넣습니다. 셋째, 구간의 적중률은 측정값이지 보장이 아니고, 낯선 데이터에서는 구간이 좁게(과신) 나올 수 있습니다. 표본으로 80% 구간 적중률을 재서 70% 아래면 기준을 더 엄격하게 둡니다. 넷째, 예측은 기초 수준이어서 연휴·행사처럼 시계열 밖의 사건을 모릅니다. 달력 변수를 넣거나 그 날짜는 사람이 봅니다. 모델이 미리보기 단계이므로 체크포인트가 바뀔 때마다 표본 검증과 임계값 조정을 다시 합니다.

원문이 밝힌 약점을 운영 규칙으로 바꾼 것. 오른쪽 칸이 대응입니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	4주 동안 하는 일
스폰서	운영 또는 고객지원 총괄 임원	대상 업무와 자동 처리 범위 승인
업무 담당	청구·정산 처리 담당 2명	필드 목록 작성, 표본 300건 정답 라벨링
엔지니어	백엔드 개발자 1명	Workers AI 호출, 임계값 분기, 검토 큐 연결
데이터 분석	분석 담당 1명	confidence 구간별 정답률, 비용 모델
리스크·법무	담당 1명	자동 처리 가능한 금액 상한, 고객 고지 문구
재무	재무 담당 1명	건당 비용 비교와 손익 분기 확인

시작 전 준비물: 최근 3개월 접수 문서 표본 300건(텍스트·이미지 포함), 현재 처리 절차서와 담당자가 손으로 옮기는 칸 목록, 건당 평균 처리 시간과 인건비, 현재 LLM 호출이 있다면 그 토큰·비용 로그, 환불·수리 같은 결정의 정책 규칙 문서.

주차	할 일	산출물
1주	대상 업무 1개 선정, 필드 목록과 타입·지시문 정의	필드 정의서(JSON)
2주	표본 300건 라벨링, Clairic 1차 호출, 구간별 정답률 측정	정답률 표, 임계값 초안
3주	Clef 판단 규칙 연결, LLM 답장 길이 제한, 전체 파이프라인 시험	건당 비용·시간 비교표
4주	판정 회의, 자동 처리 범위와 확대 대상 결정	판정 보고서

문서 처리 파일럿 4주 일정(예시).

담당자 인터뷰 질문(업무 담당용): 문서 한 건에서 손으로 옮겨 적는 칸은 몇 개이고 그중 계산이 필요한 칸은 무엇입니까? 값이 문서에 없을 때 지금은 어떻게 처리합니까? 틀렸을 때 비용이 가장 큰 칸은 무엇입니까? 환불·승인 같은 결정 규칙을 문장으로 다 적을 수 있습니까, 예외는 몇 가지입니까? 고객 답장에 꼭 들어가야 할 정보와 들어가면 안 되는 정보는 무엇입니까?

진행 판정 기준(예시): 금액 필드의 자동 처리 구간 정답률이 99% 이상, 자동 처리 비율이 70% 이상, 건당 비용이 LLM 단독의 60% 이하면 다음 업무로 확대합니다. 금액 정답률이 99% 아래거나 자동 처리 비율이 50% 아래면 필드 지시문과 임계값을 고쳐 2주차부터 다시 돌립니다.

판정 기준(예시). 숫자는 업무의 금액 규모와 오류 비용에 맞춰 조정합니다.

AX 적용 제언. 이 구조가 맞는 곳은 건수가 많고 서식이 반복되는 문서 업무입니다. 손해보험의 소액 청구 접수, 커머스의 반품·파손 처리, 구매팀의 송장·납기 확인, 재무의 경비 영수증 정산이 대표적입니다. 순서는 업무 1개 선정 → 필드 정의와 표본 라벨링 → 임계값 → 판단·답장 단계 연결 → 비용 비교가 무난합니다. 추출 모델은 미리보기 단계이므로 처음부터 핵심 시스템에 붙이지 말고, 기존 처리 흐름 옆에서 같은 문서를 읽어 사람의 결과와 비교하는 그림자 운영으로 4주를 보내는 쪽이 안전합니다. 결정 규칙을 문장으로 적는 일은 현업 리더가 직접 맡고, 규칙이 적히지 않는 업무는 판단은 사람에게 남기고 추출만 먼저 자동화합니다.

원문 사례

항목	내용
발표처	Cloudflare 블로그(2026.10.19), Workers AI 팀 Alex Reneau · Michelle Chen · Kevin Flansburg
모델	Clairic(`@cf/cloudflare/clairic`), Workers AI 미리보기. 가중치 공개 예정
요금	입력 토큰에만 과금, 출력 토큰 없음. 모델 문서 기준 100만 입력 토큰당 0.10달러, 컨텍스트 65,536토큰, 이미지 최대 4장
출력	타입이 정해진 값 또는 null, confidence · p_null · span, estimate는 중앙값과 80% 구간(p10~p90)
청구 시험	Clairic → Clef → GLM-5.3 대 GLM-5.3 단독. 100만 건당 6,032달러 대 11,740달러(49% 절감), 19.3초 대 61.7초(69% 단축)
토큰	입력 701 대 390, 출력 1,329 대 2,544
안정성	GLM-5.3 수리비 추정은 실행마다 달랐고(250 · 250 · 220달러) Clairic은 같았음. Gemma 4 · Qwen은 LLM 단독 구성을 통과하지 못함
추정 예시	집값: 중앙값 415,000달러, 80% 구간 370,000~~470,000달러. 매물 기간 구간 24~~148일
예측 예시	TSA 승객 수 21일 예측, 평균 오차 3.3%, 17/21일이 80% 구간 안
이미지 예시	영수증 사진에서 8개 필드, 없는 할인은 null(p_null 약 0.999)
약점(저자 명시)	긴 연쇄 계산과 표 집계, 근거 없는 추정, 구간 과신, 기초 수준 예측
관련 모델	Clef(Cloudflare 결정 모델, 2026.10.01, Apache 2.0), Jev(TypeSafe, 2026.09)

핵심 개념

System One / System Two: Kahneman의 구분. 빠르고 직관적인 사고와 느리고 숙고하는 사고. 글에서는 추출·결정 모델과 LLM을 각각에 빗댄다.
decision model(결정 모델): 정해진 선택지 가운데 하나를 고르고 선택지별 확률을 돌려주는 모델. Cloudflare의 Clef, TypeSafe의 Jev.
span: 추출한 텍스트가 원문의 몇 번째 글자부터 몇 번째 글자까지인지 가리키는 위치 정보.
p_null: 그 필드가 비어 있어야 할 확률. 높으면 입력에 근거가 없다는 뜻.
p10 / p90: 분포의 10번째·90번째 백분위. 둘 사이가 80% 구간이다.
calibration(보정): "80% 구간"이 실제로 80%쯤 맞는지의 정도. 측정값이며 보장이 아니다.
Workers AI: Cloudflare의 서버리스 AI 추론 서비스.

내 메모

TODO: 내 생각 추가

원문: Alex Reneau, Michelle Chen, Kevin Flansburg, “Introducing Clairic, a new System One class of extraction models”(Cloudflare 블로그, 2026.10.19). 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 글의 내용을 AX Review가 다시 정리했습니다. 요금, 컨텍스트, 이미지 한도, 응답 필드 이름은 Workers AI의 Clairic 모델 문서와 extraction models 문서에서, Clef의 발표일과 라이선스는 Clef 발표 글에서 확인했습니다. 기술·현업 디테일, JSON 예시, 임계값 표, 비용 계산, 일정·판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체와 데모 링크는 Cloudflare 블로그에서 볼 수 있습니다.