自然言語処理(NLP)を実装したくてLaravel×Python連携をしたがNLPが現実的ではないらしい
- 2020.05.25
- 1. プランニング
- ECシステム, Python-Laravel連携, 仕様, 備忘録, 商品ページ, 情報収集, 検索対策, 楽天市場, 自作システム, 自動化, 自然言語処理, 集客力UP
自然言語処理(NLP)を実装したくてLaravel×Python連携をしたがNLPが現実的ではないらしい
単語リスト作成はすでに実装済みなので、この単語を利用した自然言語処理を考えようとずっと思っていました。
まず取り掛かりとして簡単なのはマルコフ連鎖による言語処理です。このブログでも過去に取り上げています。
▼商品説明をマルコフ連鎖で構成してみる
▼マルコフ連鎖用テーブルの構造
実験の結果ですが、単語リストからのマルコフ連鎖による言語処理にはECでの大きな課題が3つありました。
- 必要なワードが網羅されるまで莫大な文章量が必要になる。⇒ 時間とByteの消費が激しい
- 選択商品と相反するWord(不必要なワード)がチョコチョコ出てくる。 ⇒ クレームの温床になる可能性あり
- 欲しいキーワードを網羅した文章は生成できるが対人間向きの文章になり難い。 ⇒ 読むとどことなくオカシイ。
それでもまぁ使い道はあるかなと思ってはいるのですが「どうせなら流行りの『機械学習×自然言語処理』に手を出してみるか」とPyshon とLaravelの連携に手を出しました。
実際の処理を追えていないため、諸々の希望に足る実装となっているかは不明ですが連携自体は下記サイトを参照しソコソコ出来た様子。
でもね、肝心の自然言語処理が暗礁に乗り上げてます。
そもそも日本語の自然言語処理は可能なのか
ここが今の大問題。
「現状、だれも満足な自然言語処理を開発できていない」
これさ、俺ごときが作れるわけないじゃん…。
という事で『EC事業者として現実的なライン』ってどこかを整理したいと思います。
そもそも自然言語処理ってどう流れるのか
現実的なラインを知るためには、全体的な流れの理解が必要です。
自然言語処理の大雑把な流れは次の通り。
- 形態素分析(文章を単語に分解する)
- 構文分析 [係り受け解析](文章を品詞に置き換え単語間の関係性を解析する)
- 意味解析(文章として意味が通じるかを解析する)
- 文脈解析(複数の文章同士で矛盾していないかなど、文を超えた繋がりを分析する)
有名なプログラム名(分析システム名?)で紐付けすると次のような感じ。
- 形態素分析 ⇒ MeCab
- 構文分析 ⇒ Cabocha
- 意味解析 ⇒ 開発段階で素人が手を出せるものはなし
- 文脈解析 ⇒ 開発段階で素人が手を出せるものはなし
更に人間が書いた文章っぽくするためには更に2つの処理が加わります。
- 照応解析(『こそあど言葉』や『ゼロ代名詞』が何を指しているかを解析する)
- 談話解析(複数の文章のうち、どこからどこまでが『関連した一連の文章』かを解析する)
談話解析は例えば『「○○○○」とAさんが言っていた。』という文章を一つのまとまりと判断させる解析の事。
まぁ普段の会話で意識したことはないけど、自動で分析処理してるよね人間は。
現状で素人に無理ゲーなのは『意味解析』『文脈解析』『照応解析』『談話解析』
つまるところ「学者レベルでないとちゃんとした自然言語処理はできない」と言う事です。
いや「学者レベルでも未だにちゃんとした(意味ある)文章は作れない」が正しいのか。
さてここで『成し遂げたい成果は何なのか』をよく考えてみましょう。
最先端の知識でも作れないものが、GoogleやましてやECモールの検索システムに実装されてると思いますか?
そんなわけはないですよね。
そして、私たちEC事業者が行いたいことは『SEO』の対策です。
自然な言語でなくても『検索』に優位な仕組みであれば良い
結論を言えば現時点で構築できる言語処理で「顧客対応はできないけど検索対応はできる」と言う事です。
「検索システム対策が先か訪問者対策が先か」は「タマゴと鶏」ではない
鶏がいないと卵は産まれません。卵が無いと鶏は産まれません。
これをECに置き換えて話す人がいますが、それは大きな間違いです。
訪問者対策は【購入】していただくために行います。
購入していただくためには【訪問】していただく必要があります。
訪問していただくためには自社サイトや商品への【導線の確保】が必要です。
そして導線確保の手段として【検索優位性】があります。
お客様の目に触れない商品が売れる事はまずありません。
つまりは、検索対策が初手でありコンバージョン対策は次手という事になります。
「でもコンバージョンが悪ければ売れないのだから、先にコンバージョンを高めておくべきでは?」
まぁ考え方はイロイロですよね。私にそれを否定する材料はありません。
今回の記事は『自然言語処理』についてなので、ここら辺の込み入った話はまたの機会にでも。
という事で、今回は『とにかく検索対策は必要』という視点で進めたいと思います。
ECのキーワード出力はどこら辺が落としどころか
現状では「自然な言語でなくても『検索』に優位な仕組みであれば良い」わけです。
「じゃあ、単語の羅列でもOK?」これについてはどこを対象にするかで別れるようです。
- 単語の羅列でOK = 楽天市場、Amazon、Wowma!、(多分Yahoo!ショッピングも)
- 単語の羅列はNG = Google ※ページの評価に構文解析も採用している模様
いずれは楽天市場なども単語の羅列NGを追随するのだろうと思っていましたが、アマゾンが羅列でOKなんですよね。
よくよく考えれば、商品を調べる時に文章で検索する事ってないですから、今の段階で「AIに文章の意味を理解させて検索者にベストな商品を提示する仕組み」を作るには天下のAmazonであっても【コスト】と【技術】が足りないという事なのでしょう。
となると、ECの検索対策にとって『文章化』って意味がないのかもしれません。
「じゃあ、どこら辺が落としどころなの?」
これには先に挙げた『タマゴと鶏』も関係してくるので私見でしかありませんが箇条書きにするとこんな感じ。
- 単語リストボックスを作り、そこに単語リストを格納する
- Google対策を考えないのであれば、単語リストは文字羅列の形でOK
- Google対策も考えるのであれば、単語リストは文章構造を考えて文章としての姿を作って出力する
- 閲覧者対策として、単語リストはその他の商品説明と異なることが解るように処置をする(※敢えて「検索対策用ワードリスト」として載せるなど)
『販売に至った商品/集客した商品』については流入ワードをよく調べたうえでキーワードを使って作文する- 作文で利用しなかったワードのうち、不要と思われるワードは破棄、必要かもしれないと思うWordについては引き続き専用箇所に記載しておく
この中で現在未作成なパーツは『商品毎の集客ワード蓄積』。これ構造は思いつくけど、収集方法が思いつかなくて頓挫してたやつです。
楽天市場では商品毎の集客キーワードが見えない(見る場所がない)ので収集しようにも取得する場所がない。
情報源が無いという状態は仕組み構築に致命的なので打消し線を入れておきました。
Google対策を考えなければ文章化も不要。となれば暫くは今の姿『優先順位をつけながら文章化』でいいのかな。
構造分析も含めて出力するなら構造文テンプレートが使える
実験的に実装してテストしてましたが、構造文テンプレートを活用するとそれっぽい文章は作れます。
例えばこんな感じです。
■構造文テンプレート
%nume%が%adjective%で%adverb%の%nume%で%verb%でき%nume%が%adjective_verb%。
(元文:フライパンがこびりつきにくく、少しの油で調理できお手入れ簡単。)
■実行結果
フライパンが軽いで少しの玉子焼きでくっつくできパスタが安全。
読むと「???」しかないですが、まぁ今やるとこんなもんです。
もう少し日本語っぽくしようとすると、副詞/形容詞/形容動詞を固定してしまうとか。
%nume%がこびりつきにくく、少しの%nume%で%nume%でき%nume%簡単。
この場合、テンプレートの数を増やす方法がありますし、汎用性も落ちるので利用文をカテゴリと紐づけるとか何らかの対策が必要になってきます。
まとめ
本屋さんに行くと『自然言語処理』とタイトルの付いた本がいくつも並んでいるので、私の手が出る所まで落ちてきたのかと思っていたのですが…。
どうやらまだまだ未開の地。EC事業者や様々な分野からの需要はあるけど構築できていない学問の様です。
いち事業者である私がそんな研究してもしょうがないので自然言語処理は当面捨てて、自然な文章とシステムが勘違いしてくれる文章の作成を目指すのが妥当の様です。
「そうなると、一度封印した『作文テンプレート』の封印を解く必要があるかな」
「この際だからカボチャを使ってパワーアップしようか」
などなど、やってみたい事は沢山ありますがどこまで実現できるか…。AIの言語処理はまだまだ難しそうです。
-
前の記事
負担ポイント見える化ツールを実装しました 2020.05.22
-
次の記事
Docker×Laravelでアクセス元のIPアドレスを取得する方法 2020.05.25
コメントを残す