写真 青い空と雲と建物と木々の緑

nishimotzの日記

  • Knoppix と Ubuntu

    Galatea for Linux の動作検証のために、いつも使っている Vine Linux とは違うディストリビューションを使ってみました。

    USB メモリから起動する Knoppix 5.3.1 環境を作ったところ、Let’s Note で 3D が有効になり FSM が 24fps くらいで動作しました。GalateaTalk (gtalk) からのオーディオ出力で若干不都合があったり、ウィンドウマネージャ(compiz fusion)が FSM 関連で怪しかったり、いろいろ不満はありますが、USB メモリで OS ごと持ち歩けるGalatea が現実的になりつつあると感じました。

    Knoppix で動いたので、同じく compiz に対応している Ubuntu Linux 8.04.1 (wubiを使用)で Galatea for Linux の動作検証を行いました。ただし3次元ウィンドウマネージャの動作を確認したら、GNOMEの設定で視覚効果を無効化した方がよいようです(FSM の不具合はこれで解決しました)。

    Thinkpad の内蔵音源がうまく動かなかったですが、ALSA をアップデートするのは面倒だったので、ノートPCの内蔵音源を無効化してUSBオーディオを使ったところ、音声認識・音声合成の動作も良好でした。

    SRM は Julius 4.0.x ベースになり、ALSA がデフォルトになりました。OSS で動かすためには以下の設定追加が必要でした。

    [SRM/srm.init]
    set Input.from = oss
    

    最後にひとこと。Ubuntu には久々に興奮しました。ALSA の不都合が惜しいですが、ディスプレイ出力の切り替えなどノートPCに固有の機能もかなりサポートされており、全体的によくできていると思います。

  • VoiceXMLとRuby on Rails 続編

    3月にVoiceXMLとRuby on Railsという記事を書きましたが、Ruby on Rails 2.0.2 で作り直してみました。

    # routes.rb に追加 -> http://localhost:3000/weather/state1.vxml
    map.connect ':controller/:action.:format'
    
    # 001_create_region.rb
    class CreateRegions < ActiveRecord::Migration
    def self.up
    create_table :regions do |t|
    t.string :name
    t.string :yomi
    t.string :weather
    t.timestamps
    end
    end
    def self.down
    drop_table :regions
    end
    end
    # 002_add_test_data.rb
    class AddTestData < ActiveRecord::Migration
    def self.up
    Region.delete_all
    Region.create :name => '東京', :yomi => 'とうきょう', :weather => '晴れ'
    Region.create :name => '横浜', :yomi => 'よこはま',   :weather => '曇り'
    Region.create :name => '大阪', :yomi => 'おおさか',   :weather => ''
    Region.create :name => '京都', :yomi => 'きょうと',   :weather => '晴れ時々曇り'
    Region.create :name => '広島', :yomi => 'ひろしま',   :weather => '曇りのち雨'
    end
    def self.down
    Region.delete_all
    end
    end
    class Region < ActiveRecord::Base
    end
    
    class WeatherController < ApplicationController
    def state1
    # counter をセッションで記憶する 
    if !session[:counter]
    session[:counter] = 1
    else
    session[:counter] += 1
    end
    @regions = Region.find(:all)
    end
    def state2
    if params[:region]
    @region = params[:region]
    @weather = Region.find_by_name(@region).weather
    end
    end
    end
    
    [state1.vxml.erb]
    <?xml version="1.0" encoding="UTF-8"?>
    <vxml version="2.0" xml:lang="ja">
    <form id='ask'>
    <field name='region'>
    <prompt timeout='20s'>
    <%= session[:counter] %>番です。
    天気を聞きたい地域を、
    <% @regions.each do |item| -%>
    <%=h item.name %><% end -%>
    から選んでください。
    </prompt>
    <grammar version='1.0' root='#region_rule'>
    <rule id='region_rule'>
    <one-of>
    <% @regions.each do |item| %>
    <item> <token sym="<%=h item.yomi %>" slot='region'> <%=h item.name %> </token> </item>
    <% end %>
    <item> <token sym='まいくてすと'>マイクテスト</token> </item>
    </one-of>
    </rule>
    </grammar>
    </field>
    <block>
    <submit next='<%= url_for(:action=>"state2") %>.vxml'/>
    </block>
    </form>
    </vxml>
    [state2.vxml.erb]
    <?xml version="1.0" encoding="UTF-8"?>
    <vxml version="2.0" xml:lang="ja">
    <form id='answer'>
    <block id='answer'>
    <log>地域=<%=h @region %>:天気=<%=h @weather %></log>
    <prompt> <%=h @region %>の天気は<%=h @weather %>です。<break /> </prompt>
    </block>
    <block>
    <goto next='<%= url_for(:action=>"state1") %>.vxml'/>
    </block>
    </form>
    </vxml>
    

    以前は rxml で VoiceXML を生成してみたのですが、やはり vxml.erb の方がすっきりしました。

    そして興味深いことに、同じコントローラーで html.erb も動かすことができそうです。

    [state1.html.erb]
    <html>
    <body>
    <p> <%= session[:counter] %>番です。 </p>
    <% form_tag :action => 'state2' do %>
    天気を聞きたい地域:
    <select name="region">
    <% @regions.each do |item| -%>
    <option value="<%=h item.name %>"><%=h item.name %></option>
    <% end -%>
    </select>
    <%= submit_tag "実行" -%>
    <% end -%>
    </body>
    </html>
    [state2.html.erb]
    <html>
    <body>
    <p> <%=h @region %>の天気は<%=h @weather %>です。</p>
    <%= button_to '戻る', :action => 'state1' %>
    </block>
    </body>
    </html>
    

    これまでISTCのマルチモーダル対話記述ワーキンググループで提案してきたアーキテクチャ階層:

    • 西本 卓也: “マルチモーダル対話システムのためのアーキテクチャ階層化,” FIT2006イベント企画「音声・マルチモーダル対話記述とその標準化」予稿集, Sep 2006. (PDF)

    と対応させてみると、

    • 6層「データモデル」が ActiveRecord
    • 5層「タスク間制御」が Controller のアクション
    • 4層「タスク内制御」以下が View (html.erb または vxml.erb)

    になっており、モダリティごとの View を統一的に記述する方法を見つけることが、4層と3層を分離して記述するためのステップになりそうです。ヘルパーメソッドやパーシャルなどの機能がその部品になるでしょう。また、コントローラーのモダリティ独立性という観点からも RESTful であることが重要だ思います。

  • 音声対話と「もう一つの未来」

    8月下旬に京都で行われる音声対話技術の講習会で、音声対話技術コンソーシアム(ISTC)が製作する Galatea Toolkit DVD-ROM が配付される予定です。私は主にLinux版に関する Toolkit の更新作業を担当しています。

    SourceForge.JPのgalateaプロジェクトでは通称「IPAライセンス」で開発されたオープンソース成果物とその後継版を配付しています。私が開発している音声対話エンジンGalatea Dialog Studio (GDS) 2.2.2も300件以上ダウンロードしていただいているようです。

    全てのモジュールを統合したISTCの成果物は講習会参加者およびISTC会員に配付される予定です。コンソーシアムの活動は本年度で終了するので、その後の開発を継続するためには、これらのツールに関するオープンソースコミュニティをもっと盛り上げていく必要があるだろうと思います。

    以前この日記で考察した「Ruby on Rails による VoiceXML 開発」はまだ「今後の課題」のままなのですが、Ruby on Rails の「フルスタック」という特長はGDSにとっても重要ではないかと思います。GDS は Java で実装されているのですが、いずれ JRuby によって、アプリケーションとインタプリタのフルスタック処理系に手が届くだろうと展望しています。これは、そもそも HTTP と VoiceXML という技術によって音声対話システムをサーバ・クライアント型モデルに分離したという経緯を考えると、不合理に思えるかも知れません。しかし、その理由はそのまま「フルスタック環境である Ruby on Rails の利便性」と同じなのではないかと思います。

    フルスタックという言葉からもう一つ思うのは、音声対話システムがうまく動かないときに、システムが依存している全てのモジュールの設定ファイルやログの確認を行うのは非常に複雑な作業である、ということです。将来的には、全てのモジュールが統一的なリモートロギングのインタフェースを備える必要があるだろうと思います。暫定的には、全てのモジュール(音声認識、音声合成、顔画像合成)の設定ファイルを対話マネージャが動的に生成し、GDS が各モジュールのログファイルを一元的に監視する、という方向を目指しており、今日もそのための作業をすこし進めました。

    音声対話あるいは音声認識について、ヒューマンインタフェースの開発者・研究者の方々は「実用にならないまま過去のものになってしまった技術」という見方をお持ちかも知れません。その一方で音声認識の研究者の方々には「もう完成されており、後は使ってもらうだけの技術」という見方もあるのではないかと思います。

    西本が今年1月に研究会で発表した

    • 西本 卓也,岩田 英三郎, 櫻井 実, 廣瀬 治人: “探索的検索のための音声入力インタフェースの検討,” 情報処理学会研究報告 2008-HCI-127(2), pp.9-14, Jan 2008. (PDF)

    は、そうした現状における問題提起のひとつなのですが、この予稿の中で私が提案した「インタフェースシステムの導入原則」(下記、一部加筆)があります。

    (ここから)

    インタフェースシステムの基本原則および構成原則(西本 1996)を踏まえて,近年のインタラクション技術の動向を反映させ,また著者の経験を反映させるための再検討を行っている.

    「基本原則」および「構成原則」の視点は引き続き有効である.そのうえで,インタフェースシステムを成功させるためには,アプリケーションそのものの選択や設計により深く関与し,システムをどのような状況に適合させ,どのように評価や改良を行っていくか,というプロセスが重要になっている.インタフェース原則を補完するものとしてこれらを暫定的にまとめたものが,以下の「インタフェースの導入原則」である.

    「インタフェースの導入原則」

    • a.有用性の原則: システムが使用される現場における必然性を考慮して設計と導入を行う.ユーザに動機付けを与える心地よさ・美しさ・楽しさを盛り込む(エモーショナルデザイン(Norman 2004)).
    • b.適合性の原則: あらゆる年齢や能力の人々に対して可能な限り使いやすさを提供する(ユニバーサルデザイン).システムが使われる状況・環境を考慮する.ユーザ以外の人に悪影響を与えない.ユーザが行っている他のタスクに悪影響を与えない.
    • c.妥当性の原則: 妥当な時期に妥当な尺度で評価を行う.評価の結果を生かして反復的な開発・改良を行う.

    (ここまで)

    インターネットにまつわる日々の雑用(その多くは、メールを読んで、メールを検索して、カット&ペーストしてメールを送ったり、ウェブのフォームを埋めることだったりしますよね)が不毛に感じられることがあります。

    GUIが普及してインターネットが普及したからこそ、いまのPC利用の状況は「当たり前」にしか感じられないのですが、たまたま「音声対話システム」がなかったにも関わらず「インターネットというインフラ」は実現してしまい、「人間がやっていた仕事をコンピュータに代行させたい」というニーズが爆発的に増加してしまった。結果的に、テキスト情報と視覚的インタフェースだけで「人間の代わりをしてくれる自動応答サービス」を実現せざるを得なくなった、とは言えないでしょうか?

    音声対話システムは「起きるはずだった未来」あるいは「失われた未来」ではなかったでしょうか。。

    もしも、音声対話システムが「もっと上手に」実現され普及していたら、我々は今日のようなメールとウェブのフォームから解放され、もっとスマートにインターネットを使いこなせていたのではないか、と思えてきました。

    いや、「失われた未来」を取り戻すのは、まだ遅くないと思うのです。いかがでしょうか。。。