PROC MATCHA
Matcha는 지저분하고, 철자가 틀리고, 절반만 입력된 주소를 실제로 가리키는 레코드에 연결합니다. 사용자 장비에서 실행되며, 모든 판정에 보정된 확률과 이유를 함께 제공합니다. 개인 이름, 사업체 이름, 이메일, IP 위치, 식별자도 같은 엔진에서 동작합니다. 어려운 사례에는 Jev (typesafe.ai) 또는 로컬 Ollama 모델을 추가할 수 있습니다.
Jenner에 포함. 외부 서비스도 API 키도 필요 없고, 모델을 추가하기로 선택하지 않는 한 데이터가 네트워크 밖으로 나가지 않습니다. 추가할 수 있는 모델은 Jev (typesafe.ai) 또는 로컬 Ollama 모델입니다.
주소가 키이지만, 그 키가 두 번 다시 같은 방식으로 입력되지 않는 여섯 가지 업무.
신청자는 휴대전화로, 급하게, 주소를 한 번 입력합니다. Matcha는 신청자가 아직 페이지에 있는 동안 참조 테이블과 대조해 주소를 해결하고, 두 레코드가 똑같이 그럴듯할 때는 결정적인 필드 하나를 지목하므로, 양식은 검사를 실패시키거나 그냥 통과시키는 대신 "Milton or Morton?"라고 물을 수 있습니다.
스크리닝은 비용이 뒤집힌 매칭입니다. 놓친 적중은 비싸고 오경보는 쌉니다. Matcha는 이 비용을 입력으로 받아 임계값을 그에 맞게 옮기므로, 고객을 온보딩하는 엔진으로 고객을 스크리닝할 수도 있습니다. 주소는 지금 바로 사용할 수 있으며, 제재 및 PEP 목록에 대한 개인 및 사업체 이름 스크리닝은 같은 엔진에서 같은 판정으로 실행됩니다.
Matcha는 검토한 모든 후보를 필드별 근거와 함께, 그리고 정답이 테이블에 아예 없을 확률과 함께 보고합니다. 사기 규칙은 단일 점수가 아니라 매처가 실제로 살펴본 내용을 바탕으로 동작할 수 있으며, IP 위치 엔터티는 세션의 위치를 고객이 신고한 주소와 대조합니다.
같은 가구가 가입, 주문, 가져오기에 걸쳐 열 가지 형태로 나타납니다. Matcha는 테이블을 자기 자신과 매칭하고, 클러스터를 기록하며, 모든 연결에 보정된 확률을 유지하므로, 중복 제거는 그 결과가 쓰일 우편 발송에 맞춰 엄격하게도 관대하게도 할 수 있습니다. 주소와 성에 의한 가구 묶기는 같은 엔진의 복합 엔터티입니다.
잘못된 배송은 재방문 비용을, 거부된 주문은 판매 손실을 낳습니다. Matcha는 각 주소를 해당 로케일의 우편 규칙에 맞게 표준화하고, 배송 가능 주소 테이블과 매칭하며, 주소가 실재하지만 서비스 지역 밖이거나 실재하지만 테이블에 없을 때 이를 알려 주므로, 수정이 올바른 곳으로 갑니다.
한 도시의 필지 조회 서비스는 주민이 주소를 문자로 보내면 자신의 필지를 돌려받게 합니다. 가장 어려운 사례, 즉 이전 매처가 매번 틀렸던 철자 오류와 받아쓰기 실수에서 Matcha 엔진 단독으로 첫 시도에 81%를 정확히 답했고, 나머지에 모델을 적용하자 91%에 이르렀습니다.
Jenner 바이너리 안의 네이티브 Rust. 하나의 스텝, 하나의 판정 테이블, 그리고 각각에 대한 이유.
각 주소는 번지, 방향, 도로명, 접미사, 호수, 도시, 우편번호로 분리되고, 해당 로케일의 우편 규칙(미국은 USPS Publication 28, 캐나다는 Canada Post)에 맞게 정규화됩니다. 텍스트가 모호한 경우 파서는 모든 해석을 유지하고 참조 데이터가 결정하게 합니다.
엔진은 사용자의 참조 테이블에서 도로명 어휘를 구축하고, 입력된 도로명을 철자, 발음, 공식 별칭으로 그에 맞춥니다. 후보는 번지, 우편번호, 도로명으로 찾으므로 잘못된 ZIP이 치명적이지 않습니다.
번지, 도로명, 접미사, 방향, 호수, 우편번호는 따로따로 비교되고, 그 근거가 합쳐져 보정된 확률이 됩니다. 접미사 누락은 참조 데이터에 그 이름의 도로가 하나뿐이면 아무 비용도 들지 않고, 둘이면 질문을 제기합니다.
잘못된 매칭, 놓친 매칭, 후속 질문이 사용자의 프로세스에서 각각 얼마의 비용인지 지정합니다. 엔진은 기대 비용이 가장 낮은 판정을 고르므로, 사용자의 수치에 비추어 충분히 확신할 때만 매칭하고 그렇지 않을 때는 잘못된 매칭 대신 매칭 없음을 반환합니다.
입력마다 판정, 확률, 이유가 담긴 한 행. 후보마다 필드별 근거가 담긴 한 행. 입력이 매칭되지 않은 이유를 말해 주는 지표 테이블. 아무것도 조용히 버려지지 않습니다.
선택적으로, 엔진이 결정하지 못한 사례는 후보와 함께 같은 스텝 안에서 언어 모델로 보내집니다. 모델은 후보 하나를 고르거나 맞는 후보가 없다고 답하며, 주소를 고쳐 쓰는 일은 결코 없습니다.
| match | 한 후보가 높은 확률로 올바른 레코드입니다. 그대로 사용하세요. |
|---|---|
| likely | 가장 확률이 높은 후보로, 그 확률이 match 임계값보다 낮을 때 실제 확률과 함께 보고됩니다. 결코 무작위 선택이 아닙니다. |
| nonmatch | 그럴듯한 후보가 없습니다. 찾지 못한 것으로 취급하세요. 검토한 후보는 그래도 보고됩니다. |
| review | 엔진이 결정하지 못했고, 사용자의 프로세스가 물어볼 수 있습니다. 후속 질문 채널에 비용을 책정한 경우에만 출력됩니다. |
| not_in_table | 참조 데이터에 없는 실재 주소입니다. 입력이 아니라 참조 데이터를 고치세요. |
| out_of_area | 우편번호나 지명이 참조 데이터의 지역 밖에 있습니다. 다른 곳으로 보내세요. |
대부분의 매처는 어려운 사례를 아무도 담당하지 않는 수동 검토 대기열로 넘깁니다. Matcha는 후보 사이에서 결정하지 못할 때 그 이유를 압니다. 입력은 1200 Milton Street였고, 참조 데이터에는 1200 Milton St와 1200 Morton St가 있습니다. 모양도 소리도 비슷한 두 도로명입니다. 이는 한 단어로 답할 수 있는 질문입니다.
그래서 후속 질문 채널에 비용을 책정하면, 미결 행은 review로 출력되며 순위가 매겨진 후보, 결정적인 바로 그 필드(ask about street, ask about unit), 그리고 질문할 가치가 있는지 프로세스가 판단하는 데 필요한 확률이 함께 제공됩니다. SMS 서비스는 "Milton or Morton?"라고 답신합니다. 온보딩 양식은 두 주소를 보여 줍니다. 콜센터 화면은 빈칸 대신 상담원에게 후보를 보여 줍니다. 비용이 책정된 채널이 없으면 review 판정은 없습니다. 그 행들은 같은 후보와 이유가 첨부된 nonmatch가 됩니다.
Matcha에 정답 파일, 즉 올바른 레코드를 보증할 수 있는 수백 건의 입력을 주면, 한 번의 실행으로 모든 판정이 그에 대해 채점됩니다. 첫 시도 정답, 이루어진 매칭의 정밀도, 오답, 상위 다섯 후보 내 재현율, 보정 곡선, 그리고 각 오류 가중치의 기대 비용까지 제공되므로, 추측 대신 곡선에서 사용자의 가중치를 고를 수 있습니다.
두 가지 테스트. 하나는 일반 대중의 입력에 대해, 다른 하나는 미국 6개 지역에 걸쳐 의도적으로 손상시킨 주소에 대해 수행했습니다. 수치는 문서에 공개된 그대로입니다.
주민들이 도시 필지 조회 서비스에 입력한 약 2,400건의 주소를 약 378,000건의 필지 등록부와 대조했으며, 올바른 필지는 그 뒤에 일어난 일로 알 수 있었습니다. 가장 어려운 223건, 즉 실제 철자 오류, 받아쓰기 흔적, 접미사 누락에서 도시의 이전 매처는 첫 시도에 매번 틀렸습니다.
엔진 단독으로 첫 시도에 정확히 매칭한 어려운 사례
나머지에 로컬 모델 또는 Jev 적용 시
쉬운 사례와의 일치율, 엔진 단독에서 엔진과 모델 결합까지
무작위로 고른 6개 ZIP 지역에서 National Address Database로부터 추출한 3,000건의 실제 주소를, 실제 데이터에서 측정한 오류 구성(철자 오류, 누락된 방향과 접미사, 약어, 붙어 버린 토큰, 숫자 실수)으로 손상시켰습니다. 정답은 정확히 알려져 있으며, 모든 입력은 사람에게 넘기는 것 없이 매칭 또는 비매칭으로 끝납니다.
엔진 단독으로 첫 시도에 올바른 매칭
이루어진 매칭의 정밀도
오답, 약 60건 중 1건
나머지에 Jev 또는 로컬 모델 적용 시 첫 시도 정답
유사도 점수만으로는 위험합니다. 퍼지 도로명 매칭을 켜고 그 위에 아무것도 두지 않았을 때는 주소 네 건 중 한 건이 잘못 돌아왔습니다. 대체 해석, 별칭, 건물 해결이 대부분의 일을 하고, 판정 계층이 충분히 확신하지 못할 때 잘못된 매칭 대신 매칭 없음을 반환하는 방식으로 오답을 3.6%에서 0.7%로 줄입니다. 비용 가중치로 이 트레이드오프를 어느 쪽으로든 옮길 수 있습니다.
같은 3,000건의 손상된 주소를 계층을 하나씩 켜 가며 매칭했습니다. 1단계부터 5단계까지는 누적이며, 마지막 두 가지는 전체 엔진의 잔여분에 대한 대안입니다.
정확한 문자열 일치는 34.6%를 맞히고 틀린 것은 없습니다. 파싱과 표준화는 올바른 매칭을 48.8%로 올리지만 잘못된 매칭도 20.8%로 올립니다. 퍼지 도로명 매칭은 올바른 매칭을 64.5%로, 잘못된 매칭을 25.0%로 올립니다. 대체 표기, 별칭, 호수는 올바른 매칭을 89.3%로 끌어올리고 잘못된 매칭을 3.6%로 낮춥니다. 비용 인식 판정, 즉 전체 엔진은 84.1%를 맞히고 0.7%를 틀립니다. 그 엔진의 잔여분에서 로컬 Ollama 모델은 90.0% 정답에 2.1% 오답, Jev는 88.5% 정답에 0.8% 오답에 도달합니다.
| 단계 | 올바른 매칭 | 잘못된 매칭 | 놓침 |
|---|---|---|---|
| 단계 1: 정확 일치 | 34.6% | 0.0% | 65.4% |
| 단계 2: 파싱 및 표준화 | 48.8% | 20.8% | 30.4% |
| 단계 3: 퍼지 도로명 | 64.5% | 25.0% | 10.5% |
| 단계 4: 대체 표기 및 호수 | 89.3% | 3.6% | 7.1% |
| 단계 5: 비용 인식 판정 | 84.1% | 0.7% | 15.2% |
| + 잔여분에 AI: 로컬 AI (Ollama) | 90.0% | 2.1% | 7.8% |
| + 잔여분에 AI: Jev (TypeSafe) | 88.5% | 0.8% | 10.7% |
출처: 무작위로 고른 여섯 ZIP 지역의 실제 미국 주소 3,000건. National Address Database에서 추출해 실제 데이터에서 측정한 오류 구성으로 손상시켰으므로 정답을 정확히 알 수 있습니다. 수치는 PROC MATCHA 문서에 게시된 그대로입니다.
Matcha는 모든 Jenner 라이선스에 포함되어 있습니다. Jenner를 구매하거나, PROC MATCHA 문서를 읽거나, 매칭 문제를 알려 주시면 평가 실행 설정을 도와 드립니다.
언어 모델은 행당 비용이 비싸고 행당 속도가 느립니다. Matcha는 유능한 분석가가 그러하듯 판단이 필요한 사례에만 모델을 사용합니다.
Ollama를 통해 로컬 모델을 자체 하드웨어에서 완전 오프라인으로 실행하므로 컴퓨터 밖으로 아무것도 나가지 않습니다. 벤치마크에는 qwen2.5:7b-instruct를 사용합니다. 로컬 모델은 행당 비용이 없고 제시된 거의 모든 질문에 답하므로 가장 많은 일치를 찾지만 오답도 대략 두 배가 됩니다.
Jev는 텍스트를 생성하는 대신 형식이 정해진 질문, 즉 후보 중 어느 것이(있다면) 이 주소와 같은 장소인지에 답하고, 보정된 확률과 함께 선택을 반환합니다. 0.9라고 말하면 약 90%의 경우 맞고, 확신이 없으면 추측하지 않고 맞는 후보가 없다고 답합니다. 이는 비용을 고려하는 매처에 꼭 필요한 형태이며, Jev가 엔진 자체의 정밀도를 유지하면서 매칭을 더할 수 있는 이유입니다.
Matcha가 Jev를 사용하는 방식 →측정된 실행에서 미결 구간은 입력의 2%에서 8%이므로, 100,000건의 주소 작업은 십만 번이 아니라 수천 번의 모델 호출을 만듭니다.
둘 다 선택 사항이며 둘 다 기본적으로 꺼져 있습니다. 엔진은 어느 쪽도 필요로 하지 않으며, 원격 모델은 구성에서 allow_remote를 설정한 뒤에만 사용할 수 있습니다.
Jev는 TypeSafe (typesafe.ai)가 만듭니다. Matcha는 엔진이 판정하지 못한 나머지 사례에만 Jev를 호출합니다.
Jev는 TypeSafe의 System One 모델입니다. 텍스트를 생성하는 대신 타입이 정해진 질문, 즉 어떤 후보가 (있다면) 이 주소와 같은 장소인지에 답하고, 선택과 보정된 확률과 신뢰도를 반환합니다. System One 모델은 이런 형태의 판단을 위해 만들어졌으며 대화를 위한 것이 아닙니다.
바로 그 형태가 비용을 고려하는 매처에 필요한 것입니다. 보정되었다는 것은 Jev가 0.9라고 말하면 약 90%의 경우 옳다는 뜻이므로, 엔진은 그 답을 잘못된 일치의 비용과 견주어 판단할 수 있고, Jev는 확신이 없을 때 추측하지 않고 맞는 후보가 없다고 답합니다.
Matcha는 나머지 사례, 즉 엔진이 스스로 판정하지 못하는 사례에만 Jev를 사용하므로 주소 100,000건 작업에서도 Jev 호출은 수천 번이지 십만 번이 아닙니다. TypeSafe API 키를 환경 변수에 두고, PROC MATCHA 단계에 adjudicate provider=jev;를 추가하며, 그 사례들이 컴퓨터 밖으로 나가도 된다고 결정하기 전까지 allow_remote는 꺼 두십시오.
export TYPESAFE_API_KEY=... # never in a file
adjudicate provider=jev; # inside the PROC MATCHA step손상된 주소 벤치마크에서 측정하면 Jev는 엔진 자체의 정밀도 98.1%를 유지한 채 올바른 일치를 83.3%에서 87.8%로 끌어올리며, 단계별 절제 실험에서 오답은 0.8%였습니다. 일반인이 입력한 실제 조회에서는 어려운 사례를 로컬 모델만큼 자주 해결했고, 올바른 후보가 없을 때는 하나를 고르는 대신 그렇다고 답했습니다.
typesafe.ai의 글 읽기: Introducing System One models and Jev
엔진은 사용자가 제공한 테이블에 대해 매칭하며, 공개 지식 팩이 이를 돕습니다. National Address Database의 미국 주소 지점, Census TIGER의 도로명 별칭, Statistics Canada의 캐나다 주소로, 모두 퍼블릭 도메인이거나 공개 라이선스입니다. Jenner Analytics는 출처가 새로 공개될 때 팩을 다시 빌드하고, 이전 릴리스와 대조해 검증하고, 서명한 뒤 데이터 채널에 게시합니다.
사용자가 직접 업데이트를 실행하기 전까지 장비에서는 아무것도 바뀌지 않습니다. 모든 팩은 한 바이트라도 풀리기 전에 서명된 매니페스트와 대조해 검증되고 원자적으로 교체되므로, 실행 중인 작업은 이전 팩이나 새 팩 중 하나만 보며 부분적인 팩을 보는 일은 결코 없습니다. PROC MATCHA는 아무것도 다운로드하지 않으며, 보고서에는 실행에 사용된 데이터 릴리스가 기록됩니다.
jenner data update --check # what would change; writes nothing
jenner data update # install or refresh every pack
jenner data update --pin 2026.9.28미국이 기본이며 캐나다는 이중 언어 형식을 포함해 지원됩니다. 영국, 프랑스, 일본, 한국, 호주용 로케일 팩은 준비 중입니다. 각 팩은 코드가 아니라 데이터이므로, 국가를 추가하는 것은 팩을 추가하는 것입니다.
주소는 지금 바로 사용할 수 있습니다. KYC 계열의 다른 모든 매칭도 같은 엔진에서 실행됩니다. 같은 보정된 확률, 같은 비용 가중 판정, 같은 출력, 같은 평가 실행입니다.
새로운 종류의 매칭은 새 제품이 아니라 엔터티 정의입니다. 레코드가 갖는 역할, 역할별 비교기, 블로킹 전략, 참조할 수 있는 지식 팩으로 이루어집니다. 점수 산정, 판정, 후속 질문 목록, 평가는 공유 코드이므로 개인 이름 매칭은 주소 매칭과 정확히 같은 방식으로 평가되고 비용이 책정됩니다.
Matcha는 세션 IP 주소의 지오로케이션 위치를 고객이 신고한 주소와 비교하며, 지오로케이션 반경을 불확실성으로 삼아 측지 거리를 사용합니다. ASN, 프록시, VPN 플래그는 불리한 증거로 계산될 뿐, 단독으로 결론이 되지는 않습니다. 결과는 주소 매칭과 같은 보정된 확률과 비용 가중 판정이므로 사기 규칙이 바로 조치하거나 review로 보낼 수 있습니다.
예시: 카드 신청자가 VPN 플래그 없이 40 km 떨어진 곳으로 지오로케이션되는 IP에서 덴버 주소를 제출: 반경 안에서 일치. 같은 주소를 다른 나라의 데이터센터 IP에서 제출: 충돌이며, 해당 행은 review로 비용이 책정됩니다.
지원 시기 문의이메일 신원 엔터티는 주소가 온보딩 시 신고한 개인과 조직의 것인지 검사합니다. 로컬 파트는 이름 토큰과 비교되며 first.last 형식, 이니셜, 별명이 포함됩니다. 도메인은 조직의 등록 도메인과 비교되고, 무료 메일과 일회용 도메인 목록, MX 레코드 존재 여부가 증거가 됩니다. 모든 신호가 비교기이며, 엔진은 그것들이 얼마나 강하게 일치하는지 말해 줍니다.
예시: [email protected]을 Northwind Actuarial의 Jane Okafor와 대조: 로컬 파트는 이름과 일치하고 도메인은 회사와 일치합니다. [email protected]을 같은 레코드와 대조: 일회용 도메인이며, 확률이 그 사실을 말해 줍니다.
지원 시기 문의사업체 엔터티는 ISO 20275에 따라 법인 형태를 제거하고, 희귀 단어에 가중치를 주며, 약어를 확장하고, 등기 식별자(LEI, EIN, UEI, Companies House 번호)가 이름을 재정의하게 합니다. GLEIF Level 1 데이터와 EDGAR 이전 상호는 지식 팩이므로 상호를 바꾼 회사도 장부상의 거래 상대와 여전히 매칭됩니다. 공급업체 검증, 거래 상대 매칭, KYB가 같은 실행을 사용합니다.
예시: "INTL BUSINESS MACHINES CORP"를 "International Business Machines Corporation"과 일치하는 LEI와 함께 대조: match, 등기 ID 재정의. "IBM Credit LLC"를 모회사와 대조: nonmatch, 법인 형태와 희귀 단어 근거가 보고됩니다.
지원 시기 문의개인 엔터티는 이름, 중간 이름, 성을 별명 팩, 키릴·아랍·CJK 문자로부터의 음역, 음성 비교, 이름 순서 변형으로 비교하고, 자리가 바뀐 생년월일이나 체크섬이 유효한 국가 ID를 그에 걸맞은 증거로 취급합니다. 제재 또는 PEP 목록은 놓친 매칭의 비용을 높게 설정한 일반 참조 테이블이므로, 스크리닝과 고객 중복 제거는 가격만 다른 같은 엔진입니다.
예시: "Mohammed Al-Rashid, 03/07/1981"을 "Muhammad Alrashid, 07/03/1981"과 대조: 음역이 일치하고 날짜는 일과 월이 뒤바뀐 것이므로, 해당 행은 놓친 건이 아니라 확률이 붙은 스크리닝 적중으로 돌아옵니다.
지원 시기 문의전화번호는 E.164로 정규화되고 국가 및 지역 일관성과 통신사 유형이 확인됩니다. 식별자는 매칭 전에 검증됩니다. IBAN, VIN, NPI 체크섬, 형식과 발급 기관 일관성, 국가 ID 형태입니다. 유효한 식별자는 강력한 증거이며, 무효한 식별자는 그 자체로 발견 사항이 되어 후보 하나가 점수를 받기도 전에 보고됩니다.
예시: 신청자의 IBAN이 mod-97 검사에 실패: 해당 행은 참조 테이블의 모든 계좌와 대조되는 대신, 매칭 전에 이유와 함께 플래그가 붙습니다.
지원 시기 문의엔터티는 조합됩니다. 기기 좌표는 가장 가까운 주소 지점으로 역지오코딩되고, 가구는 주소 매칭에 성의 일치를 더한 것이며, 거래 상대는 사업체나 개인에 계좌와 국가를 더한 것이고, 제품명이나 약품명은 코드 재정의가 있는 토큰 포함으로 매칭됩니다. 점수 산정 코드는 그 차이를 알지 못하며, 그래서 각각이 같은 엔진에 같은 평가 실행과 함께 도착합니다.
예시: 배송 앱의 GPS 위치가 주문 주소에서 30 m 지점에 찍힘: 일치, 거리가 보고됩니다. 한 주소에 성이 일치하는 두 고객 레코드: 하나의 가구, 연결에 보정된 확률이 붙습니다.
지원 시기 문의신청자가 제공한 주소, 이메일, 전화번호, 식별자를 한 단계로 검증하고, 검사마다 하나의 확률을, 모호한 경우에는 하나의 후속 질문을 받습니다. Matcha는 신청자가 아직 페이지에 있는 동안 주소를 해결하고, 검사를 실패시키거나 그냥 통과시키는 대신 "Milton or Morton?"라고 묻습니다.
지원 시기 문의 →세션의 IP 위치를 신고된 주소와, 기기 좌표를 배송 주소와, 이메일을 개인과 비교하고, 블랙박스 점수가 아니라 규칙이 조치할 수 있는 증거를 얻으세요. 매처가 검토한 모든 후보가 정답이 테이블에 아예 없을 확률과 함께 보고됩니다.
지원 시기 문의 →음역, 별명, 음성 비교, 생년월일 자리바꿈을 적용해 개인 및 사업체 이름을 제재 및 PEP 목록에 대해 스크리닝하며, 비용은 스크리닝에 맞게 책정됩니다. 놓친 적중은 비싸고 오경보는 쌉니다. 목록은 참조 테이블이고, 평가 실행은 알려진 사례에 대한 적중률을 채점하며, 보정 곡선은 사용자 데이터에서 0.9가 무엇을 뜻하는지 알려 줍니다.
지원 시기 문의 →신청서, 거래, 원장에 나오는 사업체를 법인 형태, 이전 상호, 등기 식별자를 넘어 하나의 법적 실체로 식별해 익스포저를 한 번만 계산합니다. LEI, EIN, UEI, Companies House 번호는 있을 때는 이름을 재정의하고 없을 때는 이름을 뒷받침합니다.
지원 시기 문의 →모든 주소를 해당 로캘의 우편 규칙으로 표준화하고, 배송 가능 주소 테이블과 매칭하며, 주소가 실재하지만 지역 밖인지 또는 실재하지만 테이블에 없는지를 파악합니다. 문 앞의 기기 좌표가 배송 지점을 확인하고, 비용 가중치가 잘못된 주소가 거부된 주문보다 나쁜 때를 판정합니다.
지원 시기 문의 →모든 판정에 확률, 이유, 검토한 후보가 붙어 사용자가 보관하는 테이블에 기록됩니다. 모델을 추가하기로 선택하지 않는 한 아무것도 장비를 떠나지 않고, 보고서는 실행이 사용한 데이터 릴리스를 기록하며, 같은 평가 실행이 몇 달 뒤 감사인을 위해 결과를 재현합니다.
지원 시기 문의 →PROC MATCHA는 Jenner의 일부이며, 별도 제품도 행당 요금도 아닙니다. Windows와 Linux에서 Jenner 라이선스는 장비당 한 번 구매하는 영구 라이선스입니다. 구매한 버전은 원하는 만큼 계속 실행되며, 새 릴리스와 지원은 1년간 포함됩니다. macOS용 Jenner는 Mac App Store에 있으며, Workspace는 시간 단위로 청구됩니다.
매칭된 행, 검토된 후보, 던져진 질문에 대해 Jenner Analytics가 청구하는 요금은 없습니다. Jev를 선택하면 TypeSafe가 입력 토큰당 요금을 책정하며, Jev는 나머지 사례만 봅니다.
Jenner 구매요금 보기
주소는 지금 바로 사용할 수 있습니다. 보유하신 데이터로 평가 실행을 요청하거나 같은 엔진의 기능 지원 시기를 문의하시면, 일정과 설정에 필요한 사항을 답변해 드립니다.
