形態素解析を行い各投稿の関連記事を出力するプラグイン、WordPress Related Post for Japanese ができたのでおいてみます。 🙂 Yahoo! Japan の提供する形態素解析を用いて、その結果を元にランク付けを行い、シングルページの場合に投稿の最後に関連度トップ5 のタイトルとリンクを付与します。
このプラグインは実は 3年前からつくろうとおもっていたものです(笑)
hiromasa.zone :o) » WordPress Related Entries for J (仮称)
そのエントリに関連するエントリを抽出する、Related Entries for J (仮称) を作り始めてみました。
うーん、この手の日本語の処理は大変です。 漢字コード表とにらめっこで、なんとかデバッグ表示くらいまでは動くようになりました。
N-Gram のまねごとで辞書をつくって検索、、という予定だったのですが N-Gram 解析時にメモリ不足でとんだり、はたまた既存の投稿にたいする辞書作成のよい UI が思いつかなかったりで結局お蔵入りになったのでありました。
時はたち、Yahoo さんが形態素解析 API を提供してくれ、WordPress は wp-cron によるバックグラウンド動作をサポートしてくれ、そしてひろまさくんは PHP が少し分かるようになり(笑)、
[tegaki]期は熟した![/tegaki]
ってことでリリースとあいなりました。 🙂
WordPress Plugins/JSeries » WordPress Related Post for Japanese
Yahoo! Japan が提供する日本語形態素解析APIを利用して、WordPress の投稿をアナライズし、自動的に投稿の下部に「関連する記事」へのリンクを付与するプラグインです。
使い方ですが、プラグイン有効化してほっとけばそのうちいい感じに関連記事がでてくるようになります。 ほっとけば、、というのは過去記事に対しては閲覧をフックして、その投稿に辞書がまだなければ Yahoo! に問い合わせがいくようになっています。 なので、サイトアクセス数にもよりますが 2、3日くらい待ってもらえば次第にいい感じになっていくと思います。
bot の襲撃をうければ一気にできるでしょう。 まったりどうぞ。 🙂
形態素分析なんかはめったにできるもんじゃないので、Yahoo! からの貴重な RAW XML データもそのままテーブルに保持しています。 (wp_)morpheme というテーブルが新規にできているはずです。 最初はこのテーブルのできをみていると面白いかもしれません。
形態素解析。
対象言語の文法の知識（文法のルールの集まり）や辞書（品詞等の情報付きの単語リスト）を情報源として用い、自然言語で書かれた文を形態素（Morpheme, おおまかにいえば、言語で意味を持つ最小単位）の列に分割し、それぞれの品詞を判別する作業を指す。
形態素解析は日本語を文章として解析してそれぞれの品詞を取得できます。 日本語って英語のようにスペースデリミタじゃないので単語の区切りを切り出すには意味の解析が必要です。
日本語の検索というのはこれが難しくって、形態素しないで普通に文字一致で検索をかけると「京都」の検索で「東京都」があたってしまったり、「パン」の検索で「ルパン」があたってしまったりするわけです。 🙂
今回は、このような不具合をさけるためまずは形態素で名詞を抽出し、それをハッシュして DB に登録。 そのハッシュに対して MySQL の like で検索しています。 またハッシュで格納する際に高頻度ででてくる単語を前に配置し、その位置情報も加味してランキングを決めています。(SQL 一発取りしたかったのもある)
まー紛れも多い実装で、やってみるまではドキドキでしたが、うちのサイトではなかなかの精度ででてきてくれるようで嬉しいです。
逆に、Yahoo! が知らない単語、たとえば「プラグイン」が「プラグ」と「イン」にわかれたり、「タチコマ」が「タチ」と「コマ」に分かれたりしていますが、双方はたいていはセットで出現するため大きな問題にはならなかったようです。
関連出さなくても、(wp_)morpheme テーブルを生成するだけでも後々いろいろ使えるかもしれません。(オプションでそういう設定もできます)
たとえば、WordPress のサイト検索をこのテーブル読むようにおきかえると、頻出順とかにもできますし、先ほどの部分一致の問題も回避できるかもです。 あと、robot 用のメタタグいれても面白いかもですね。 一応、隠しで使えそうな function をいれてあったりもします。(やろうとして力尽きたとも言う)
てなわけで、ぼくてきには機能を満たしているので 1.00 にしていますが、みなさんでいろいろ改造してみてください。 🙂
– まっじくなんばー多かったりソースコメントとかええかげんなのは、堪忍な。
早速入れてみました…が、(wp_)morpheme テーブルが作成されません。
ちなみに、こちらの環境は PHP 5.2.6 + MySQL 4.0.27
とりあえず、明日からお盆休みなので子守の合間を見てソースを眺めさせていただきます。
# 今日は、もう眠いzzz
こんばんは。 🙂
おー、もしかすると MySQL 5 系特有のなにかをいれてしまったでしょうか。。
実は create table の部分がちょっといんちきしているので、こちらもみてみます。 (wp_)options から、WpJRelated 項目を消すと、コンストラクタがうごいて create table する予定です。
ご連絡ありがとうございます!
# お子さんいらっしゃったのですね! 知りませんでした. ;D
ピンバック: WordPress Related Post for Japanese いいよ。 | orioa
うわぁ、これはすごい力作ですね。
形態素解析自体はもはや枯れた技術だと思うんですが、その結果を用いて記事同士の関連を見つけるのは、けっこう難しいことです。本プラグインでは、単語の出現頻度が似ているものを関連している記事としているようですが、それでどこまで適合率および再現率が出てくるかは、興味深いところです (「適合率」「再現率」という用語については Wikipedia の「情報検索」あたりを参照)。
関連記事を5本しかピックアップしないため再現性は重視されていないわけで、適合率を高めるのがポイントとなるでしょうか。
をかもとさんの問題は、CREATE TABLE するときに DEFAULT CHARSET=utf8 を決め打ちで書いているのが原因ですね。ここは MySQL のバージョンを確認し、wp-config.php の DB_CHARSET, DB_COLLATE を見て設定するのが、正しいやり方のようです。
wp-admin/includes/schema.php の先頭と、wp-includes/wp-db.php の supports_collation() を見てみてください。Ktai Style の admin/install.php も同じコードになっています。
あと、非常に細かいことで気になったところをいくつか。
・PHP5 専用ならば思いきって private とか使った方がいいかもしれません。
・238行目 add_options_page() で「8」というユーザーレベルを書くよりは ‘manage_options’ というロールを書いた方がいいかもしれないです。
・281行目 get_class は PHP5 では大文字小文字そのまま、PHP4 ではすべて小文字というのはバグじゃなくて仕様のようです。
・525 行目は、get_the_title($id) の方がいいと思います。こちらは保護中とか非公開とかの文字列が自動で付きます (というか、非公開のポストは除外した方がいいのかも)。
最後に質問ですが、テーブルに yahooid が入っている理由がよく分からないので教えてください。
こんばんは。
私のところにも導入させていただきました。ありがとうございます。
さらに細かいことですが…
「li」要素と「ol」要素の位置が逆のように思えます（笑）。
ご確認をお願い致します。
をかもとさん同様テーブルが作られない問題は、さくらインターネットでは起きるようです。ちなみにXREAはオッケーでした。
ピンバック: 【WordPress】「WordPress Related Post for Japanese」導入！ » Telmina
reate table 文がMySQL4系で、うまく動作してないようですね。
手動で create table しただけで行けました。
とりあえずもう一つのブログで動作確認中。
一つだけ不具合報告。IDが同一のレコードが作成されることがあります。
あと、要望としては関連記事をサイドバー等に表示するためのテンプレートタグが欲しいかも。
ピンバック: MMRT daily life
ピンバック: Odysseygate.com
ピンバック: WordPress Related Post for Japanese 導入してみた - kuniharumaki blog
ピンバック: SharpLab. - 関連エントリを表示するWordPressプラグイン
ピンバック: SharpLab. - いつまでも妄想と思うなよ
ピンバック: marblic.com
いつもこのプラグインを便利に利用させて頂いています。
WP2.7にしてからかも知れないのですが、エントリー更新後
すごく重くなる症状が出ています。
phpmyadminでみると、「select mo id if instr mo uniq_delimitar_hash」
というプロセスが並行して10本ほど走っているようです。
ハッシュコードみたいなのも見えますが、まったく同じ値になってます。
もし、思い当たる点や原因などがおわかりでしたら教えて頂きたいのです。
お忙しいと思いますが、よろしくお願いします。
mia cucina さん、こんにちは。 🙂
返信遅れましてすいません。
こちらでも同様の現象を起こそうとしてみたいのですが、プロセスが増える現象は再現できませんでした。
エントリー更新後に発生ということで、ちょっとこれは試しなのですが、もし過去のエントリの辞書が十分にできているのであればオプション画面から「閲覧時(投稿を閲覧した時にその投稿の辞書がなければ作成します)」のチェックをはずして様子をみていただけますでしょうか。
辞書がない新規投稿の辞書作成と、閲覧時の辞書作成と、関連の取得のタイミングがおかしくなっている気がしたのですが、再現できなくなんともでした。。
もしなにか変化がありましたらご連絡ください。:)
ひろまささん、ご返信ありがとうございます。
たまたま、今プラグイン設定画面を見ていて
同じスイッチを殺したところでした^-^
これで状況を見てみます。
再現しないと言うことでこちらの状況をお伝えすると、
いまwp_morphemeが1,200件、50.5 MiBほどになっていて
XREAサーバでWP-Cache付けて運用しているのですが
投稿時と初回閲覧時（キャッシュ作成時）に7~8秒ほど
白紙状態になります。
その時にphpmyadminで確認するとプロセスが多数走っていて
しかもプロセスリストを更新してもなかなか終了しない状態になります。
Sorting Result?という状態でかなり遅くなっているようです。
こちらでもログを取るなどもう少し調べてみます。
失礼します。
mia cucina さん、こんにちは。
状況ありがとうございました。
このプラグインは、導入時点での過去記事用の辞書生成に閲覧をフックしているのですが、それと同時に新規投稿時にも辞書作成を行います。 もしかすると、そのタイミングで不整合しているのかな、と思いました。
もしなにかお気づきの点ありましたらお知らせください! こちらも大きな辞書ということを考えて少し見てみます。
ピンバック: be advanced - WordPressで関連記事を表示