PROC MATCHA
Matcha は、乱雑で、綴りが誤っていたり、入力途中だったりする住所を、本来指しているレコードに結び付けます。お使いのマシン上で動作し、すべての判定に較正された確率と理由を添えます。個人名、企業名、メールアドレス、IP 位置情報、識別子も同じエンジン上で動作します。 難しいケースには Jev (typesafe.ai) またはローカルの Ollama モデルを追加できます。
Jenner に同梱。外部サービスも API キーも不要で、モデルを追加すると選ばない限りデータはネットワークの外に出ません。追加できるのは Jev (typesafe.ai) またはローカルの Ollama モデルです。
住所がキーとなり、しかもそのキーが二度と同じようには入力されない、6 つの業務。
申込者は住所を一度だけ、スマートフォンで、急いで入力します。Matcha は申込者がまだページにいる間に、その住所を参照テーブルと照合して解決します。二つのレコードが同程度に妥当な場合は、決め手となる一つのフィールドを特定するため、フォームは審査を失敗させたり素通しにしたりする代わりに「Milton or Morton?」と尋ねることができます。
スクリーニングとは、コストを逆転させたマッチングです。ヒットの見逃しは高くつき、誤警報は安く済みます。Matcha はこのコストを入力として受け取り、それに合わせてしきい値を動かすため、顧客をオンボーディングするのと同じエンジンで顧客をスクリーニングできます。住所は今日から利用できます。制裁リストや PEP リストに対する個人名・企業名のスクリーニングも、同じエンジン上で同じ判定により実行されます。
Matcha は検討したすべての候補を、フィールドごとの根拠と、正解がテーブルにまったく存在しない確率とともに報告します。不正ルールは、単一のスコアではなく、マッチャーが実際に見たものの範囲内で動作できます。IP 位置情報エンティティは、セッションの位置を顧客が申告した住所と照合します。
同じ世帯が、サインアップ、注文、インポートにまたがって 10 通りの形で現れます。Matcha はテーブルをそれ自身と照合し、クラスタを書き出し、すべてのリンクに較正された確率を保持するため、重複排除は、それが供給する郵送物に応じて厳格にも寛容にもできます。住所と姓による世帯化は、同じエンジン上の複合エンティティです。
誤配送は再配達のコストを、注文の拒否は販売機会の損失を招きます。Matcha は各住所をそのロケールの郵便規則に標準化し、配送可能住所テーブルと照合して、住所は実在するが対象エリア外である、あるいは実在するがテーブルに欠けているときにそれを知らせるため、修正が正しい場所に届きます。
ある市の区画検索サービスでは、住民が住所をテキストで送ると自分の区画が返ってきます。最も難しいケース、つまり以前のマッチャーが毎回間違えていた綴りの誤りや音声入力のミスに対して、Matcha エンジン単体で初回に 81% を正しく回答し、残りにモデルを適用すると 91% に達しました。
Jenner バイナリ内のネイティブ Rust。1 つのステップ、1 つの判定テーブル、そしてそれぞれに理由。
各住所は番地、方角、通り名、接尾辞、部屋番号、市、郵便番号に分割され、そのロケールの郵便規則(米国は USPS Publication 28、カナダは Canada Post)に正規化されます。テキストが曖昧な場合、パーサーはすべての読み方を保持し、参照データに判断を委ねます。
エンジンはお使いの参照テーブルから通り名の語彙を構築し、入力された通り名を綴り、発音、公式の別名によってそれに合わせます。候補は番地、郵便番号、通り名から検索されるため、ZIP の誤りは致命的ではありません。
番地、通り名、接尾辞、方角、部屋番号、郵便番号は個別に比較され、その根拠が合わさって較正された確率になります。接尾辞の欠落は、参照データにその名前の通りが 1 つしかなければコストがかからず、2 つあれば疑問を提起します。
誤ったマッチ、マッチの見逃し、追加の問い合わせが、お客様のプロセスでそれぞれいくらのコストになるかを指定します。エンジンは期待コストが最小となる判定を選ぶため、お客様の数値に照らして十分に確信できるときだけマッチし、そうでないときは誤ったマッチではなく「マッチなし」を返します。
入力ごとに判定、確率、理由を記した 1 行。候補ごとにフィールド単位の根拠を記した 1 行。入力がマッチしなかった理由を示すメトリクステーブル。何も黙って捨てられることはありません。
オプションとして、エンジンが決着をつけられないケースは、その候補とともに、同じステップの中で言語モデルに送られます。モデルは候補を 1 つ選ぶか、どの候補も当てはまらないと答えるかのどちらかで、住所を書き換えることは決してありません。
| match | 1 つの候補が高い確率で正しいレコードです。そのまま使えます。 |
|---|---|
| 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 に正解ファイル、つまり正しいレコードを保証できる数百件の入力を与えると、1 回の実行ですべての判定がそれに対して採点されます。初回正答、行われたマッチの適合率、誤答、上位 5 候補内の再現率、較正曲線、そして各誤りの重みにおける期待コストです。これにより、推測ではなく曲線からお客様の重みを選べます。
2 つのテスト。1 つは一般市民の入力に対して、もう 1 つは米国 6 地域にわたる意図的に破損させた住所に対して行いました。数値はドキュメントに公開されているとおりです。
住民が市の区画検索サービスに入力した約 2,400 件の住所を、約 378,000 件の区画レジスタと照合しました。正しい区画は、その後に起きたことから判明しています。最も難しい 223 件のケース、つまり実際の綴り誤り、音声入力の痕跡、接尾辞の欠落に対して、市の以前のマッチャーは初回に毎回間違えていました。
エンジン単体で、難しいケースを初回に正しくマッチ
残りにローカルモデルまたは Jev を適用した場合
簡単なケースとの一致率、エンジン単体からエンジンとモデルの併用まで
無作為に選んだ 6 つの ZIP 地域から National Address Database より抽出した 3,000 件の実在住所を、実データから測定した誤りの構成(綴りの誤り、方角と接尾辞の欠落、略語、連結されたトークン、数字の誤り)で破損させました。正解は正確に分かっており、すべての入力は人に回されることなく、マッチか非マッチのいずれかで終わります。
エンジン単体で初回に正しくマッチ
行われたマッチの適合率
誤答、およそ 60 件に 1 件
残りに Jev またはローカルモデルを適用した場合の初回正答
類似度スコア単体は危険です。あいまいな通り名マッチングを有効にし、その上に何も置かなかった場合、住所の 4 件に 1 件が誤って返ってきました。代替の読み方、別名、建物の解決が仕事の大半を担い、判定レイヤーが十分に確信できないときに誤ったマッチではなく「マッチなし」を返すことによって誤答を 3.6% から 0.7% に減らします。コストの重みによって、このトレードオフをどちらの方向にも動かせます。
同じ 3,000 件の破損住所を、レイヤーを 1 つずつ有効にしてマッチングしました。ステージ 1 から 5 は累積で、最後の 2 つはフルエンジンの残余に対する代替手段です。
完全一致では 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% |
出典：無作為に選んだ 6 つの ZIP エリアの実在の米国住所 3,000 件。National Address Database から抽出し、実データから測定した誤りの構成比で破損させたため、正解は正確に分かっています。数値は PROC MATCHA ドキュメントで公開されているものです。
Matcha はすべての Jenner ライセンスに含まれています。Jenner を購入するか、PROC MATCHA のドキュメントを読むか、お客様のマッチングの課題をお聞かせください。評価実行のセットアップをお手伝いします。
言語モデルは 1 行あたりのコストが高く、1 行あたりの処理が遅いものです。Matcha は優れたアナリストがそうするように、判断を要するケースにのみモデルを使います。
Ollama を通じてローカルモデルを自前のハードウェアで、完全オフラインで実行できるため、マシンの外には何も出ません。ベンチマークには qwen2.5:7b-instruct を使っています。ローカルモデルは行あたり無料で、提示されたほぼすべての問いに答えるため、最も多くの一致を見つける一方で誤答をおよそ 2 倍にします。
Jev はテキストを生成する代わりに、型付きの質問、つまり候補のうちどれがこの住所と同じ場所か(該当があれば)に答え、較正された確率付きの選択を返します。0.9 と答えたときは約 90% の確率で正しく、確信がないときは推測せず、どの候補も当てはまらないと答えます。これはまさにコストを意識したマッチャーが必要とする形であり、Jev がエンジン自身の適合率を保ったままマッチを追加できる理由です。
Matcha が Jev をどう使うか →測定した実行では未決定の帯域は入力の 2% から 8% であり、100,000 件の住所のジョブで発生するモデル呼び出しは 10 万回ではなく数千回です。
どちらもオプションで、どちらもデフォルトでは無効です。エンジンはいずれも必要とせず、リモートモデルは設定で 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% でした。一般の人が入力した実際の検索では、難しいケースをローカルモデルと同じ頻度で解決し、正しい候補がないときは 1 つを選ぶのではなく、そう答えました。
typesafe.ai の記事を読む: Introducing System One models and Jev
エンジンはお客様が与えたテーブルに対してマッチングを行い、オープンなナレッジパックがそれを支えます。National Address Database からの米国住所ポイント、Census TIGER からの通り名の別名、Statistics Canada からのカナダの住所で、すべてパブリックドメインまたはオープンライセンスです。Jenner Analytics はソースが公開されるたびにパックを再構築し、前回のリリースと照らして検証し、署名して、データチャネルに公開します。
お客様が自ら更新を実行するまで、お使いのマシン上では何も変わりません。すべてのパックは 1 バイトも展開される前に署名付きマニフェストと照合して検証され、アトミックに差し替えられるため、実行中のジョブが見るのは古いパックか新しいパックのどちらかであり、部分的なパックを見ることは決してありません。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 の形式です。有効な識別子は強力な証拠であり、無効な識別子はそれ自体が所見として、候補が 1 つもスコアリングされる前に報告されます。
例: 申込者の IBAN が mod-97 チェックに失敗：その行は参照テーブルのすべての口座に対してスコアリングされる代わりに、マッチングの前に理由付きでフラグ付けされます。
提供時期を問い合わせるエンティティは合成できます。デバイスの座標は最寄りの住所ポイントに逆ジオコーディングされ、世帯は住所マッチングと姓の一致、取引相手は企業または個人と口座と国、製品名や医薬品名はコードによる上書き付きのトークン包含によってマッチします。スコアリングコードはその違いを知らないため、それぞれが同じエンジン上に同じ評価実行とともに到着します。
例: 配送アプリの GPS 測位が注文の住所から 30 m の地点に落ちる：一致、距離を報告。同じ住所に姓の一致する 2 件の顧客レコード：1 つの世帯、リンクに較正された確率付き。
提供時期を問い合わせる申込者が入力した住所、メールアドレス、電話番号、識別子を 1 ステップで検証し、チェックごとに 1 つの確率と、あいまいな場合には 1 つの追加質問を得られます。Matcha は申込者がまだページにいる間に住所を解決し、チェックを失敗させたり素通しにしたりする代わりに「Milton or Morton?」と尋ねます。
提供時期を問い合わせる →セッションの IP 位置情報と申告された住所、デバイスの座標と配送先住所、メールアドレスと個人を比較し、ブラックボックスのスコアではなく、ルールが作動できる証拠を得ます。マッチャーが検討したすべての候補が、正解がテーブルにまったく存在しない確率とともに報告されます。
提供時期を問い合わせる →翻字、ニックネーム、音韻、生年月日の入れ替わりに対応しつつ、個人名と企業名を制裁リストや PEP リストに対してスクリーニングします。コストはスクリーニング向けに設定され、ヒットの見逃しは高く、誤警報は安くなります。リストは参照テーブルであり、評価実行は既知のケースに対するヒット率を採点し、較正曲線はお客様のデータで 0.9 が何を意味するかを示します。
提供時期を問い合わせる →申込書、取引、元帳に載る企業を、法人格、旧社名、登記識別子をまたいで 1 つの法人に名寄せし、エクスポージャーを一度だけ数えます。LEI、EIN、UEI、Companies House 番号は、存在すれば名前を上書きし、存在しなければ名前を裏付けます。
提供時期を問い合わせる →すべての住所をそのロケールの郵便規則に標準化し、配送可能住所テーブルと照合し、住所が実在するがエリア外なのか、実在するがテーブルにないのかを把握します。玄関先でのデバイス座標が配送地点を確認し、コストの重みが、誤った住所が注文拒否より悪いのはいつかを判定します。
提供時期を問い合わせる →すべての判定に確率、理由、検討した候補が付き、お客様が保持するテーブルに記録されます。モデルを追加すると選択しない限り何もマシンの外に出ず、レポートは実行が使用したデータリリースを記録し、同じ評価実行が数か月後に監査人のために結果を再現します。
提供時期を問い合わせる →PROC MATCHA は Jenner の一部であり、別製品でも行単位の課金でもありません。Windows と Linux では、Jenner ライセンスはマシンごとに一度購入する永続ライセンスです。購入したバージョンは使いたい限りいつまでも動作し、新リリースとサポートは 1 年間含まれます。macOS 版 Jenner は Mac App Store で提供され、Workspace は時間単位で課金されます。
マッチした行、検討した候補、行った質問に対して Jenner Analytics から課金されることはありません。Jev を選択した場合は TypeSafe が入力トークン単位で課金し、Jev が見るのは残りのケースだけです。
Jenner を購入料金を見る
保証できる数百件のレコードに対して評価を実行し、お客様のデータでどれほど優れているかを示す正直な数値を 1 つ手に入れてください。
住所は今日から利用できます。お客様自身のデータでの評価実行を依頼するか、同じエンジン上の機能の提供時期をお問い合わせください。日程とセットアップに必要なことをご返信します。
Jenner を購入してお手元の住所で PROC MATCHA を実行するか、ドキュメントを読むか、Jenner の 3 分間の紹介動画をご覧ください。
