Charlie's volatile short

「その目的にはこのAPIを使うのが最適です」、最適なAPIをワトソンの技術で教えてくれる、米IBMが「API Harmony」発表 @ Publickey

要件に適合するAPIを探すのに人工知能を使うというもの。
詳細は書けないが、機械学習を応用して、入力データの特性に応じて処理アルゴリズムとパラメータの組を選択するというシステムを手がけたことがある。多分そういうのだと思う。

mixiの「メールアドレスを入力して探す」機能が割と危ない件 @ tokikawase

mixi「メアドでユーザー検索」取り下げ　反発受け3日で見直し @ ITmedia News

反発というより「悪用の報告もあった」(ITmedia)ことが取り下げの判断につながったのでは?　危険性はリリース前に内部で気付きそうなものなので、気付いてもなお一旦リリースしてしまったmixiの決定ロジックにどんな問題があるのか興味深い。

NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance @ CNET Japan

「(オン・メモリを前提とするアーキテクチャのDBで)実メモリを超えたデータをどうやって扱うのか？」という問題に『1GBの物理メモリで10GBのデータを扱う』という意味で「1:10問題」と命名している。だけど、これって「ワン・テン」が語呂がいいからという理由かしらん? 意図としては1:2でも1:1000でも1:256でもよいはずで。

メモリを増やして対処するというアプローチの実例として、64GBだか96GBのメモリを積んだサーバでsuffix arrayを処理しているというのを聞いたことがある。だいぶ大容量かつ安価になってきたSSDを使った構成とで、速度やコストの比較を知りたいなぁ。

Baidu.jp 不自然言語処理コンテスト

間違っていても読める、読みづらく書きづらいのに使われている、あるいは短くて書きやすいけど知らない人には伝わらない表現－このような不自然なことばは、検索エンジンを作るBaiduにとっては、ちょっと厄介な存在です。
そこで、最良の検索エンジンの提供を志すBaiduでは、このような言葉を「不自然言語」と名付け、これによりまっすぐ向き合うべく、「Baidu.jp 不自然言語処理コンテスト」を開催いたします。

検索避けで「//」を間に入れるとか、「ネ申」とか書いているのを、検索サービス側としては何とか検索できるようにしたい、と考えているわけですが、そのための知恵を公募しちゃおうというもののようです。
(2010-06-29追記)
コンテストのサイトで紹介されている「ｧﾀｼ」の例はWikipediaでギャル文字として紹介されているもので、「みさなん こんちには！」は/.-Jで

にんんげ は もじ を にしんき する とき その さしいょ と さいご の
もさじえ あいてっれば じばんゅん は めくちちゃゃ でも ちんゃと
よめる という けゅきんう に もづいとて
わざと もじの じんばゅん を いかれえて あまりす。

と紹介されているもののようです。Charlieが勉強した頃には情報検索というとまだ図書館の蔵書検索のようなものがメインだったので、「検索対象の情報は誤字脱字が少ない」という前提の処理ばかりでした。当時からあったのは、送り仮名の揺れとか平仮名を「ひらがな」と書いたりといった表記の揺れを吸収する研究とか、OCR(スキャナなんかで画像にした文書からテキスト・データに変換)処理したときに認識誤り(ゼロとオーとか、漢字の「くち」とカタカナの「ろ」とか)があっても検索できるようにする研究とかですね。後者を発展させれば「ネ申」とかギャル文字を検索できるようになってるはずなんですが、今はまだそこまでたどり着けていないようですね。

アイトラッキングから検証した、使いやすいフォームの10のポイント @ コリス

電話や郵便番号の入力は、ユーザーを悩ませます。(略)
あらゆるフォーマットの入力を受け付けるように設定してください。

「あらゆる入力を受け付ける」は難しいとしても、未だに「住所の番地は全角で入力してください」とかほざくシステムが多いのは以下のような打算がサービス提供者に働くからだと思う。

• 入力の許容度を上げるのは、エラーにしてしまうよりコストがかかる。
• 住所の入力等はサービスの主要機能ではない。たいてい住所や電話番号を入力するのは、買い物の精算中とか会員登録なんかの「ここまで来たのに今さらやめられるか」というタイミングなので、多少面倒でも続ける人がほとんど。
• コストをかけても売上げに良い影響はない(だろう) → それなら別に凝らなくていいや。

表現の許容度が高いオープンソースの入力用ライブラリが定石として普及すればいいんでしょうが、日本語・日本の制度向けのは寡聞にして知らないですね。
「01/02/03」って日付の解釈はいろいろできるとか(平成元年のつもりかもしれない)いうのは情報処理・言語処理の分野で長年研究されているようですが(分野名としては情報抽出; Information Extraction)。形態素解析のライブラリはあるのにね。

関連記事

• よく使われる正規表現はCPANのモジュールを使いましょうというお話
• 客からお預りしたものだから手を付けちゃダメってこと?

「パス」の検索結果によると、 2009/01/31現在、IT用語辞典 e-wordsもwikipediaもマイクロソフトもはてなも全部

このサイトはコンピュータに損害を与える可能性があります。

だそうで。

▼ Googleで「パス」を検索した結果の画面

さらには…

続きを読む »

ニュースの可視化サイト『Newsgraphy』を公開しました @ kaisehのブログ

NTTレゾナントのBLOGRANGER TGは、話題の広さを高低で表現していた。Newsgraphyは、時系変化を色で表したり、人や場所といったエンティティを塗り分けたりするようだ。

卒論で検索UIを作ったのを思い出した。検索すると、検索トピックの関連語を、ばねモデルで散らばして今で言うタグクラウドみたいなのを表示して、クエリ拡張するようなの。Xawで評価プログラムの画面を作った記憶が……。