UNIX用かな漢字変換エンジンAnthyβリリース 58
ストーリー by wakatono
おお、βリリースだ 部門より
おお、βリリースだ 部門より
tabatee 曰く、 "私供のProject HekeはIPA未踏ソフトウェア創造事業に採択されて開発を行っており、現時点での成果をβ版としてリリースします。
今回はバグfixおよび使い易さの向上を図りましたので、常用できるレベルに達していると思います。ドキュメントをよく読んだ上でインストールをお願いします。
コメントやバグレポートをお待ちしています。
今回公開するバージョンにはまだxemacs対応を取り込んでいませんので、 xemacsで使いたい人はcvs.m17n.orgから最新版をgetしてください。"
さぁ、以前/.-Jでもαリリースを紹介したが、今度はβ版だ。リリース版の完成度を高めるべく、みんなで使い込もう。
辞書構造の古さ (スコア:4, 興味深い)
変換エンジンを新しくするのはいいけど、辞書が単語情報しか持っていないというのは...
辞書の語彙数が10万を超えてくると、分ち書きの場合の数が爆発的に増えてきます。こうなると現行のfreeな変換エンジンで利用している単語やその頻度、品詞連接の情報だけでは変換精度が急速に悪化してきます。特に、日本語は名詞の連続により数多くの複合語を構成することができます。この場合、品詞連接の情報が全く役に立ちません。結果として、ひどい変換をしてしまうことがあります(仕事場にあったEDR辞書から作成した合計24万単語の辞書をFreeWnnで使用した印象)。
この問題を解決するため、たいていはコーパスを用いて単語連接の情報を学習します。そのためには、単語単位での連接情報が辞書に保存できなければなりません。そのための準備がエンジンおよび辞書の両者にあればよいのですが、もしないとなるとどこかで性能が頭打ちになってしまう心配があります。
Re:辞書構造の古さ (スコア:2, 興味深い)
また、品詞の情報以外を持たせること考えていますが、その前によりシンプルかつ有効なアイデアが存在するので、そちらを実装してから検討するつもりです。
んで、語彙数が増えただけで破綻するのはFreeWnnの方の問題ではないかと思います(変な頻度情報を付けてない限りは)。
毎年大量の金をつぎこんで研究や統計処理をしている売り物に勝てないまでも、フリーソフトとしてより良い物をつくり出そうというのが、うちのプロジェクトの目標です。
NL面でも手弁当でできることはある (スコア:3, 興味深い)
品質をどこまで求めるのかは品詞選択などモデル設計に大きく依存するので、単に高品質のコーパスが手に入らないからあきらめるというのは最適な選択ではありません。
現状でのFreeWnnやCannaの品詞を考えると、ChaSenの品詞細分類よりはかなり粗い分類です。そこで、お金をかけずにできそうなコーパスおよび辞書作りの方法を考えてみました。
これだけでもそこそこ量は集まりそうな気がするのですが。名詞だけでもやってみては?
なお、語彙数の問題は、私の辞書の半分強しかないcannadicでも変な変換をする報告 [srad.jp]がすでにあります。これはanthy上で起きているので、変換エンジンよりも辞書の問題と考えるべきです。また、昔DOSで使っていたWXPは辞書を10万語に拡大した時点でいち早くこの問題を見抜き(当時のATOKは高々3万語)、単語連接のコストを最小化する戦略転換を行っています。
ところで、プロジェクトの中に自然言語処理を本職または趣味でやってる方っていらっしゃるんですか? あちこち見てもその方面の知識がありそうな人が全然見当たらないんですが...
Re:NL面でも手弁当でできることはある (スコア:1)
この推論の根拠は?
Re:NL面でも手弁当でできることはある (スコア:3, 興味深い)
繰り返しになるかも知れませんが、この「辞書の問題」とは、「語彙の特徴を表す情報の欠落」です。その上で、私が指摘したような誤変換というのは、品詞パタンは確かに知識に合致しているが、そのなかに入る語彙の並びが人間が書く文章ではあり得ないというものです。他の例としては、「接頭辞-名詞-接尾辞」と「名詞-名詞」です。私はかつて用語抽出に関わっていた時にこの問題にぶち当たりました。いずれの品詞パタンもいろいろな例を考えることができてしまうので、結局品詞情報のみで勝負するのは不可能という結論に達しました(穴埋めには語彙の情報を用いた)。いずれの例にしても本質的な情報を見落としているので、アルゴリズムからの改善には限界があります。
なお、全く品詞情報なしに問題を解いている例としては、音声認識があります(2年ほど手をつけていた)。ここ最近の音声認識の処理は
という2段がまえが主流です。このうち2.に着目すると、音素列はかな列によく似ており、ゆえに2.の処理はかな漢字変換の問題とよく似ていることが分かります。2.に用いる知識としては品詞パタンやそれを一般化した文法規則などさまざまな試みがありましたが、精度を飛躍的に改善したのは単語のn-gramモデルでした。私もこのモデルを作ったことがありますが、品詞の情報はモデルには全くありません。それでもサンプル文などで測ると8割や9割は正しく認識できます。
異なる問題を解くに当たって同じような傾向があることが分かっているので、人間の都合だけで語彙情報を切り捨てる方向に向かうことに不安を覚えるわけです。
コンパイル問題 (スコア:2, 参考になる)
anthy-2427 をコンパイルする際、すでに anthy がインストールされていないとコンパイルがうまくいかない、という不具合があります。
実際にはコンパイル正常に終了したかのように見えるのですが、src-main/.libs の中身が、 332808 libanthy.a 14 libanthy.la -> ../libanthy.la 723 libanthy.lai 17 libanthy.so -> libanthy.so.0.0.0 17 libanthy.so.0 -> libanthy.so.0.0.0 151220 libanthy.so.0.0.0U* というぐあいになり、libanthy.so と libanthy.so.0 のシンボリックリンクが切れてしまっています。
一方、src-diclib のコンパイルはうまくいきます。
とりあえず、libanthhy.so がない状態でインストールしてしまうと、 次回コンパイル時には libanthy.so も正しくコンパイルされます。 インクルードファイルか何かがシステムにインストールされているかどうか、 ということが原因になっているのではないかと想像しています。
Re:コンパイル問題 (スコア:1)
手元では再現できないので、他の方の試していただけないでしょうか?
またdebian使いの方はおもてさんのページ [utyuuzin.net]のdebでも試してもらえないでしょうか?
Re:コンパイル問題 (スコア:1)
Debian 使いですので、それでも試しました。
たまたま、おとつい、いろいろと試していたのですが、その deb パッケージでも問題が再現しました。 つまり、パッケージの再構築を行うと、libanthy ができない問題が原因で止まってしまいます。 このとき、前もって libanthy0 と libanthy-dev をインストールしておくと、正しく再構築できます。
環境は、Debian Sid、gcc 2.95.4、libtool 1.4.2 です (って、libtool って関係あるのかな?)。
Re:コンパイル問題 (スコア:1)
一応anthy関連のファイルは全部削除してからコンパイルしたつもりですが、前にインストールした事があるので、そのファイルがどこかに残ってしまっているかもしれません。
gccは2.95.4だと思います。(3.0.3も入っているのですが、どっちが使われてるのか良くわかってないのです。MakefileにはCC=gccとあったのでたぶん2.95.4だと思うのですが。)libtoolは1.4.2です。
Re:コンパイル問題 (スコア:1)
# rpm -ivh anthy-2307-1.i586.rpm
error: failed dependencies:
libanthy.so.0 is needed by anthy-2307-1
srpmのtar玉からコンパイルした場合の $ ls src-main/.libs/
353742 libanthy.a
14 libanthy.la -> ../libanthy.la
735 libanthy.lai
17 libanthy.so -> libanthy.so.0.0.0
17 libanthy.so.0 -> libanthy.so.0.0.0
159914 libanthy.so.0.0.0
環境は Kondara2.0、gcc-2.96、libtool-1.3.5です。
specファイルいじってlibanthy.so* をrpmに含めるとこまではやったんですが、
Jmodeをコンパイルする段階でエラーが出て、結局投げてしまいました。
# 負け犬ッス (^^;
ただ、その時のエラーがlibtoolがらみだったような。
今手元にログがないので、ちょっと再挑戦してみます。
Re:コンパイル問題 (スコア:1)
私は、anthyについてはCVSから落としてきてインストールしたんですが、
同じJmodeのコンパイルでエラーが出てそのままです。
私の場合は、configureでlibanthy.aが見つからないとか
言われていますね。
#/sbin/ldconfigとか、シンボリックリンクとかも
#ちゃんとやったはずなんだけどな
あとでもう少し調べてみます。
Re:コンパイル問題 (スコア:1)
jmode0.4.27をDLしてmakeしなおしたんですが、今度は問題なく通ってしまいました。
あう、再検証ならず……。
anthyのコンパイル問題は、SRPMだとspecファイルの %makeinstallセクションに
mkdir -p ${RPM_BUILD_ROOT}/usr/local/lib
install -c -D -m 644 src-main/.libs/* ${RPM_BUILD_ROOT}/usr/local/lib
%fileセクションに
/usr/local/lib/*
を追加することで回避しました。
libanthy.so.0がハードリンクされますが、とりあえずは問題ないと思います。
# マズかったら突っ込んでください。
Re:コンパイル問題 (スコア:1)
Re:コンパイル問題 (スコア:1)
今朝ためしてみると、なぜか再現しませんでした。anthy 関係はすべてアンインストールしてから試したのですが。
というわけで、なにかこちらの環境の問題だったかもしれないのですが、とりあえず問題が生じたときの状況を記憶を頼りに説明すると、コンパイルエラーは出ません。Debian パッケージの再構築では、ユーザ用ライブラリパッケージの構築では libanthy.so を削除するようなのですが、その際に libanthy.so がないといってエラーになります。もとの anthy-*.tar.gz のコンパイルにおいては、make install さえも正常終了しますが、ほかの報告にもあるように、つづいて jmode のコンパイルを試そうとした際、libanthy がないといってリンクエラーになります。
Re:コンパイル問題 (スコア:1)
(また、debianの方も同様の修正を追加したanthy-2427-2 [utyuuzin.net]に更新されています)
テストして、有益な報告をくださったみな様、有難うございました。
Re:コンパイル問題 (スコア:1)
今度はおとなしくSRPMを使ってインストールしたら、
問題なくインストールできました。
ついでにKDE3.0系(CVS版)のソフトで試したら、
OverTheSpotでは確定前の文字は表示されませんが、
入力そのものはできますね。
さらにOnTheSpotでは、文字が確定後にもう一度表示される
(連続した2つの入力になる)
という現象になりますね。
#暇ができたら調べてみよう。
コンソール上での日本語入力 (スコア:2, 興味深い)
X Window System 上での日本語 (多国語) 入力には、XIM という標準が存在します。 (Project HEKE では IIIMF はステだそうですが、IIIMF を推進している人たち [Sun だとか Li18nux だとか] にはその問題点を伝えたのでしょうか。 将来にその問題点が改善される見込みは?) しかし、コンソール上で日本語を使いたいと思ったとき、 各々のソフトウェアが Canna/Wnn といった各々のプロトコルの API をそれぞれ実装して対処している、というのが現状です。この方法だと、
- アプリケーションソフトが対応していないと日本語を使えない
- 個々のアプリケーションソフトごとにいちいち設定が必要
- 特定の変換エンジンしか使えない
といった問題があります。さらに、アプリケーションソフト開発者に日本語や各 API に関する知識が要求され、 「すべてのソフトウェア (あたりまえですが外国製も含む) で当然のように日本語が使える」 という目標はとうてい達成できません。複数の変換エンジンと交信でき、多国語が入力できるアプリケーションソフトもあるにはありますが (Mule/Emacs) それひとつだけ、というのはいやですし。(じゃあ 1000 個あればいいか、という数の問題ではなくて、世の中のソフトウェアのなかの大多数がそういう機能を持ってほしい、という割合の問題だと思ってます)。そこで、Linux/BSD のコンソールそのものあるいは GNU screen などが、日本語などの変換エンジンと交信できるための統一的な API があればいいなと思うのですが、そのようなプロジェクトって、 あったりしないでしょうか?
uum/canuum/skkfep みたいなアプローチでもいいのですが、 これだと、システム側の設定やユーザのドットファイルによる設定になじまないし、その上で走っているアプリケーションの実行中に動的に切り替えることができません。 やはり、標準 API が存在し、そしてその API が生き残るためには世界標準 (デファクトスタンダードでもいいです) でなければならず、そのためには「日本語のための規格」であってはならないと思います。
とかいいながら、ぼくは XIM のプロトコルでさえろくに理解してなかったりする...
Re:コンソール上での日本語入力 (スコア:2, 参考になる)
#あとまぁ、ある偉い人にLinuxの世界も政治力だよと言われてやる気を無くしたという面があります。
コンソールで各国の入力システムを統合して扱うライブラリとしては、turbolinuxのunicon(の関連ページ) [linux.or.jp]があったと思います。
んで、これからは多少問題があるにしてもgtk+-immoduleとIIIMFがデファクトスタンダードになっていくと思われます。(欠点はそれぞれgtk+でしか使えないということと、入力システムとしてどうかなぁという設計)
私個人としても各国の言語の固有の問題について調査/整理をして、そのような理想になるべく近い入力システムを設計しようとして仕様書を少しずつ書いてはいるのですが、いつ動くかはわからない超長期プロジェクトになりそうなので期待しないでくださいまし。
Project Hekeとしての目標はそれらの問題に対しては目をつぶって、できるだけ日本語の入力をうまく処理することにしぼっています。
IIIMF (スコア:1)
IIIMF はじつは試してみたことがあるんですが、コンパイルエラーの山で、それをとりあえず消すためにいろいろと小手先の対応をしてやっとの思いでバイナリを作ったらこんどは segfault するので、もう手が付けられなくなって投げ出した、という過去があります。
いまはもうちょっとましになっているのかもしれませんが、Sun という大きな後ろ盾を持っていながらこの品質ではなあ、と思ったことです。
が、ロケール非依存、Unicode 使用、というのは世の人々に対するウケがいいですから (Yudit の作者の Gaspar Shinai さんも気に入ってました。Yudit が kinput2 をサポートするのに XIM をサポートしないのは、XIM がロケール依存だからだそうです)、たぶん広まることでしょう。文句を言う、というよりは、未完成のソフトウェアには欠陥があるのが当然なのだから、どんどんバグレポートを出してあげるというスタンスでやるのがいいのではと思います。とくに、XIM とか IIIMF って分かってる人が少なそうですので (ぼくもさっぱり分かりません)、分かってる人が指摘しないとだれも指摘しないで終わってしまう恐れがあります。
政治力云々ですが、ぼくも Unicode Consortium に文句をつけたりしていると、そういうことを感じたりもします。Unicode の場合は政治力同士の力のせめぎあいや対立、という側面が強いですが、IIIMF はどうなんでしょうか。Sun だけがやっているので、政治的対立を生むような対抗勢力が存在しないような気がするのですが。
Re:IIIMF (スコア:2)
もともと Sun の社内製品ですから，Solaris 上でしか動作確認されていないだろうし，Solaris 独自のライブラリやソース公開できない他製品に依存していたかもしれないし，移植性という意味ではそれほど期待しない方がいいでしょう。
だいたい，移植性を考慮し出すと，X のソースみたいな #ifdef の嵐になるものです :-)
XIM が検討されていたのは10年くらいは前のことです。 そのころはまだ Unicode も正式な仕様としては出てなかったし， ロケールに依存しないで国際化プログラムを組もうとすれば， Compound Text や ISO-2022-JP みたいなエンコーディングを 直接いじらざるを得なかったし， 全てのプログラムの文字列処理にそこまでやらせるのは， かなり無理があったものです。 (xterm の議論 [srad.jp]を見る限りでは，今でも まだそこまで要求するのは無理そうですが。)
マルチリンガルったって， 当時は mule だってあったかどうか (Nemacs はあったかな) くらいの 時代ですからね。
まあ，いまは Unicode も無視できないし， サーバ/クライアント・モデルで， どのプログラムが どこまでロケールに依存すべきか， という話もあるし，いつまでも昔のしがらみを引きずることも ないでしょう。いい方式があったらぜひとも提案してください。
でも，Yudit が XIM を使わないのは， 単に自分で何もかもコントロールしたいからじゃないの。 kinput2 がばりばり Unicode 対応したという話も聞かないし。
一つの解法として (スコア:2, 参考になる)
えせかんな [netfort.gr.jp]という物があります. これは基本的に日本語対応ですが, VJE等をCannaサーバに見せかけることにより, XIMに対応していない(例えばkinputプロトコル専用の場合等)プログラムでも市販の日本語フロントエンドが使えます.
まあCannaのAPIが多国語対応として良いかどうかは別問題ですが(けど中文版Cannaってのもあるんだよね), 過渡的な対処方法の例にはなるのではと思います.
GIMP (Generl Input Method Protocol) (スコア:1)
GIMP という名前は置いておいて (スコア:1)
readline ライブラリのようなものの上に実装されると嬉しいと思われ。
# mishimaは本田透先生を熱烈に応援しています
多スクリプト入力はどのレイヤーがいい? (スコア:2, 参考になる)
なぜ? readline ライブラリだと、それを用いたアプリケーションでしか日本語を入力できないですよ。世界中のすべてのコンソールアプリを readline (のようなもの) 対応に書き換えないといけなくなります。(実際に GNU readline を使おうとするとライセンス問題が発生しそうですが)。
ぼくは、コンソールそのものが変換機能 (をプラグインできるためのインターフェース) を持つのがいいと思っています。GNU screen だとか uum/canuum/skkfep とかでも「すべてのソフトウェアで日本語 (中国語、韓国語、...) を」は実現できますが、ログインした後にそれらを起動しないといけないのが不満が残るところです。ただ、どうせ別の目的で GNU screen を起動するんだ、という人の場合は、ついでに日本語変換もサポートしてくれたら嬉しいことでしょう。また日本語表示はできるけど日本語変換はできないリモート環境での利用においても、screen/uum/canuum/skkfep 的なアプローチは有効です。
というわけで、コンソールそのものを基本とし、GNU screen のようなレイヤーにも補助的に変換機能 (のプラグインへのインターフェース) を備えるといろんな場合に対応できて、いいんじゃないかと思います。
ところで、「思われ」というのはどういうニュアンスの言葉なんでしょうか。
Re:多スクリプト入力はどのレイヤーがいい? (スコア:3, 興味深い)
GNU screen の場合、相手が console だったり仮想端末だったりリアル端末 だったりするので、screen 自身で完結した機能をもった方がいいだろうなと 私は思っています。なので ああいうパッチ [daionet.gr.jp] を書きました。
screen に generic な front end をしこめるような 方法を以前から妄想はしてるんですが、なかなか実現に至りません。 一応 layer という概念が screen にはあるので、がんばれば できそうだなあという見通しだけはあるんですが...
あと、あのパッチはかなり ad-hoc な実装なので、 今後は期待しない方がいいです。私も最近はほとんどつかってませんし。
knok
Re:多スクリプト入力はどのレイヤーがいい? (スコア:1)
というか今の今まで screen というコマンドの存在を忘れていた。
実際、自分の頭の中に最初あったのはまず、
「VT100 with XIM」みたいな形で端末の規格の中にそれを押し込めてしまうものだったけど、
これにはちょっと無理がある。
その後「cursesライブラリ上に実装する方がよかろ」と思ったが、
それだと範囲が広すぎるのでは？との思いから readline に至ったわけなんだけど。
> ところで、「思われ」というのはどういうニュアンスの言葉なんでしょうか。
「思われる」「思われます」ですな。
# mishimaは本田透先生を熱烈に応援しています
Re:コンソール上での日本語入力 (スコア:1)
確か GNU screen には Onew のインターフェースがあったような記憶が仄かにあります (ローカルパッチの類かも。使い手ではないので良く知りません _o_;)。
Re:コンソール上での日本語入力 (スコア:1)
onew (スコア:1)
onew そのものの tar.gz (ずいぶん昔のものっぽいから tar.Z でもいいけど) がどこを探しても見つからないし、onew を統合していると言われている jvim-canna の tar.gz を調べてみたところ onew 由来らしきソースファイルがひとつあるだけでドキュメントさえもないのでよくわからないのですが、onew は日本語専用っぽい気がします。日本語専用のものが GNU のソフトウェアに統合されるということは、ありえないと思います。
GNU screen + onew は、ローカルパッチとしては、存在するみたいですね。
Re:onew (スコア:1)
README.ONEWを見た限りでは、日本語に特化したもののようです。
Re:コンソール上での日本語入力 (スコア:1)
>日本語などの変換エンジンと交信できるための統一的な API
PocketBSD(に限る必要は全く無いが)方面には
MGL2 [sakura.ne.jp]という画面環境が有り、こいつ用のimのAPIってーかが存在します。
既にimcannnaとかimskkとかimkazeとか(^^;が有ります。
>これだと、システム側の設定やユーザのドットファイルによる設定になじまないし
MGL2は馴染んでいるような気がします。
#あーゆーのを以って馴染んでると呼んで良いんですよねえ?
>その上で走っているアプリケーションの実行中に動的に切り替えることができません。
で、MGL2のために、
imProxy [nifty.ne.jp]なんてものを作ったことが有ったりします(^^;
なんかかなりインチキくさいですし、色々不備も有りますが、
いちおうまがりなりにも「動的に切り替える」ことが出来ます。
proxy(代理)オブジェクトのノリっす。必要になったら必要な本物のimを起動して処理を丸投げするってわけね。
こんなんじゃ…だめですかねやっぱり?(^^;;;;;
Re:コンソール上での日本語入力 (スコア:1)
また、バックエンドの側の視点というのも忘れてはいけません。たとえば日本語の場合、各個人のデータは他のユーザから保護されないといけないし、変換エンジンはそのデータに対してトランザクション的なアクセスが必要だったり、独特のパターンで高速なアクセスが必要だったりします。また、それらのデータは入力を行うソフトだけではなくて、辞書を操作するユーティリティがアクセスすることも考えておかないといけません。
セキュリティ保護の枠組みとかは自分で持つのはかなり無理があるので、Anthyの場合はUnixのパーミッションのモデルとかsshなどに頼るようにしています。
オフトピながら (スコア:1)
国と言語は一対一対応ではないので、「多国語」よりも「多言語」の方がよいと思われ。
それを言うなら (スコア:1)
言語と文字 (スクリプト) も一般的には一対一対応ではないので、「多言語」よりも「多スクリプト」のほうが良いです。でもやっぱり入力モードは言語別のほうがいいから「多言語」のほうがいいかも。
jmodeが落ちる (スコア:1)
GLib-ERROR **: could not allocate -1464288248 bytes
aborting...
Abort (core dumped)
とエラーを出してjmodeが落ちちゃいます。
ちょっと調べてみたところ、gtk_init()で落ちるようで。
ちなみに環境はRedhat7.1, gcc-2.96, gtk-1.2.9。
うー、なんでだろ？。
# 上の「初回コンパイル時のリンク切れ」は問題なかったんだけどなぁ。
Re:jmodeが落ちる (スコア:1)
とりあえず、0.4.26ならなぜかうまく動くらしいのでそちらでお願いします。
それからelispの方は動いてるでしょうか?
Re:jmodeが落ちる (スコア:1)
結果は同じでした…。残念。
elispのほうは使えました。
# この手のバグは見つけるのが厄介ですよねぇ～。
FreeBSDでコンパイルと動作確認 (スコア:1)
展開してコンパイル一発でした…逆にあっけなかったというか(汗
動作確認した環境は
FreeBSD4.4-STABLE
コンフィグ時に
%env CFLAGS='-O2 -march=i686 -pipe' ./configure
した以外はすべてデフォルトです。
ports/editorsよりインストールしたemacs21で動作確認しました
…というか普段がjvim+FreeWnnなので、この動作検証のために
emacs21入れる方が時間かかったなぁ(苦笑
変換の癖のチェックやWnnとの比較はこれから行います。
Re:FreeBSDでコンパイルと動作確認 (スコア:1)
そんでviですか...w3mのパッチも作れたのでvi対応も辛くはないのですが、やっぱり国際化を考慮したレイヤを通してから実装をしたいと思っているので、すぐに出来るとは期待しないでくださいませ。(勝手にやってくださる分には大歓迎です)
;私の研究室のボスにして初代Wnnの作者の湯浅教授は自作のエディタにAnthyを組み込んで常用しておられます。(作者としてありがたいやら信じられんやら)
ウェブページ (スコア:1)
Project HEKE のウェブページ [kmc.gr.jp]に、ベータ版のニュースリリースがないですが、書いた方がいいと思います。
ところで、このウェブページ、レイアウトの意図がよくわからないんですが、どういう順番で読めばいいのでしょうか? (「IRCの %へけ というのは、もちろんニュースではないですよね?)
PS. コンパイル問題の対処ありがとうございます。
PS2. tabatee さんの卒業後もこのページが Project HEKE のオフィシャルページでありつづけるのでしょうか。
付属語の連接、長すぎませんか? (スコア:1)
「みれるとおもったが」→「見れるとおもっ|他が」
「ないこともないが」→「ないこともな|意が」
など、付属語が連接しすぎのケースが目に付くように思います。この辺はさじ加減だと思いますが、もう少し連接を絞ってもいいので は?
「貴社の|貴社が|貴社で|期しゃした」とかも同様です。
Re:付属語の連接、長すぎませんか? (スコア:1)
学習アルゴリズムも工夫しているので、一度間違えた入力を訂正したあともう一度入力してみてください。この学習機構の効きについても意見をいただけるとありがたいです。
「期しゃした」が先頭に出てくるのはバグで、cvs版では修正しました。
「見れる」は「ら抜き言葉」の扱いになってましたが修正する方向です。
「無いこともないが」は付属語グラフの評価のせいで、多分その「さじ加減」の問題になるので難しいです。
多くの誤変換は確率の問題ででてくると思われがちですが、Anthyはまだそのレベルには達していないので、この手の報告も助かります。
Re:付属語の連接、長すぎませんか? (スコア:1)
「見れる」はまさにら抜き言葉だと思うのですが..?
まあそれはおいといて、もう少し調べてみたところ、「思ったが」が一文節として扱われず「思った|画」になるのがもう一つの原因のようです。こっちは付属語連接が短すぎたとうわけですね。
「無いこともな|意が」に関しては、難しいとのことですが「無いことも」までの連接にとどめておくべきでは? 「無いこともな」の「な」は終助詞だと思うんですが、文末以外での連接を許すと誤変換の温床になると思います。
「そのなまえで」→「祖のな|前で」になったりしますよ。
ちなみに、MS-IMEやATOKでは「無いこともな」は一文節扱いにはならず、「無いことも|な」になります。まねすればいいというわけではないですが、参考にはなりますよね。
Re:付属語の連接、長すぎませんか? (スコア:1)
ソース中のmkanthydic/*.depwordに付属語のグラフが書いてあって、誤変換の多くはここに遷移を追加するだけで解決するんですが、グラフにご指摘のあった終助詞などをふくめてもうちょっと情報を持たすことを検討しています。
Re:付属語の連接、長すぎませんか? (スコア:1)
> もう一度入力してみてください。この学習機構の効きについても意見をいただけるとありがたいです。
これは、文節区切りの誤変換の学習のことですね?
「このはな」変換→「此のはな」→「この|花」確定。とかしてみましたが、2回目はちゃんと「この|花」に一発変換しました。また、「この|花」を「此のはな」に戻してみると、それも学習します。いい感じだと思いました。
ただ、ちょっと融通が利かない面もありますね。「この|花」学習後に「このはなが」を変換すると「この|花が」ではなく「此花が」となります。もう少し学習を効かしてほしい気もしますが、微妙なところかもしれません。
逆に、「このはなしを」を変換すると「この|花|氏を」になるのは学習による誤変換ですね。こちらのほうは学習が効きすぎて弊害になっており、このままではまずいように思います。
付属語の方もそうですが、いろんなところにさじ加減がありますよね。対応するのは大変だと思いますが...
Re:付属語の連接、長すぎませんか? (スコア:2)
学習のやり方が相当ad hocなようです(「さじ加減」という言葉が出てくるあたり、学習アルゴリズムに限らない問題と考えるべきだが)。そのために、表向きは「学習した」ように見えているのですが、実は学習による変換モデルの更新がコントロール不能な状態に陥っている(評価基準が数学的な裏付けを持っていない)のではないでしょうか。
そこへいくと、確率モデルでは評価基準が意味のわかりやすい形式で出てくれるので、他の人にとっても楽なんですけどねぇ。でもコーパスを使うことをあきらめた段階でこの事実に気付けなかったとすれば、仕方ないです。
ad hocな改良中心の戦略に学習を加えることは正しいの (スコア:2)
考えを広げていくうちに、ある大きな疑問が出てきました。
おそらくプロジェクトの方針としては、できるだけ人間の直観をモデルに反映させることを狙って、ad hocな改良を加え続けていくことになるのでしょう。ところが、先に挙がっている文節区切りの学習などは、よくよく考えるとコーパスに基づく自然言語処理の一部分です。より一般化すれば事例に基づくモデル構築の部分問題になっています。モデルが先にありきとする前者の立場とは真っ向から対立してしまいます。
同じ問題に対し、両者が同じ解を導くことは一般にはありません。すなわち、人手で作成したモデルが事例によって否定されてしまう可能性があります。もし最初にモデルをおくことから出発した場合、この問題は動作原理の一貫性を損なってしまう恐れがあります(全てを学習に帰着させる場合は、学習手法をfixしておけば再学習が可能)。
というわけで、ad hocな改良と事例ベースの学習をそんなに単純に混ぜてしまう方針には大きな不安を覚えるのですが...
使用雑感(兼バグレポート) (スコア:1)
使ってみてすぐ気付いたことなので、既知の現象かもしれませんが。
(使用環境:anthy2427b、jmode0.4.26、emacs20.7、Mozilla0.9.7)
・Canna/kinput2環境のemacsで、C-oで文節を伸長しようとすると、
Cannaが立ち上がってしまう。(.emacsいじればいいだけかも)
・変換モードに入ってからの文字修正ができない。
(emacs)変換中BSが効かない。
(jmode)BSで変換確定してしまう。
・jmodeで〈《【『といった括弧の変換ができない。
・jmodeが立ち上がった状態でemacsを起動するとSIGSEGVる。
-nwオプションで回避。
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x08097a17 in XMapRaised ()
現時点では、どちらかというとAnthyよりjmodeの方が気になります。
C-oでCannaが立ち上がるのを嫌ってIM無指定にしたので、いまもAnthy+jmodeで書き込みしてるんですが、かな←→英数字の切替えが面倒です。ショートカットが欲しい。
バグレポートの受け口は、今後もIRCとメールだけなんでしょうか。
Re:使用雑感(兼バグレポート) (スコア:1)
jmode起動時にemacs20.7を起動すると死ぬ現象に対する解決法として、 環境変数LANGをLANG=Cにしてemacsを起動すると回避できるそうです。
例によって (スコア:0)