Skip to content

将棋

自然言語処理系機械学習サービスの日本語対応状況

自然言語処理系機械学習サービスの日本語対応状況 published on 自然言語処理系機械学習サービスの日本語対応状況 へのコメントはまだありません

やりたいこと

やりたいことがあまり具体的になってないけど、機械学習を使った自然言語処理をやりたい。大雑把には、日本語のテキストを入力して、それを分類したり、書き手の感情や性格とかを判別したり、そんなの。

最終的には全部自分で実装したいけど、当面は、既存のもので使えそうなのがあればそれを使おうと思う。

調べたもの

以下のものを調べた。

注意事項

ただ、すべてのものを調べた訳ではない。

  • 自然言語処理関連のもののみ
  • 個人的に興味がないものは調べていない
  • 終了予定のサービスなども調べていない

あと、API として最初からすぐに使えるようになっているものと、トレーニングしなければいけないものなどが混じっている。

誤り等があった場合は、ご指摘等頂ければ、訂正等を行う予定。

Continue reading 自然言語処理系機械学習サービスの日本語対応状況

[書評]ビジネスモデル・ナビゲーター

[書評]ビジネスモデル・ナビゲーター published on [書評]ビジネスモデル・ナビゲーター へのコメントはまだありません

久々の書評。

プログラマー向けに簡単に説明すると、ビジネスモデル版デザインパターン。

それだけだとあんまりなので、もう少し詳しく書く。知ってる人にとっては当たり前なんだけど、イノベーションが全く新規のアイディアであるってのはかなりのレアケースで、実際には既存の考え方の組み合わせだったりすることがかなり多い。本書では、成功企業のビジネスモデルを55種類のパターンとして分類している。

イノベーションを科学的に考えるというのは、関わっているチームゼロイチでもやっていることなので、興味深く読んだ。

PART 1 で、これらのパターンを使ってどうやってビジネスモデルを変革していくかの方法について述べていて、PART 2で実際の55パターンを説明している。

55のパターンは、知っているものも多いけど、説明されてあーなるほどってのもあったり、Pay Per Use と Performance-based Contracting のように、同じだと思っていたのに本質的には違っていたり、というのがあったり、新たな発見は結構ある。

最初に「ビジネスモデル版デザインパターン」って書いたけど、プログラムのデザインパターンと同じで、知っているだけだと意味は無くて、実践を通じて理解を深めていく必要があるのかな、という気がしている。

ということで、「あ、このパターンは使えるかも」ってのは、早速自分の仕事にも取り入れている。さて、結果はどうでるか。

自宅警備員

自宅警備員の仕事術

自宅警備員の仕事術 published on 自宅警備員の仕事術 へのコメントはまだありません

自宅警備員歴が結構長くなったけど、こんな感じで仕事してるってノウハウみたいなのを公開してみる。「こんなやり方もオススメ」みたいなフィードバックがあるといいなーってのが書こうと思ったキッカケなので、皆様のオススメの仕事術も教えて下さいませ。

毎日やってる事

日報

大体朝に書いてる。忙しくてもなるべく書くようにしているので、ここ最近は、ほぼ毎日書けていると思う。

内容、ポイントは以下の通り。

Continue reading 自宅警備員の仕事術

Java (Scala) で言語判定

Java (Scala) で言語判定 published on Java (Scala) で言語判定 へのコメントはまだありません

やりたい事

  • Java (Scala) で、ある文字列が何語(日本語、英語、など)なのかを判別する
  • 入力文字列は以下の2通り
    • ユーザーから入力された検索文字列(1単語、数文字〜数単語、数十文字)
    • 検索対象となる文章(数十単語〜数十ページ程度)
  • 対応する言語
    • 当初は日本語と英語
    • 今後は5言語程度

なぜこれをやりたいかは、以下のエントリーを参照。

Elasticsearch多言語化その2 – K blog

Continue reading Java (Scala) で言語判定

Elasticsearch の nested 型のハイライト

Elasticsearch の nested 型のハイライト published on Elasticsearch の nested 型のハイライト へのコメントはまだありません

本投稿は、一つ前の「Elasticsearch多言語化その2」の補足。

ゴール

やりたい事は、以下のようなフィールドに対する検索結果のハイライトをすること。

  • nested 型で、中身は複数の “attachment” 型
  • attachment 型の “content” フィールドには、content.{ja,en,…} というサブフィールドを作成し、各言語毎の analyzer で処理する

マッピング定義は以下の通り。(elastic4s の DSL をそのままコピペしたが、まぁ大体理解してもらえるかと。)

val messageMapping = mapping("message").fields(
  "title_v3" typed StringType fields(
    "en" typed StringType analyzer "english",
    "ja" typed StringType analyzer "ja_kuromoji_neologd",
  ),
  "body_v3" typed StringType fields(
    "en" typed StringType analyzer "english",
    "ja" typed StringType analyzer "ja_kuromoji_neologd",
  ),
  "attached_files_v3" nested (
    "attached_file" typed AttachmentType fields (
      "content" typed StringType fields(
        "en" typed StringType analyzer "english" termVector ("with_positions_offsets") store (true),
        "ja" typed StringType analyzer "ja_kuromoji_neologd" termVector ("with_positions_offsets") store (true),
      )
    )
  ) includeInRoot (true)
)

環境は以下の通り

  • Elasticsearch 2.3.5
  • Elasticsearch Mapper Attachments プラグインを使用
  • elastic4s というライブラリ経由で Scala から使用

TL; DR

先に結論を書いておくと、以下の2つがうまくいった。

  • nested 型のフィールドに include_in_root を指定し、検索時には通常のクエリーを実行
  • 通常の nested 型のフィールドに対し、nested query を実行し、inner hits でハイライト対象フィールドを指定

どちらの場合も、 “term_vector”: “with_positions_offsets” と “store”: “true” は、attached_file.content.{ja,en} につける。

上手く行かなかったのは以下の方法。

  • nested query を実行し、highlight query でも nested query を実行

以下、詳細に説明していく。

Continue reading Elasticsearch の nested 型のハイライト

国際化

Elasticsearch多言語化その2

Elasticsearch多言語化その2 published on Elasticsearch多言語化その2 への2件のコメント

本投稿は、Elastic stack (Elasticsearch) Advent Calendar 2016 の2日目の記事かつ、以前書いた以下の投稿の続編。

背景等

以前書いた内容と重なる部分もあるが、背景等について説明しておく。

Elasticsearch を、各種開発者向けサービスの横串検索用に使用

GitHub, Slack, Google Drive 等のデータを API 経由で取ってきて、Elasticsearch に入れて、それを横串・一括検索出来るようなツールを作っている。元々は内部向けのツールだったが、ぼちぼち体裁等が整って来たので、現在β版的な感じでひっそり公開中。(今年中にはちゃんと公開したい。)

詳細はこちら → GitHub も、Slack も、まとめて検索 | Commet

検索対象の特性は、メイン言語+英語 or 英語のみ

開発チームまたはプロジェクトが1つの大きな単位で、そのチーム・プロジェクトで使っている GitHub のレポジトリ、Slack のチャンネル、Google Drive のフォルダを指定すると、その配下のデータが Commet 上に取り込まれる。

私の(そして、想定しているターゲット)のユースケースとしては、オフショアを利用していたり、メンバーが多国籍だったりする場合もあるが、使われている言語は、基本的には以下のどちらか。

  • メインとして使われている言語(日本語等)+英語
  • 英語オンリー

環境

  • Elasticsearch 2.3.5
  • elastic4s というライブラリ経由で Scala から使用

Continue reading Elasticsearch多言語化その2

PCの前でアイスを持ってるおっさん

おっさんにとってリモートワークで良かった事

おっさんにとってリモートワークで良かった事 published on おっさんにとってリモートワークで良かった事 へのコメントはまだありません

最近リモートワークが大分普及してきて、メリット・デメリットも色々言われていると思う。他のところで言われてるのと同じような事を書いても仕方ないので、最近気づいた点を1つ書こうと思う。(短文、のはず)

スペック的なもの

  • 40代男性
  • 完全リモートになって、2年位
  • フリーランス
  • 開発がメインの仕事で、パターンは2通り
    • 他社の開発プロジェクトに入って、一開発者として働く
    • プロジェクトを丸々受けて、PL兼開発者として他のフリーの開発者と進める

顔が見えなくて、一呼吸置けるのが良い

見出しだけで内容が分かる人もいるかもしれないけど、少し書いておく。

リモートだと、ビデオチャットで打ち合わせをする時以外は顔を直接合わせる必要がないので、ちょっとムッとくるような事があっても、相手に悟られることもないし、ちょっとお茶でも飲んで落ち着いてから返信することも出来るので、無用な摩擦が減って、個人的には向いている働き方だと思う。

(多分)割と正直な性格なので、何かあるとすぐに顔に出るし、リモートじゃなければ、何か自分の意見と違う事があったらムキになって反論しているかもしれない。

Continue reading おっさんにとってリモートワークで良かった事

stop-arret

Elasticsearch多言語化その1

Elasticsearch多言語化その1 published on Elasticsearch多言語化その1 へのコメントはまだありません

英語でもそこそこの検索結果が出て欲しい

以前、Elasticsearch の analyzer 関連の投稿を書いた。

Elasticsearch の analyzer 関連の設定で知ってることを全て書く

Elasticsearch を何に使っているかなどは、詳しくはそちらを参照してもらうとして、ポイントだけ抜粋しておく。

  • GitHub, Slack, Google Drive, ChatWork, Backlog などからAPI経由でデータを取ってきて、インデックスを作成
  • 言語は、日本語がメインだけど、海外の人とのやりとりや、英語のwebページ(StackOverflowとか)からのコピペもあるので、英語もある程度使われている。

現状は、日本語にのみ対応した設定だけど、英語もそこそこ使われているので、英語の検索結果もそれなりの精度になって欲しい、というのが今回の話。

やったこと: 英語の stemmer を filter として追加

先に結論を書いておくと、使用している analyzer に、”english” と “possessive_english” という2つの stemmer を filter のところに追加した。

設定方法などは、詳しくは以下のページを参照。

Stemmer Token Filter | Elasticsearch Reference [5.0] | Elastic

Continue reading Elasticsearch多言語化その1

国際化

i18n: 言語リソース名の命名規則

i18n: 言語リソース名の命名規則 published on i18n: 言語リソース名の命名規則 へのコメントはまだありません

テキストを多言語化する方法は大まかに2パターン

サイト・webサービスなどのテキストを多言語する方法はいくつかあって、詳細はググってもらうとして、(分類の仕方も色々あるけど)大雑把に以下の2つに分けられると思う。

  • gettext のように、ソースファイルに含まれる翻訳元言語(英語が多い)のテキストを _() や __() といった関数で囲んで、それを抽出して他言語のリソースを作成する
  • Java の ResourceBundle のように、任意の識別子(キー)と多言語対応が必要なテキスト(値)のペアからなるエントリーを含んだリソースファイルを各言語毎に作成し、それを使用する

(言葉で説明すると分かりにくいので、上の説明でピンとこない方は gettext, Java ResourceBundle などで検索してほしい。)

で、今回は後者に関して、キーの命名規則を自分達はこうしてるっていう話を書く。

ネットであまりベストプラクティス的なのが見当たらなかったので、とりあえず今やってる方法を晒して、他の人からの意見とかをもらって改善出来れば良いなあという意図。

Continue reading i18n: 言語リソース名の命名規則

Elasticsearch の analyzer 関連の設定で知ってることを全て書く

Elasticsearch の analyzer 関連の設定で知ってることを全て書く published on Elasticsearch の analyzer 関連の設定で知ってることを全て書く へのコメントはまだありません

詳しい人から見れば大した内容じゃないと思うけど、調べたり試行錯誤した結果をまとめる。(間違いなどがあれば、ご指摘頂けるとありがたいです。)

Elasticsearch を何に使っているか

他サービス → API/webhook → 自サーバーの Elasticsearch

以前触れたと思うけど、開発プロジェクトのデータを全部1箇所にまとめて検索出来るようにしていて、そこで Elasticsearch を使っている。

自分の仕事内容としては、時間の4割位を受託開発にあてている。受託開発では、お客様や発注元の開発ベンダーに合わせて色んなツールを使わざるを得なくて、具体的には ChatWork, Backlog, Google Drive とかを使うことが結構多い。それに対して、自分達の開発チーム内部では自分達用のSlackチームがあるし、それ以外にも別のツールを使ってたりしているので、色んなところに情報が分散しがち。

なので、各ツールのAPI(あるいはwebhook)経由で自分達のサーバーにデータを送って、それを Elasticsearch に流し込んでいる。

検索対象

元データの種類は以下の通り。

  • テキスト
    • GitHub/Bitbucket/Backlog の issue (チケット), PR での議論
    • Slack, ChatWork の会話
    • wiki ページ
  • ファイル
    • Backlog のファイル置き場にあるファイル
    • Google Drive のファイル
    • Slack に貼られたファイル

言語は、日本語がメインだけど、海外の人とのやりとりや、英語のwebページ(StackOverflowとか)からのコピペもあるので、英語もある程度使われている。

Continue reading Elasticsearch の analyzer 関連の設定で知ってることを全て書く