小さなセマンティックアナライザーで大きな問題を解決する

プロジェクトの試運転。 委員会は、システムがリアルタイムで到着するメッセージから情報を認識する方法を観察します。 最初のメッセージが到着します。 」

委員会。 「Quiet」とはどういう意味ですか？ 彼らはそこに酔っているのか何か？

システム。 "Quiet" =通常の制限内の風力。

委員会。 だから、天気についてです。 システムは試運転中です！

記事のすべてのイベントは架空のものです。 現実との偶然の一致はランダムです。

私はたまたまプロジェクトに取り組み、セマンティック分析を使用して、大企業を管理する際の主な問題の1つを解決することができました。

「Z」という会社は、広大な祖国全体に広範な支店ネットワークを持ち、人口と企業にfireを供給しています。 会社の施設では、さまざまなインシデントが定期的に発生します。これらのインシデントは、より高い管理体制に知られる必要があります。

歴史的に、オブジェクトからの情報は、組織構造の上のSMSおよび電子メールメッセージの形式で送信されていました。

そしてもちろん、情報は良心的に失われ、奇跡的に修正され、レベルからレベルへと移動するときに定期的に遅れていました。 その結果、下で起こっていることの歪んだ画像が上部で形になりました。

管理装置への関連情報の配信を手配するために、短時間でタスクが与えられました。 会社は巨大であり、期間は短い。 オブジェクトからのすべてのメールに、メインコントロールセンターの携帯電話番号とメールを含めることにしました。 同時に、メッセージを読むのではなく、それらにスマートプログラムを設定します。これにより、すべてが処理されます。

「彼女は自分でそれを理解する」とは、

1. 異なる送信者がいる場合でも、同じインシデントに関する状況のメッセージを結合します。
2. GISとダッシュボードを使用して状況のグラフィカルな表現を作成します。
3. さまざまなパラメーターの通知設定ツールを作成します。
   
   3.1。 インシデントの種類;
   
   3.2。 インシデントの優先度;
   
   3.3。 事件の場所と時間など
4. 制御および抑制ツールの作成：
   
   4.1。 インシデントの発生以降のメッセージ送信のタイミングの違反。
   
   4.2。 インシデント情報の歪みと沈黙。
5. 統計情報を収集し、ブランチからのレポートと比較するためのツールを作成します。

車輪を再発明する

ほとんどの読者は、「既成のソリューションがあるのに、なぜ素晴らしいものを発明するのか」と尋ねるでしょう。 良い質問ですが、冗談のように、 ニュアンスがあります。 より正確には、多くのニュアンスがありました。文章はほとんど短く、個々のメッセージのスペルと文法は教区の卒業生の作品に似ていました。 テキストは多数の略語と略語で構造が不十分であり、その中のほとんどの単語は業界用語であり、特定の地域の詳細が掛けられています。 つまり、カリーニングラードとクラスノヤルスクのまったく同じ実体は、異なる呼び方をすることができます。 その結果、その時点で利用可能なソフトウェアを整理し、地域の専門家と相談した結果、独自のソリューションを提出することを余儀なくされました。

テキストから事実を抽出する段階の柔和な理論はここで見つけることができます 。

プロジェクトのアーキテクチャ

このアーキテクチャは、状況のタイプ、イベントのタイプ、属性イベントのタイプの3つのレベルの分類子に基づいています。 そして原則：

• 「何」-何が起こったのか
• 「どこ」-どのオブジェクト
• 「いつ」-何時

アルゴリズムが機能するためには、特定のトピックで塗りつぶされた分類子が必要です。

1. イベントのリスト-これは、顧客が関心を持つすべての統計情報であり、施設でのインシデントに関するアラートです。 例：地震、事故、構造物の崩壊。
2. イベント属性は、断片化されたイベントです。 例：地震の日時、地震の事実、イベントの目的、インシデントの影響を受けた消費者の数など。
3. 状況のタイプ-同様のタイプのイベントの一般化。 たとえば、「自然災害」のタイプは、ハリケーン、洪水、農村を組み合わせたものです。

アルゴリズムは段階に分けられます：

1. テキストの準備;
2. テキストを文章に分割する;
3. 割り当て：トークン、エンティティ、句読点。
4. ステージ3に基づいてイベント属性を強調表示します。
5. ステージ4に基づくイベントの識別。
6. イベントを既存の状況に関連付けるか、新しい状況を登録します。
7. 各段階に関する状況のタイプの定義。

受信したメッセージの例を考えてみましょう。

「10.02.15」、仮に夕方の10時に、SKの南支店の敷地で、15から17のKAZステーションがあります。社会サービスはありません。 価値 n.p.の影響 イヴァノヴォとペトロヴォ。 500人

ステージ1：テキストの準備

「ゴミ」からテキストを削除し、目的に合わせて類似の文字を一見します。 少なくとも4種類の「ダッシュ」（----）があり、引用符はそれ以下です（「」「」「」）。

出力は次のとおりです。

02/10/15夕方10時頃、SKの南支店、AZ駅の15から17の場所で、社交的ではありません。 価値 n.p.の影響 イヴァノヴォとペトロヴォ。 500人

ステージ2：文への分割

テキストセグメントが短いほど、作業しやすくなります。 文字「！？」をカウントします。 ...”文章の最後、およびビジネス、テキストの削減のためではない場合。 ソリューションの鍵は、正規表現にピリオドが含まれる略語とトークンの辞書です。

メッセージは文章の配列のようになります。

02/10/15夕方10時頃、SKの南支店、AZ駅の15から17の場所。

ソーシャルなし。 価値

n.p.の影響 イヴァノヴォとペトロヴォ。

500人

ステージ3：割り当て：トークン、エンティティ、句読点

各文から目立つのは、トークン、厳密な接続、データベースベースのエンティティ、句読点です。

例：

• トークン-「 無効 」。
• 厳格な関係-「 {number}人 」;
• 本質は「 Surgut branch 」です。

文の段階の最後では、それらはトークンと句読点の配列であり、未知の単語はすべて捨てられます：

02/10/15 トークン「数値日付」 トークン「 pretext 」 仮に 夜のトークン「時間への参照 」の 10個のトークン「言語番号」、 SK エンティティ「組織構造」の南部支店のトークン「pretext」セクションへのトークン「コンマ 」、ステーショントークン「ステーション」の トークン「コンマ」 AZ トークン「緊急シャットダウン」 17 厳格な関係「リスト」 。

トークン「ネガティブパーティクル」社会的価値トークン「社会的に重要なオブジェクト」なし

影響を受けるトークン「影響」 n.p. トークン「ローカリティ」イバノヴォエッセンス「ローカリティ」およびトークン「ユニオン」ペトロヴォエッセンス「ローカリティ」 。

500人の厳格な関係「人数」 。

ステップ4：イベント属性の定義

コンフィギュレーターの各イベント属性に対して、アルゴリズムと入力データが指定されます：トークンと厳密な通信。 アルゴリズムの動作を調整する設定と同様に。 たとえば、「トークンの重要なシーケンス」フラグは、アルゴリズムがテキスト内のトークンを見つけるだけでなく、コンフィギュレーターで指定された順序に対応する順序をチェックする必要があることを意味します。

圧倒的な数の属性で使用される主なアルゴリズムは、主語と述語の間の関係の決定です。 このアルゴリズムは構文規則に基づいており、隣接する文を「調べ」ます。

例：

2015年2月10日午後10時の日付と時刻に関連する日付 、英国の組織構造の南支部で、AZ 述語1の 主題1の述語1の主題1を 15から17に説明します。

ソーシャルなし。 価値 主題に対する否定（社会的に重要な消費者なし）

影響を受ける述語2 n.p. 述語2の主題2（和解） 述語2のイバノヴォ主題、 「 n.p。 」の改良、述語2のペトロヴォ主題、 「 n.p。 」の改良

述語2の 500人の主題3は、述語が近隣の文から取得されます。

ステージ5：イベント定義

この段階で、イベントの属性がイベントを形成します。 コンフィギュレーターの各イベントには、その属性と設定がリストされます。最も重要なのは、メイン属性のマークです。 メイン属性がないと、イベントは発生しません。 たとえば、イベント「盗難の試み」には、「盗難の事実」（主な属性）、「発生時刻」、「組織構造」という属性があります。

同じ属性が異なるイベントに参加できます。たとえば、文の先頭に示された組織構造は、メッセージ内の後続のすべてのイベントに使用できます。

イベントは、近隣のオファーからのデータを考慮して生成されます。 たとえば、前の文で事故が解消され、後続の顧客が影響を受けた顧客をリストしていると言及されている場合、転送は損傷の事実ではなく、損傷からの回復の事実です。

例：

02/10/15 4:35 p.m. SKの支店。 事故は完全に排除されます。 脂肪のない消費者：500人。

ステージ6：状況におけるイベントの結合

メッセージからの主な情報が受信されました。現在、既存の状況に添付するか、新しい状況を登録する必要があります。

「何？ どこ？ いつ？」 つまり、メッセージは、3つの質問すべてに等しく答えた場合の状況を指します。

合計で、各メッセージに対して、互換性のあるイベント（ "What"）を持つ類似オブジェクト（ "Where"）の存在の調整を行い、時間デルタ制限（ "When"）を課します。

たとえば、3つの下位レベルのオブジェクトで地震が発生し、それぞれが次のレベルにメッセージを送信し、最上部にコピーを送信しました。 次に、「次のレベル」は情報を要約し、最上部に渡しました。 その結果、上部には、システムが1つの状況に結合する4つのメッセージがあります。 「どこ」のオブジェクトが近くにあるという事実は、会社のオブジェクトのディレクトリから学習します。

ステップ7：状況のタイプの判別

状況におけるイベントの構成に基づいて、そのタイプが決定されます。 運用管理における意思決定には、状況のタイプが非常に重要です。

たとえば、ある状況では、次の一連のイベントが発生します。テレメトリの損失、建物の一部の崩壊、消費者への供給の停止、雪崩。 状況のタイプは、「建物または構造の崩壊」として定義されます。

データ使用量

統計とレポートに加えて、抽出されたデータは次のツールで使用されました。

1. 重要なイベントに関する運用担当者へのアラートシステム。
   
   通知システムの実装の一環として、イベントデータとその属性を処理する条件コンフィギュレーターが作成されました。
   
   アラートの例：
   
   1.1。 「凍結」：「事故は50,000人以上に影響を与えました」、「現在の季節は冬」、「場所-シベリア」。
   
   1.2「干ばつ」：「事故は社会的に重要な対象物、給水塔に影響を与えた」、「継続時間-2時間以上」。
2. 情報の移動を制御します。
   
   システムは状況に関するすべてのメッセージを持っているため、データ転送規制の実装を監視できます。メッセージチェーンが中断される場所、タイミングに違反する人、事実を歪める人。 このツールは、違反者にSMSアラートを自律的に送信します。
3. レポートおよびニュースレターのメッセージの自動生成。
   
   テキストテンプレートのおかげで、重要な状況は自動的に短いテキストにまとめられ、ニュースレターやレポートに到達します。

まとめ

選択されたアプローチは、比較的低い時間と材料コストで会社のトップレベルにすべての支店からの運用データを提供することにより、その効果を示しています。

アプローチの利点：

1. 動作条件での認識精度-95％;
2. 主な人件費は分類法とトークンの配列であるため、アルゴリズムを新しいサブジェクト領域にすばやく調整します。
3. アプローチの実装の相対的な単純さと速度。

アプローチの欠点：

1. サブジェクト領域ごとに、新しいトークンの正規表現を記述する必要があります。
2. 複雑な文の認識精度の低下。
3. タイプミスの問題：正規表現に入れる必要があり、辞書を操作するときは「 レーベンシュタイン距離 」を使用する必要があります（その効果は単語の文字数に依存します）。
4. 文に分割するには、略語辞書を更新する必要があります。

当初は、システムのユーザーは会社のトップレベルの従業員であると想定されていましたが、状況は試運転中のいくつかのケースの後に変化し、これが特にプロジェクトとアプローチの成功の主な指標になりました。

たとえば、セクションの関連する事故の状況を説明するようにとの要請を受けて、コンサルタントから電話を受け取り始めました。彼らはすでにシステムの存在を知っており、この情報はそこからしか得られないからです。

または、当社のシステムのダッシュボードを見ている本社がビデオ会議の支部との会議で、支部長に次のように尋ねました。 火事に関する情報は、古いチャンネルを通じて、会議の30分後に支部の長に届きました。