回答編集履歴
7
千葉行きバスの例を微修正
answer
CHANGED
|
@@ -34,8 +34,9 @@
|
|
|
34
34
|
さらに、「勤務先は東京になります」になると難しい。
|
|
35
35
|
まあこれは一文から勤務先の表現と地名を抜き出せばいいでしょう。
|
|
36
36
|
|
|
37
|
-
しかし、「東京からバスを出すので、埼玉**ではなく**、
|
|
37
|
+
しかし、「東京から送迎バスを出すので、別働隊の埼玉**ではなく**、
|
|
38
|
+
千葉行きに乗って向かってください」の勤務先をどうするかは難しい。
|
|
38
|
-
|
|
39
|
+
**意味や文脈**が関係してくるからです。
|
|
39
40
|
|
|
40
41
|
この一文を抜き出すのに、前後の文も判断する必要があるかもしれません。
|
|
41
42
|
こうして、正規表現の単純な抽出では、すぐに限界を迎えます。
|
6
「埼玉ではなく」という、正規表現では難しい、否定表現の例を追加
answer
CHANGED
|
@@ -34,11 +34,11 @@
|
|
|
34
34
|
さらに、「勤務先は東京になります」になると難しい。
|
|
35
35
|
まあこれは一文から勤務先の表現と地名を抜き出せばいいでしょう。
|
|
36
36
|
|
|
37
|
-
しかし、「東京からバスを出すので、千葉に向かってください」の
|
|
37
|
+
しかし、「東京からバスを出すので、埼玉**ではなく**、千葉に向かってください」の
|
|
38
38
|
勤務先をどうするかは難しい。**意味や文脈**が関係してくるからです。
|
|
39
39
|
|
|
40
40
|
この一文を抜き出すのに、前後の文も判断する必要があるかもしれません。
|
|
41
|
-
正規表現の単純な抽出では、すぐに限界を迎えます。
|
|
41
|
+
こうして、正規表現の単純な抽出では、すぐに限界を迎えます。
|
|
42
42
|
|
|
43
43
|
そもそも、勤務先を「東京、千葉」と並列にして良いのかとか、
|
|
44
44
|
集合場所と勤務先は別なのかとか、**要件**が決まっている必要があります。
|
5
クラスとパースの関係について加筆
answer
CHANGED
|
@@ -90,12 +90,18 @@
|
|
|
90
90
|
まとめると、全体の文書を部分文字列（オブジェクト）の集合に分解して、
|
|
91
91
|
後は正規化（30か三十か単位をそろえるなど）し、表などに構造化して出力します。
|
|
92
92
|
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
93
96
|
なお今回、長く難しい話になるので、**パース（構文解析）**の話題を省略しましたが、
|
|
94
97
|
単語単位だけでなく、文法にそって文単位で解析すると、
|
|
95
98
|
難度は一気に上がりますが、より本格的な自然言語処理が可能になります。
|
|
96
|
-
そして、オブジェクトにしたいのは、このパースを視野に入れているからです。
|
|
97
99
|
|
|
100
|
+
そして、このパースを視野に入れているから、オブジェクトにしたいのです。
|
|
101
|
+
パースでは構文木を作りますが、正規表現では階層構造の表現が難しい。
|
|
102
|
+
しかし、**クラスは階層構造を表現**できます。そのためのクラスです。
|
|
98
103
|
|
|
104
|
+
|
|
99
105
|
---
|
|
100
106
|
|
|
101
107
|
> ライブラリやAPIがあれば、教えていただければと思います。
|
4
正規表現の限界と、オブジェクトとパースの関係について言及
answer
CHANGED
|
@@ -9,8 +9,8 @@
|
|
|
9
9
|
情報抽出は部分的には可能なので、**ドメイン**を絞るやり方が良いです。
|
|
10
10
|
逆に、汎用的にやろうとするほど、高確率で失敗します。限定してください。
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
自然言語処理は、人工知能と文字列処理のあいだにありますが、
|
|
13
|
-
ドメインを絞ることで、文字列処理に近づけると、実現可能性が高まります。
|
|
13
|
+
**ドメインを絞ることで、文字列処理に近づける**と、実現可能性が高まります。
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
---
|
|
@@ -36,16 +36,18 @@
|
|
|
36
36
|
|
|
37
37
|
しかし、「東京からバスを出すので、千葉に向かってください」の
|
|
38
38
|
勤務先をどうするかは難しい。**意味や文脈**が関係してくるからです。
|
|
39
|
-
この一文を抜き出すのに、前後の文も判断する必要があるでしょう。
|
|
40
39
|
|
|
40
|
+
この一文を抜き出すのに、前後の文も判断する必要があるかもしれません。
|
|
41
|
+
正規表現の単純な抽出では、すぐに限界を迎えます。
|
|
42
|
+
|
|
41
43
|
そもそも、勤務先を「東京、千葉」と並列にして良いのかとか、
|
|
42
|
-
集合場所と勤務先は別なのかとか、要件が決まっている必要があります。
|
|
44
|
+
集合場所と勤務先は別なのかとか、**要件**が決まっている必要があります。
|
|
43
45
|
|
|
44
|
-
そういうわけで、抽出する先の文章の書式が統一されているほど、
|
|
46
|
+
そういうわけで、抽出する先の文章の書式が**統一**されているほど、
|
|
45
47
|
文字列処理に近づき、実装しやすくなります。
|
|
46
48
|
たとえば、表から表なら位置を変えるだけなので簡単でしょう。
|
|
47
49
|
|
|
48
|
-
まとめると、決め打ちできる書式をいかに増やすかが重要です。
|
|
50
|
+
まとめると、**決め打ちできる書式をいかに増やすか**が重要です。
|
|
49
51
|
情報収集するサイトを絞るとか、データの出所が社内なら、
|
|
50
52
|
フォーマットを統一するようにしておくとか。
|
|
51
53
|
|
|
@@ -72,7 +74,7 @@
|
|
|
72
74
|
規模が大きくなるにつれ、非常に複雑になりやすい。
|
|
73
75
|
|
|
74
76
|
だから、せっかくJavaを使うなら（Pythonなら関数型のやり方でもいいかも）、
|
|
75
|
-
**オブジェクト**で表現したいです。DDDなどでいうドメインモデルです。
|
|
77
|
+
**オブジェクト**で表現したいです。DDDなどでいう**ドメイン**モデルです。
|
|
76
78
|
|
|
77
79
|
私なら、まず「人数」をクラスにして、
|
|
78
80
|
さらに、数字部分と単位部分も別のクラスに分けて、
|
|
@@ -91,6 +93,7 @@
|
|
|
91
93
|
なお今回、長く難しい話になるので、**パース（構文解析）**の話題を省略しましたが、
|
|
92
94
|
単語単位だけでなく、文法にそって文単位で解析すると、
|
|
93
95
|
難度は一気に上がりますが、より本格的な自然言語処理が可能になります。
|
|
96
|
+
そして、オブジェクトにしたいのは、このパースを視野に入れているからです。
|
|
94
97
|
|
|
95
98
|
|
|
96
99
|
---
|
3
最後に構文解析について言及
answer
CHANGED
|
@@ -29,13 +29,13 @@
|
|
|
29
29
|
|
|
30
30
|
たとえば、【】でくくってくれないかもしれない。
|
|
31
31
|
「要員」の代わりに「人数」と表現するかもしれない。
|
|
32
|
-
それくらいならまだ、正規表現など文字列処理で対応できます。
|
|
32
|
+
それくらいならまだ、**正規表現**など文字列処理で対応できます。
|
|
33
33
|
|
|
34
34
|
さらに、「勤務先は東京になります」になると難しい。
|
|
35
35
|
まあこれは一文から勤務先の表現と地名を抜き出せばいいでしょう。
|
|
36
36
|
|
|
37
37
|
しかし、「東京からバスを出すので、千葉に向かってください」の
|
|
38
|
-
勤務先をどうするかは難しい。意味や文脈が関係してくるからです。
|
|
38
|
+
勤務先をどうするかは難しい。**意味や文脈**が関係してくるからです。
|
|
39
39
|
この一文を抜き出すのに、前後の文も判断する必要があるでしょう。
|
|
40
40
|
|
|
41
41
|
そもそも、勤務先を「東京、千葉」と並列にして良いのかとか、
|
|
@@ -61,12 +61,13 @@
|
|
|
61
61
|
「対象の文書（全体文字列） → 部分文字列 → 表などに構造化」という流れ。
|
|
62
62
|
|
|
63
63
|
この部分文字列とは、たとえば「東京」とか「30名」とかです。
|
|
64
|
+
しかしこれは、「神奈川」や「100人」も抜き取りたいので、
|
|
65
|
+
「地名」とか「人数」とか**抽象化**された概念になります。
|
|
66
|
+
|
|
64
|
-
「東京」とか都道府県限定なのか、それとも、
|
|
67
|
+
また、「東京」とか都道府県限定なのか、それとも、
|
|
65
68
|
「秋葉原」「新宿」とかでも良いのかなど、要件と関係してきます。
|
|
69
|
+
それに、「30名」は「30人」も、「三十名」「三十人」も抜き出したいでしょう。
|
|
66
70
|
|
|
67
|
-
また、「30名」は「30人」も、
|
|
68
|
-
「三十名」「三十人」も抜き出したいでしょう。
|
|
69
|
-
|
|
70
71
|
こういうのを正規表現だけで表現すると、
|
|
71
72
|
規模が大きくなるにつれ、非常に複雑になりやすい。
|
|
72
73
|
|
|
@@ -81,10 +82,17 @@
|
|
|
81
82
|
クラスが増えても、それだけ実装コストを掛ける意味があると思います。
|
|
82
83
|
|
|
83
84
|
ネストしたIF文と正規表現の嵐だと、結局メンテ不能になっていきます。
|
|
84
|
-
一方、部分文字列をオブジェクトの集合で表現すると、それぞれ独立しているので、
|
|
85
|
+
一方、**部分文字列をオブジェクトの集合で表現する**と、それぞれ独立しているので、
|
|
85
86
|
変更の対象が分かりやすくなり、変更容易になるのでメンテしやすいです。
|
|
86
87
|
|
|
88
|
+
まとめると、全体の文書を部分文字列（オブジェクト）の集合に分解して、
|
|
89
|
+
後は正規化（30か三十か単位をそろえるなど）し、表などに構造化して出力します。
|
|
87
90
|
|
|
91
|
+
なお今回、長く難しい話になるので、**パース（構文解析）**の話題を省略しましたが、
|
|
92
|
+
単語単位だけでなく、文法にそって文単位で解析すると、
|
|
93
|
+
難度は一気に上がりますが、より本格的な自然言語処理が可能になります。
|
|
94
|
+
|
|
95
|
+
|
|
88
96
|
---
|
|
89
97
|
|
|
90
98
|
> ライブラリやAPIがあれば、教えていただければと思います。
|
2
ないわけではないことを考慮して、 商品化 → 安価な商品の普及 という大意に変更
answer
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
|
|
4
4
|
先に断っておくと、**固有表現抽出**を含めた**自然言語処理**は、
|
|
5
5
|
AIなどと同じ最先端の分野なので、希望通りにできる保証はありません。
|
|
6
|
-
もし
|
|
6
|
+
もし簡単に汎用化できたら、安価なソフトが商品化されて、とっくに普及してるはずです。
|
|
7
7
|
|
|
8
8
|
では、どういうアプローチをしたら良いか。概要から言いますと、
|
|
9
9
|
情報抽出は部分的には可能なので、**ドメイン**を絞るやり方が良いです。
|
1
Java,Pythonの言語への言及部分を変更
answer
CHANGED
|
@@ -70,7 +70,7 @@
|
|
|
70
70
|
こういうのを正規表現だけで表現すると、
|
|
71
71
|
規模が大きくなるにつれ、非常に複雑になりやすい。
|
|
72
72
|
|
|
73
|
-
だから、せっかくJava
|
|
73
|
+
だから、せっかくJavaを使うなら（Pythonなら関数型のやり方でもいいかも）、
|
|
74
74
|
**オブジェクト**で表現したいです。DDDなどでいうドメインモデルです。
|
|
75
75
|
|
|
76
76
|
私なら、まず「人数」をクラスにして、
|