テキストで何かを見つける方法

オブジェクトの検索またはテキスト内の概念の認識-これがほとんどのNLP問題の始まりです。検索エンジンの設計、音声アシスタントの作成、またはカスタムクエリの分類を行う場合は、最初に入力テキストを解析し、日付、国、都市などの一般的な名前のエンティティ、または特定のモデルに固有の名前付きエンティティを見つけようとする必要があります。現在、正確に何を探しているのか、またはテキストで何が発生する可能性があるのか​​が事前にわかっているタイプのタスクについてのみ話していることに注意してください。









NER（名前付きエンティティ認識）コンポーネント、つまり名前付きエンティティを検索するためのソフトウェアコンポーネントは、テキスト内のオブジェクトを検索し、可能であれば、そこから情報を取得する必要があります。例-「22枚のマスクをください。」数値NERコンポーネントは、指定されたテキストで「22」というフレーズを見つけ、これらの単語から数値正規化値「22」を抽出します。これで、この値を使用できます。



NERコンポーネントは、ニューラルネットワークに基づくことも、ルールや内部モデルに基づいて機能することもできます。一般的なNERコンポーネントは、多くの場合、2番目の方法を使用します。



テキスト内の標準エンティティを見つけるためのいくつかの既製のソリューションを考えてみましょう。この投稿では、制限付きの無料または無料のライブラリに焦点を当て、この問題のフレームワーク内でApacheNlpCraftプロジェクトで何が行われたかについても説明します。以下のリストは、詳細で詳細な概要ではなく、ネットワーク上にすでに十分な数がありますが、これらのライブラリを使用する主な機能、長所と短所の簡単な説明です。

NERコンポーネントプロバイダー

Apache OpenNlp

Apache OpenNlpは、日付、時刻、地理、組織、数値のパーセンテージ、および人を処理する、英語用のかなり標準的なNERコンポーネントのセットを提供します。小さなセットは他の言語（スペイン語、オランダ語）でも利用できます。



配信：

Javaライブラリ。 Apache OpenNlpは、メインプロジェクトにモデルを同梱していません。これらは個別にダウンロードできます。



長所：

Apacheライセンス。モデルは多くの実装でテストされています。



マイナス：

どうやら、モデルは理由のためにメインプロジェクトから削除されました。新しいモデルや既存のモデルの変更がかなり長い間見られなかったため、それらの作業が停止されているか、気のめいるようにゆったりとしたペースで進んでいるという印象を受けます。Apache OpenNlpユーザーは独自のモデルを作成してトレーニングできるため、このタスクは実際には完全にユーザーに任されている可能性があります。

スタンフォードNlp

スタンフォードNLPは、優れた品質と幅広い可能性を備えた、活気に満ちた絶えず進化する製品です。英語の場合、次のエンティティを認識するためのサポートが追加されました：人、場所、組織、その他、お金、数、順序、パーセント、日付、時間、期間、セット。さらに、組み込みのRegex NERコンポーネントを使用すると、電子メール、URL、都市、state_or_province、国、国籍、宗教、（役職）タイトル、イデオロギー、criminal_charge、cause_of_death、handleなどのエンティティを高精度で見つけることができます。リンクの詳細。ドイツ語、スペイン語、中国語の限定的なNERサポートが発表されました。認識の品質は、オンラインデモを使用してテストできます。



供給：

Javaライブラリ。モデルは、プロジェクトと一緒にMavenからダウンロードできます。

英語以外の言語のNERコンポーネントのリストと詳細な説明はどこにも見つかりませんでした。リンク1、2 -異なる言語のための独自のNERコンポーネントを訓練するプロセスの例が与えられています。簡単に言えば、他の言語を使用する機能が発表されていますが、いじくり回す必要があります。



長所：

プロジェクト全体および既製のモデルで作業することからの感覚が最もポジティブであり、プロジェクトは存続し、発展し、認識品質は良好です（「良好」は条件付きの概念であり、NERコンポーネント認識の品質を特徴付けるメトリックがありますが、この問題は記事の範囲を超えています）。



マイナス：

ドキュメントの混乱は別として、それらは小さいです。重要な人は、ライセンスに注意してください。GNU General Public LicenseはApacheとは異なるため、たとえば、このライセンスを持つ製品をApacheなどでライセンスされている製品に追加することはできません。

Google言語API

英語用のGoogle言語APIは、個人、場所、組織、イベント、work_of_art、consumer_good、other、phone_number、address、date、number、priceのエンティティのリストをサポートしています。



プラットフォーム：

REST API、SaaS。RESTを介した既製のクライアントライブラリが利用可能です（Java、C＃、Python、Goなど）。



長所：

NERコンポーネント、開発、品質の大規模なセットは、有名なインターネットの巨人によって提供されます。



短所：

特定のボリュームから始めて、使用は支払われます。

空間

このライブラリは、認識がサポートされているエンティティの最も幅広いセットの1つを提供します。サポートされているエンティティのリストについては、リンクを参照してください。



プラットフォーム：

Python。



残念ながら、産業利用の個人的な経験が不足しているため、このライブラリの長所と短所の実際の説明を追加することはできません。さらに、PythonNLPソリューションの詳細な概要はすでにhabrで公開されています。



上記のすべてのライブラリを使用すると、独自のモデルをトレーニングできます。また、それらすべて（Apache OpenNlpを除く）では、見つかったエンティティから正規化された値を抽出できます。つまり、クエリで見つかった数値エンティティ「173」から数値「173」を取得できます。



ご覧のとおり、名前付きエンティティを見つける問題を解決するための多くのオプションがあり、それらの開発の方向性は明らかです-サポートされている言語と認識されたエンティティのセットのリストを拡張し、認識の品質を向上させます。



以下は、ApacheNlpCraftプロジェクトがこのすでに高度に開発された領域にもたらしたものの要約です。

NlpCraftによって提供される追加機能

• 新しいエンティティ用の独自のNERコンポーネント、いくつかの既存のエンティティ用の改善されたソリューション。
• 製品使用のフレームワーク内での上記のすべてのライブラリのNERコンポーネントの統合。
• 「複合エンティティ」のサポート。これにより、ユーザーは既存のコンポーネントに基づいて新しいカスタムコンポーネントを簡単に作成できます。

これについてもう少し詳しく説明します。

独自のNERコンポーネント

Apache NlpCraftのネイティブNERコンポーネントは、日付、番号、地理、座標、並べ替え、およびさまざまなエンティティの照合を認識するためのコンポーネントです。それらのいくつかはユニークであり、いくつかは既存のソリューションの単なる改善された実装です（認識精度が向上した、追加の値フィールドが追加されたなど）。

既存のソリューションの統合

上記のソリューションはすべて、ApacheNlpCraftで使用するために統合されています。

プロジェクトで作業する場合、ユーザーは必要なモジュールを接続し、特定のモデルのエンティティを検索するときに使用するNERコンポーネントを構成で指定するだけです。



以下は、テキストを検索するときに2つのプロバイダーからの4つの異なるNERコンポーネントを使用する構成の例です。

"enabledBuiltInTokens": [
   "nlpcraft:num",
   "nlpcraft:coordinate",
   "google:organization",
   "google:phone_number"
]

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Apache NlpCraftの使用について詳しくは、こちらをご覧ください。Google Language APIを使用するには、有効なGoogle開発者アカウントが必要です。

複合エンティティのサポート

複合エンティティのサポートは、上記の機能の中で最も興味深いものです。もう少し詳しく見ていきましょう。



複合エンティティは、別のエンティティに基づいて定義されたエンティティです。例を見てみましょう。インテントベースのNLP制御システム（Alexa、Google Dialogflow、Alice、ApacheNlpraftなどを参照）を開発していて、モデルが地理的に機能するとしますが、米国のみです。 「nlpcraft：city」などの地理検索コンポーネントを使用して、直接使用できます。



さらに、インテントがトリガーされると、対応する関数（コールバック）で、フィールド「国」の値を確認する必要があります。」、および必要な条件を満たしていない場合は、誤検知を防ぎ、機能を終了します。次に、マッチングに戻り、別のより適切な関数を選択してみてください。



このアプローチの何が問題になっていますか。

• 呼び出された関数からメインワーカースレッドに制御を移したり戻したりすることで、呼び出された関数の操作がはるかに困難になります。さらに、すべての対話システムがそのような制御転送機能を備えているわけではないことを考慮する価値があります。
• インテントと実行可能なメソッドコードの間のマッチングロジックを塗りつぶします。

わかりました...独自のNERコンポーネントを最初から作成してアメリカの都市を見つけることができますが、このタスクは5分で解決されません。



別の方法で試してみましょう。 （可能な場合はそれらのシステムで）意図を複雑にし、国によってさらにフィルタリングされた都市を検索することができます。しかし、繰り返しますが、すべてのシステムが要素のフィールドによる複雑なフィルタリングの可能性を提供するわけではありません。さらに、意図を複雑にします。これは、特にプロジェクトに多くのシステムがある場合は、できるだけ明確で単純なものにする必要があります。



Apache NlpCraftは、既存のコンポーネントに基づいてネイティブNERコンポーネントを定義するためのメカニズムを提供します。以下は構成の例です（完全なDSL構文はここにあります。要素の作成例はここにあります）：

"elements": [
  {
    "id": "custom:city:usa",
    "description": "Wrapper for USA cities",
    "synonyms": [
      "^^id == 'nlpcraft:city' && lowercase(~city:country) == 'usa')^^"
    ]
  }
]

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この例では、特定の基準でフィルタリングされた既存の「nlpcraft：city」に基づいて、新しい名前付きエンティティ「Americancity」-「custom：city：usa」について説明します。 これで、作成された新しい要素に基づいてインテントを作成できます。テキストで検出された米国以外の都市では、インテントが不要にトリガーされることはありません。 もう一つの例：

"macros": [
  {
    "name": "<AIRPORT>",
    "macro": "{airport|aerodrome|airdrome|air station}"
  }
],
"elements": [
  {
    "id": "custom:airport:usa",
    "description": "Wrapper for USA airports",
    "synonyms": [
      "<AIRPORT> {of|for|*} ^^id == 'nlpcraft:city' && 
       lowercase(~city:country) == 'usa')^^"
    ]
  }
]

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この例では、名前付きエンティティ「米国の都市空港」-「カスタム：空港：米国」を定義しました。この要素を定義するとき、州の所属に従って都市をフィルタリングするだけでなく、都市の名前の前に「空港」の概念を定義する同義語を付けるという追加のルールを設定しました。 （マクロを介した要素の同義語の作成について詳しくは、こちらをご覧ください）。



複合要素は、任意の程度のネストで定義できます。つまり、必要に応じて、新しく作成された「カスタム：空港：米国」に基づいて新しい要素を設計できます。また、親エンティティのすべての正規化された値、この場合は基本要素「nlpcraft：city」にも注意してください」は「custom：airport：usa」要素でも使用でき、トリガーされたインテントの関数本体で使用できます。



もちろん、「ビルディングブロック」は、OpenNlp、Stanford、Google、Spacy、NlpCraftでサポートされているすべての標準コンポーネントだけでなく、カスタムNERコンポーネントに対しても定義でき、それらの機能を拡張して、既存のソフトウェア開発を再利用できます。



実際には、新しいタスクごとに新しいコンポーネントを作成するのではなく、単にそれらを構成するか、それらの機能を独自の要素に「混合」することに注意してください。



したがって、「複合エンティティ」を使用すると、開発者は次のことができます。

• インテントを再利用可能なビルディングブロックに部分的に転送することにより、インテントを構築するロジックを大幅に簡素化します。
• モデルのトレーニングやコーディングを行わずに構成を変更して、新しい動作のNERコンポーネントを入手します。
• 既存のテストまたはメトリックに依存して、期待される品質で既製のソリューションを再利用します。

結論

既存のNERコンポーネントの長所と短所の概要が読者の役に立つことを願っています。また、Apache NlpCraftが機能を大幅に拡張し、既存のソリューションを新しいタスクに適応させる方法を理解することで、プロジェクトの開発プロセスがスピードアップすることを願っています。