私の以前の出版物を読んだ人は、私が書くことはめったにありませんが、通常は連続して書くことを知っています。 特定のトピックに関する私の考えを収集し、1つの短い記事のProcrusteanベッドに圧迫することなく棚に置きたいと思います。



今回は、ワードプロセッシング（自然言語処理）について話す新しい理由があります。 1つのオフィス用のスペルチェックを開発しています。 出力は、MS Wordに組み込まれている機能に似た機能になるはずです。ただ、この分野の主要な専門家とは言えませんが、勉強しようとしています。 ノートでは、私たちのプロジェクトがどこに向かっているのか、テキスト処理のこの段階またはその段階がどのように配置されているのかについて話そうとします。 たぶん、コメントで私は自分自身のために新しい/面白いものを聞くでしょう。 プロジェクトがこれの恩恵を受ける場合-罰金。 少なくとも、頭の中でデータを取得しますが、これも良いことです。

巨人の肩の上に？

既存のソリューションを見ることなく、システムを発明することは難しいことは明らかです。 しかし、私たちの周りの巨人は、どういうわけか特に観察されていません。 私たち全員が知っているMS Wordがあり、また...そして他に誰がいますか？ さて、コメンテーターに修正してもらいますが、Open Office用のLanguageToolモジュール（後で説明します）を除いて、何も思いもしません。 ピースグッズ。 （はい、Mac用のGrammarian Pro Xパッケージも思い出しましたが、天候にも影響しません）。 したがって、「父」に焦点を合わせるのは困難です。 少なくともスペルチェックは多く実装されていますが、文法は大したことです。

コンパイルと 静的解析

プログラミング言語では、テキストのエラーを検出するための2つのモデルが明確に表示されます。 第一に、コンパイル段階でエラーを検出できます。つまり、設計の言語文法に従って、言語の単語を意味のある有効なものに結合しようとするときです。 次に、静的コード分析を実行できます。つまり、潜在的に危険なアクションに関連付けられたプログラムテキスト内の特定のパターンを探します。



理論的には、「コンパイルモデル」はもちろん非常に魅力的です。テキストを「コンパイル」してみてください。 それにエラーがある場合、分析されたフラグメントは単に「互いにくっつかない」ため、システムはすぐに理由を確認します-コンピュータ言語コンパイラにとってそれがどれほど明確か。 残念ながら、現時点では、本格的な「自然言語コンパイラ」は存在しません。 これはまさに私が余暇に掘る方向ですが、私は生のアイデアを商用製品に埋め込むことを試みる準備ができていません。 優れた最先端のモジュールを作成すると同時に、現代のどのように構築されているかを理解することをお勧めします。



MS Wordでスペル設定を開くと、文法チェックが静的アナライザーの原理に正確に作用することがわかります。 特定のチェックセットがあり、システムはそれらを介してテキストを順番に実行します。







実際、「MS Wordのスペルチェック」について話すのは完全に正しいわけではありません。実際には、さまざまな言語のモジュールはさまざまなチームやさまざまなアルゴリズムで作成されています。 ただし、チェックのふるいを通してテキストを「実行」するという一般的な考え方は、各モジュールで有効なようです。

キャノピーの下

ここで、このような重要な質問について説明します。先ほど説明したチェックはどこから来るのでしょうか。 上記のスクリーンショットに示されているMS Wordに正確なルールセットが組み込まれているのはなぜですか？ ところで、各タイプの分析に関するより詳細な情報はヘルプで利用できます：







Wordによる文法チェックの品質は、怠zyな人だけに影響されませんでした。 ネガティブな経験の多くが共有されていることを確認するために、少なくともこのよく知られている材料の選択を勉強するだけで十分です:)すべての文法モジュールの欠点は、3つの主な理由が原因であると思います まず、「静的チェック」の原則は、スペルミスの不完全な網羅を意味します。 これらのエラーの名前はレギオンであり、文章で考えられるすべての考えられる、考えられない不条理をシステムに追い込むために、テスターの顕著な才能を持たなければなりません。 第二に、私たちの技術は私たちが望むほど良くありません。 テスターは多くのエラーを認識しますが、それらをプログラムすることはできません。 すべてのエラーが同様に簡単にキャッチされるわけではないことは明らかです。 第三に、最も可能性が高いのは、エラーがよく知られているジョーク、「ランプの下」で、実際に見つかった場所ではなく、明るい場所で検索されることです。



今日、通常の通信で発生したエラーの頻度リストを見つけるのはそれほど簡単ではありません。 数少ない研究の 1つに、学生のエッセイ（英語）で見られる20の最も一般的な間違いがリストされています。 私たちはネイティブスピーカーについて話しているので、リストは私たちには自明ではないように思えるかもしれません。 外国人の場合、まったく異なるサンプルを取得できると思います（さらに、作家の母国語に大きく依存しています）。



別の記事の著者は怠け者ではなく、さまざまな文法チェックモジュールを通じて、示されたエラーを含むテキストを運転しました。 結果は完全に失望した。 要するに、すべてが悪いです（そして、何らかの理由でWord 97が後続のすべてのバージョンよりもはるかに優れていることが判明しましたが、それは私たちにとって重要ではありません）。 最も人気のあるバグのテストは、プログラミングするには複雑すぎるか、見落としによって開発者が単に見逃しています。

フィールドの現在の状態のミラーとしてのモジュール

もちろん、顧客は世界で最高の文法モジュールを持ちたいと考えています。 少なくともMS Wordのそれより悪くない。 そして、私たちは彼にそれを提供しようとしますが、実際には、私は現在の品質基準から遠く離れることを望みません。 私たちと対戦しすぎています。 実際、実際の頻度（キャリアと外国人の両方）を示す可能性のあるエラーの適切な分類はありません。そのようなリストがなければ、チェックは雲の後ろのどこかに飛んでゲームに入ることを期待して暗い空での撮影に変わります。 そして、リストからのミス（私はそれらを注意深く研究しました）は、ほとんどの部分を見つけるのが本当に難しいです。 さて、私たちは働きます。 はい、私たちは英語から始めて、計画に従ってドイツ語を始め、そこに人生が現れるとはまだ言及していません。



次のパートでは、システムの仕組みの技術的な詳細に進みます（現時点では、ほとんどの場合、それは私の頭にのみ存在しますが、プロセスは高速に動いています）。