タグ

Programmingとnlpに関するyokochieのブックマーク (23)

  • iOSDCで自然言語処理の話をしてきました #iosdc - とりあえずやってみればいいじゃん

    iOSのカンファレンスなのに自然言語処理(以下、Natural Language Processingの略語であるNLPを使います)に比重を置いた話をしてきました。登壇内容はスライドと後日公開されるビデオ見ればわかると思うのでここでは裏話的な話を。 iosdc.jp なぜこのCfPを出したのか 「NLPが好きだから」「NLPを再び勉強するきっかけが欲しかったから」「NLPの面白さを知ってもらいたい」とかそんなかんじです。 スライドにもちらっと書いてますが、私とNLPとの付き合いは大学時代まで遡ります。意味不明な計算出て来るし、変な解析結果が返ってくることもあって「なんじゃお前」と思ったこともありましたが、次第にその奥深さが好きになっていきました。ただ、私が好きなNLPというやつはとっつきづらい印象を持たれがちだと思うんです。きっと用語がいけない。ちょっとNLPに関する用語を並べてみましょう

    iOSDCで自然言語処理の話をしてきました #iosdc - とりあえずやってみればいいじゃん
    yokochie
    yokochie 2017/09/22
    これ聞きたかったんですけど遅れて見られなかった…
  • Budou - 機械学習を用いた日本語改行問題へのソリューション - ウェブ雑記

    こんにちは! 日語のウェブサイトを作っていると、日語特有の問題にぶちあたることがありますよね。 その中でも今回着目したいのは、日語改行問題。最近、この問題を解決するためのライブラリを公開したので、紹介します。 github.com そもそも日語改行問題とは何か ウェブブラウザで日語で書かれたウェブサイトを見ていると、ときどき文章が変なところで改行されているのを目にすることがありますよね。 たとえば、こんなかんじ。 「ソリューション」が「ソリューショ」と「ン」に分かれてしまっています。読みにくいですね。 英語では単語がスペースによって区切られますが、日語や中国語などのアジア圏の言語では単語がスペースで区切られないことが多いです。 そのため、英語では単語の途中で改行されることは通常ありませんが、日語では単語の途中で改行されることがよくあります。 文ならともかく、見出しやキャッチ

    Budou - 機械学習を用いた日本語改行問題へのソリューション - ウェブ雑記
  • Amazon CAPTCHA

    Amazon CAPTCHA
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • marisa-trieを使ってみた - nokunoの日記

    id:s-yata さんの新作trieライブラリが公開されていたので使ってみました。環境はMac OS Xです。やた@はてな日記 marisa-trie - Project Hosting on Google Code インストール普通にGoogle Codeからダウンロードしてインストールします。 $ wget http://marisa-trie.googlecode.com/files/marisa-0.0.1.tar.gz $ tar xfz marisa-0.0.1.tar.gz $ cd marisa-0.0.1/ $ ./configure $ make $ sudo make install 動作確認Wikipedia N-gram(nokunoの日記)よりbigramを格納し、marisa-predictによって前方一致検索を行いました。 $ cat bigram.txt

  • オープンソースのTrieライブラリまとめ - nokunoの日記

    最近、趣味で開発しているStaKKのためにTrieライブラリを書いているのですが、参考にするためオープンソースのTrieライブラリについて調べました。簡潔データ構造を用いたものが中心です。 @hillbig氏によるもの tx LOUDSによる圧縮でメモリ使用量を削減したTrieライブラリ。 関連記事:Tx: Succinct Trie Data Structure Engineering the LOUDS Succinct Tree Representation - 射撃しつつ前転ux txの改良版。tailの圧縮によりtxの1/2くらいのサイズになるらしい。要チェック。 関連記事:ux... - ny23の日記id:s-yata 氏によるもの taiju LOUDSを含む簡潔データ構造を用いた大規模Trieライブラリ。sumire-triesインメモリの簡潔データ構造を実装した大規模T

  • perlで高速な類似検索エンジンを構築できるようにしてみた - download_takeshi’s diary

    すみません。タイトルはやや釣り気味です。 類似検索エンジンというか、そのアイデア程度の話なんですが、以前から考えていた類似検索エンジン風のネタがあったので、ちょっとperlで書いてみたので、そいつを晒してみます。 Luigi   https://github.com/miki/Luigi 類似検索なのでLuigi。ルイージとか読みたい人はそう読んじゃっても良いです。(冷) 考え方と仕組み 類似文書の検索、となりますと一般的には超高次元での空間インデックスとかが必要になります。 昔からR-TreeやSR-Treeなど、いろいろと提案されていますが、より高次元になると「次元の呪い」によりパフォーマンスが出なくなる、なんて言われていますね。 そこで最近ではLSHに代表されるような、より高度な「近似」型のインデキシング手法が人気を集めているようです。 で、今回考えたLuigiも実は近似型のインデッ

    perlで高速な類似検索エンジンを構築できるようにしてみた - download_takeshi’s diary
  • Python による日本語自然言語処理

    はじめに この文書は、 Steven Bird, Ewan Klein, Edward Loper 著 萩原 正人、中山 敬広、水野 貴明 訳 『入門 自然言語処理』 O'Reilly Japan, 2010. の第12章「Python による日語自然言語処理」を、原書 Natural Language Processing with Python と同じ Creative Commons Attribution Noncommercial No Derivative Works 3.0 US License の下で公開するものです。 原書では主に英語を対象とした自然言語処理を取り扱っています。内容や考え方の多くは言語に依存しないものではありますが、単語の分かち書きをしない点や統語構造等の違いから、日語を対象とする場合、いくつか気をつけなければいけない点があります。日語を扱う場合にも

  • 定兼 邦彦 (Kunihiko Sadakane) - 圧縮接尾辞配列ライブラリ - researchmap

    文字列を圧縮したまま検索するライブラリです. 文字列の一部を高速に復元することもできます. 圧縮接尾辞配列ライブラリ (2010-08-10版) Direct BWT construction External Memory BWT construction http://code.google.com/p/csalib/ にもあります. 注意: dbwt100717.zipにはバグがありました.Ubuntuでは動かない可能性が高いです. dbwt100730.zipを使ってください. 索引とは,の索引と同じ意味で,検索を高速に行うためのデータのことです. ただし,の索引では代表的な言葉のみが登録されていますが,このライブラリの索引は 任意の語が検索できるようになっています. このライブラリの索引は自己索引 (self-index) と呼ばれるもので,索引自体に 元のファイルの情報を全

  • Hadoopを使わずにWikipediaのテキスト処理を400倍高速化 - tsubosakaの日記

    タイトルは釣りです。id:mamorukさんの書いたHadoop で Wikipedia のテキスト処理を900倍高速化 - 武蔵野日記を読んで、そもそも1G程度のデータの単語頻度を数えるのに858分もかかるんだっけと思い、id:nokunoさんの資料を読んでみると単語頻度を求める際に a b a aみたいなデータを a 3 b 1に変形するのにsortしたファイルをuniq -cで処理するということをやっていた。これはあまり効率のよい方法ではなくて行数をNとしたときにO(N log N)の計算時間となる(文字列比較はO(1)でやれることにする)。 これに対して、単語の頻度をハッシュ表で保存すると理想的な条件の元ではO(N)の計算時間で頻度を求めることが出来、より高速に計算することが可能となることが期待される。 また、単語数をWとしたとき、C++mapのような二分探索木を使ってもO(N

    Hadoopを使わずにWikipediaのテキスト処理を400倍高速化 - tsubosakaの日記
  • Não Aqui! » SimString (類似文字列検索ライブラリ) 1.0 released

    SimStringという類似文字列検索ライブラリをBSDライセンスでリリースしました.類似文字列検索とは,文字列集合(データベース)の中から,クエリ文字列と似ているものを見つけ出す処理です.コンピュータは,正確に一致する文字列を探すのは得意ですが,表記揺れに出くわすと,途端に対応できなくなります.例えば,「スパゲティ」に対して,レストラン情報などを返すサービスにおいて,「スパゲッティ」や「スパゲティー」などの表記揺れが検索クエリに与えられると,通常のデータベースでは情報を提示することが出来ません.類似文字列検索を用いると,表記揺れが検索クエリに与えられても,「スパゲティ」という既知語を代替クエリとして提案したり,「スパゲティ」の情報をダイレクトに引き出すことができるようになります. 似てる語を探す技術って,文字列処理の基中の基で,自然言語処理では当たり前のように使われていてもおかしくな

  • MeCabのコマンドライン引数一覧とその実行例 | mwSoft

    -r --rcfile 使用するリソースファイルを指定する リソースファイルとは、辞書ディレクトリに入っている「dicrc」ファイルを指します。 試しにシステム辞書の「dicrc」ファイルをコピーして、「dicrc2」というファイルを作り、その中の「; simple」の「EOS」を「eos」に書き換えます。するとこんな風になります。 // リソースを指定せずに実行 $ echo テスト | mecab -O simple テスト 名詞-サ変接続 EOS // リソースを改変したdic2に指定して実行 $ echo テスト | mecab -r dicrc2 -O simple -d /usr/local/lib/mecab/dic/naist-jdic テスト 名詞-サ変接続 eos 我が家の環境では、システム辞書ディレクトリをカレントディレクトリとした状態にするか、「-d」でシステム辞書

  • 軽量データクラスタリングツールbayon - mixi engineer blog

    逆転検事を先日クリアして、久しぶりに逆転裁判1〜3をやり直そうか迷い中のfujisawaです。シンプルなデータクラスタリングツールを作成しましたので、そのご紹介をさせていただきます。 クラスタリングとは クラスタリングとは、対象のデータ集合中で似ているもの同士をまとめて、いくつかのグループにデータ集合を分割することです。データマイニングや統計分析などでよく利用され、データ集合の傾向を調べたいときなどに役に立ちます。 例えば下図の例ですと、当初はデータがゴチャゴチャと混ざっていてよく分からなかったのですが、クラスタリングすることで、実際は3つのグループのデータのみから構成されていることが分かります。 様々なクラスタリング手法がこれまでに提案されていますが、有名なところではK-means法などが挙げられます。ここでは詳細については触れませんが、クラスタリングについてより詳しく知りたい方は以下の

    軽量データクラスタリングツールbayon - mixi engineer blog
  • Webstemmer(クローラーツール)

    語サイトでは、具体的な性能は測定していませんが、 以下のようなサイトで正しく動くことがわかっています: アサヒ・コム Nikkei NET Mainichi INTERACTIVE Yomiuri On-line IT media 東京新聞 日刊スポーツ 信濃毎日新聞 livedoor ニュース 使いかた Webstemmer をつかったテキスト抽出は以下のようなステップになります: まず、特定のニュースサイトから種となる HTML ページを多数取得する。 取得したページのレイアウトを学習する。 別の日に、同一のニュースサイトから新しい HTML ページを取得する。 2. で学習した結果をつかって、新しい HTML ページから文を抽出する。 1. および 2. のステップが必要なのは最初の 1回だけです。 ひとたびサイトのレイアウトを学習してしまえば、 あとはレイアウトが大きく変更さ

  • 自然言語処理は Python がいちばん - 武蔵野日記

    現在大学1年生の人で3年後には NAIST に (というか松研に) 来たいという人から「どんなプログラミング言語やっておくといいですか」と質問されたりするのだが、なかなか答えるのは難しい。自分は PerlPython がメインでときどき C++/C# を使ったりするのだが、どれが一番いいかはなんとも言えないので、自然言語処理以外に転向する可能性も考えると、C とか C++ とか Java とか(授業でそちらをやるのであれば)を最初の武器に選んだ方がいいのでは、と思ってはいる。 そんなこんなで最近 Hal Daume III (機械学習を用いた自然言語処理では非常に有名な人) のブログで Language of Choice というタイムリーなエントリーが出ていたので、紹介すると、「それなりに大きな自然言語処理のプロジェクトでどのプログラミング言語を使うのか」というアンケート結果が出

    自然言語処理は Python がいちばん - 武蔵野日記
  • 編集距離 (Levenshtein Distance) - naoyaのはてなダイアリー

    昨日 最長共通部分列問題 (LCS) について触れました。ついでなので編集距離のアルゴリズムについても整理してみます。 編集距離 (レーベンシュタイン距離, Levenshtein Distance) は二つの文字列の類似度 (異なり具合) を定量化するための数値です。文字の挿入/削除/置換で一方を他方に変形するための最小手順回数を数えたものが編集距離です。 例えば 伊藤直哉と伊藤直也 … 編集距離 1 伊藤直と伊藤直也 … 編集距離 1 佐藤直哉と伊藤直也 … 編集距離 2 佐藤B作と伊藤直也 … 編集距離 3 という具合です。 編集距離はスペルミスを修正するプログラムや、近似文字列照合 (検索対象の文書から入力文字にある程度近い部分文字列を探し出す全文検索) などで利用されます。 編集距離算出は動的計画法 (Dynamic Programming, DP) で計算することができることが

    編集距離 (Levenshtein Distance) - naoyaのはてなダイアリー
  • 第11回 Kansai.pm / スペルミス修正プログラムを作ろう - naoyaのはてなダイアリー

    昨日は第11回 Kansai.pm でした。 今回は無理を言って自分がホストを担当させていただきましたが、面白い発表が多く開催した自分も非常に満足でした。 PFI の吉田さんによる Cell Challenge での計算機に合わせたアルゴリズムのチューニング手法の発表 (発表資料) は圧巻でした。伊奈さんの文抽出の話 (発表資料)、はこべさんのコルーチンの話 (発表資料)、いずれも難解になりがちなところを凄く分かりやすく解説されていて、さすがだなと思いました。各々ショートトークも、いずれも良かったです。 スペルミス修正プログラムを作ろう 自分も 20 分ほど時間をいただいて、スペルミス修正プログラムの作り方について発表しました。 スペルミス修正プログラムを作ろうView more presentations from Naoya Ito. スペルミス修正プログラムについてはずばり スペル

    第11回 Kansai.pm / スペルミス修正プログラムを作ろう - naoyaのはてなダイアリー
  • スペル修正プログラムはどう書くか

    Peter Norvig / 青木靖 訳 先週、2人の友人(ディーンとビル)がそれぞれ別個にGoogleが極めて早く正確にスペル修正できるのには驚くばかりだと私に言った。たとえば speling のような語でGoogleを検索すると、0.1秒くらいで答えが返ってきて、もしかして: spelling じゃないかと言ってくる(YahooMicrosoftのものにも同様の機能がある)。ディーンとビルが高い実績を持ったエンジニアであり数学者であることを思えば、スペル修正のような統計的言語処理についてもっと知っていて良さそうなものなのにと私は驚いた。しかし彼らは知らなかった。よく考えてみれば、 別に彼らが知っているべき理由はないのだった。 間違っていたのは彼らの知識ではなく、私の仮定の方だ。 このことについてちゃんとした説明を書いておけば、彼らばかりでなく多くの人に有益かもしれない。Google

  • Latent Semantic Indexing - naoyaのはてなダイアリー

    情報検索におけるベクトル空間モデルでは、文書をベクトルとみなして線形空間でそれを扱います。この文書ベクトルは、文書に含まれる単語の出現頻度などを成分に取ります。結果、以下のような単語文書行列 (term document matrix) が得られます。 d1 d2 d3 d4 Apple 3 0 0 0 Linux 0 1 0 1 MacOSX 2 0 0 0 Perl 0 1 0 0 Ruby 0 1 0 3 この単語文書行列に対して内積による類似度などの計算を行って、情報要求に適合する文書を探すのがベクトル空間モデルによる検索モデルです。 見ての通り、単語文書行列の次元数は索引語の総数です。文書が増えれば増えるほど次元は増加する傾向にあります。例えば索引語が100万語あって検索対象の文書が 1,000万件あると、100万次元 * 1,000万という大きさの行列を扱うことになりますが、単

    Latent Semantic Indexing - naoyaのはてなダイアリー
  • チームラボ / teamLab

    森ビル デジタルアート ミュージアム:エプソン チームラボボーダレス Feb 09, 2024 - 麻布台ヒルズ、東京 NOW OPEN

    チームラボ / teamLab