@johtaniの日記 3rd

カンファレンスの録画をGemini Notebookを使ってチェックする

Tue, 04 Aug 2026 07:54:42 +0000

6月の話だったのですが、今年もBerlin Buzzwordsにオンラインで参加していました。検索に関する話題が多めの毎年ベルリンで開催されているカンファレンスです。

カンファレンスが終わってすぐに、録画がYouTubeにプレイリストとしてアップもされています。うれしいことに、トラックが複数あるため参加中にすべてのセッションを聞けるわけではありません。

ただ、録画すべてを見るのも大変です。カンファレンスのページにセッション概要やタイトルも掲載されていますが、どのセッションが自分の興味に合いそうか？を探すのもある程度大変ですよね。とくにBerlin Buzzwordsは検索だけではなく、そのほかの技術に関する話題もありセッション数が多いです。

ですので今年は、YouTubeのプレイリストをもとに、Gemini Notebook（旧NotebookLM）を利用してYouTubeの録画をもとに一覧を作ってみました。実際に作ったリストは検索技術勉強会でも紹介しているSlackにも投稿したのですが、こんな感じで作ったというのを来年の自分のために残しておきます。

検索に関するSlackへのリンクはこちら。

検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff
— takuya-a (@takuya_b) March 31, 2021

作業手順

作業手順といっても簡単です。

YouTubeのプレイリストから、各セッションの録画へのリンクの一覧を作る
リンクの一覧をGemini Notebookのソースに入力
一覧からプロンプトで資料を作ってもらう

という指示で出来上がったのが、次のようなMarkdownの資料です。最初の2行のリンクや動画へのリンクは個別に修正したりしてますが、メモの中身はこの作業で出来上がったものです。

Berlin Buzzwords 2026メモ

リンクの一覧

最初はプレイリストのリンクを1つだけ渡して指示を出してみたのですが、どうやら個別の動画ではなくプレイリストにあるタイトルだけをもとに概要などを作るようでした。なので、実際に話した内容とはすこし異なるものが出てきました。プレイリストからURLの一覧を作るのは手でやってもいいですし、スクリプトを組んだりもできるかなと。

ソースの入力

Gemini Notebookのソースには、1で作ったURLを改行区切り下リストを渡すだけでOKです。 Gemini Notebookの左側にソースとしてYouTubeのアイコンで始まるセッションがならびます。次のプロンプトを実行するタイミングでは、すべて選択した状態にしておきます。

プロンプト

最後は次のようなプロンプトを使いました。Berlin Buzzwordsでは検索以外のトピックもあるので、判別できるような指示を入れてあります。

それぞれの動画に関して解説を作ってください。5行程度の説明文と10個程度のトピックとなるキーワードをお願いします。出力形式はMarkdownで、それぞれの動画へのリンクもつけてください。少なくとも検索関するトピックかどうかがわかるようにキーワードを必ず付与するようにしてください。

これで先ほどのMarkdownの説明が出来上がりです。これをもとに、気になるセッションから録画を見ていくことができて便利でした。 Gemini NotebookからYouTubeのリンクもたどれますし。

Gemini Notebookで作る便利な点

さらに、Gemini Notebookを使っていて便利だったのは、この後セッションを見ながら、個別のセッションについて質問したりもできる点です。見ているセッションだけをソースでチェックを入れた状態で質問をしていくと、どんなことをしゃべっているのか？という深堀もできます。

おまけ

Berlin Buzzwords以外にも海外で検索に関連するカンファレンスの動画がアップされています。海外の企業がどんな検索で困っているのか？今どんなことがはやっているのか？というのをチェックするのに便利です。ということで、5月に開催されていたHaystack US 2026やBerlin Buzzwordsと同じ週に開催されていたMICES 2026についてもメモを作っていたので、こちらもリンクを置いておきます。

ほかにもこんなカンファレンスがあるよ、こんな録画があったよなどあれば、共有してもらえると嬉しいです！

プレゼン公開をブログの仕組みに含めるようにした話

Fri, 31 Jul 2026 07:54:20 +0000

全然ブログ書いてなかったですね。。。

2月にやってた内容なんですが、忘れないように書き残しておこうかなと。プレゼンの公開には、noti.stを使っていました。

そんなところに元同僚がこんなブログを書いてました。

🎂 13 years： Migrating my speaker page with AI | David Pilato

おなじく、noti.stを使っていたのですが、コーディングエージェントを使って作業して、自分のブログに移行したと。

noti.stは有料サービスなんですが、最近あまり外向けでしゃべることもなくなっているのにサブスクしてました。コーディングエージェントを触ってみるいい機会になりそうだな？というのもあって、自分もチャレンジしてみることに。

実際に出来上がったプレゼンの一覧はこちらです。

私のブログサイトはHugoを使ってビルドしたものをGitHub Pagesで公開しています。今回Claude Codeに作ってもらったのは次のようなものです。

noti.stからPDFをダウンロードしてHugo用のmdファイルを作るスクリプト
PDFからスライドコンテンツからHugo用のmdファイルを作るスクリプト
SpeakerDeckに公開しているスライドをiframe embedのHugo用mdファイルを作るスクリプト

それぞれがPythonスクリプトになっています。また、Hugo向けにpresentationというパスでスライドを公開するためのテンプレートなども作ってもらいました。

noti.stのスライドたち

noti.stにPDFでアップロードしていました。ダウンロードもできるようになっています。また、noti.stにはいつのスライドで、どのイベントでしゃべったのか？スライドの簡単な概要なども入力してあります。

ということで、スライドのタイトル、日付をダウンロード時に取得してプレゼンページのパスやタイトルに利用できるようにしてもらいました。また、スライドを作るときにはリンクなどを埋め込んでいるのですが、PDFにもこの情報が入っています。これらも抜き出して、スライドを表示するページに参考リンクとして表示できるようにしてあります。

PDFから画像としてスライドを1枚ずつ抜き出しつつ、pngに変換したものを生成しています。画像ファイルはそれなりの枚数でサイズも大きくなるため、スライドのPDFと画像ファイルだけGit LFSで管理する形にしてもらっています。

スライドの公開ページでは、ページめくりのタイプのビューアと一覧ですべてのスライドを閲覧できる2種類を作ってあります。コーディングエージェントにお願いすればやってくれるの本当に助かりますよね。。。 Git LFSの操作もやってくれるし。

今後のスライド用に処理の切り出し

また、今後もスライドを作って公開する場合はPDFで作成する予定です。ということで、noti.stの処理のPDFから生成するところだけを切り出したスクリプトも作ってもらいました。この仕組みに変更した後にスライドを作るタイミングがないためまだこれを試してはいないですが。。。

SpeakerDeckはiframe embed

せっかくなので、SpeakerDeckで公開しているスライドも掲載してしまおうと思い相談したところ、 SpeakerDeckはiframe embedで取り込むことができそうだということで、PDFから生成するのではない形にしてもらいました。

なので、古いスライドのページについてはビューアがちょっとおしゃれです。

まとめ

2月にやってた作業についてメモを残す程度に思い出しながら書いてみました。最初はClaude Codeと壁打ちをしながらどうするのがいいかというのを詰めていき、大体まとまったところで、Issueを作ってそれをもとに作業をやってもらう形でやっています。いったんページめくりのものが出来上がってから、参考リンクを抜き出してみたり、一覧の仕組みも追加してもらったりしました。

忘れないように、作ったスクリプトやディレクトリ構成、Git LFSなどに関してはメモを作ってもらっています（すごい便利）。ちなみに、プレゼンページを作る前に、Hugoの環境をdevcontainer化してほかの環境でも楽に再現できるようにしたり、Hugoのバージョンやテーマの最新化などもやっていました。気が向いたらその辺も書くかも？（たぶん書かない。。。）

今年の振り返りと来年の抱負（2025）

Wed, 31 Dec 2025 11:07:18 +0000

家族でカタンやったけど勝てない。。。ってことで、毎年恒例の紅白見つつブログです。

振り返り（2024年に書いた抱負から）

まずは振り返りです。

フリーランス継続

今年も無事フリーランスとして終えられました。継続していただいているお客さんのおかげで助けられてます。今年は、調べものにGeminiやChatGPTを使いつつという感じです。最近の検索システムの流れなどを調べたりというのが便利にできています。ちょっとだけ海外のお手伝いもできました。

プログラミング継続

夏ごろまではAtCoderを続けていたのですが、体調を崩したタイミングで休止しています。あとは、自分がプログラミングというよりは、Amazon Qを利用してプログラミングをしてもらっています。翻訳とかの小ネタ用のプログラミングもやってたりします。 AtCoderではGoを使っていますが、LLM活用となるとPythonをさわることが増えてる気がするなぁ。

Weaviateをもと触る

こちらは勉強会用のグループを作ったけど、うまく回せてないです。ただ、Weaviateをバックエンドにしながら時分用の備忘録用のツールをAmazon Qと書いています。もうちょっといろいろと使い勝手とか考えたほうがいいんだけどなぁ。

本を読んだブログを書く？

本はちょっとずつ読んでるんですが、ブログはかけてないですね。。。とりあえず、本を読むだけじゃなく、簡単な感想を書けるように自分用のSlackでメモを取る仕組みは作ってあり、読んだところのコメントをちょっとずつは書いています。それをまとめてないだけです。。。

あとは、友人と輪読してる本については簡単にまとめました。

今年の輪読会で読んだ本 | @johtaniの日記 3rd | @johtani’s blog 3rd edition

勉強会の録画をマスターする？

これは、大失敗でしたよ。。。

悲報。録画ボタン押し忘れるという大ポカをやってしまいました、、、スライドは順次公開していただいているのでリンクを見つけては資料の一覧に貼り付けていきます。すみませんでした！ https://t.co/ymtNSnAj15
— Jun Ohtani (@johtani) October 31, 2025

1月末にやる勉強会ではリベンジします！応援してて。。。あと、会場で気づいた人は声かけて。。。

振り返り（今年あった出来事）

ゲーム

ゲームも夏に体調を崩してからはちょっと抑え気味でした。

産業キャプテン
デス・ストランディング2（クリア）
ゴースト・オブ・ヨーテイ（クリア）

産業キャプテンは原子力発電作ったところくらいで止まってる。。。ロケット打ち上げできるんだろうか？？

プラモデル

仕事を始める前に説明書の1コマ分を組み立てるという習慣を続ける思考を読んでから続けています。

今年はRGのガンダムVer.2.0、RGのバンシィ・ノルンを作って、今はRGのフルアーマーユニコーンを作ってるとこです。ユニコーン、パーツが多いので、春くらいかもなぁ完成は。

仕事

今年も家で仕事してました。オンラインで仕事させてもらえるの本当にいい（運動不足だが）。夏に体調を崩したけども、家でオンラインで仕事ができるのでそれほど迷惑をかけずに済んだのは本当に良かった（だいぶ復調しました）。

メインPCは昨年組み立てたんだけど、サーバーに使っていたDesk Miniが５月後半に電源が入らなくなったので、MinisforumのAI X1に急遽買い換えました。前よりも小さくなったけども、性能よくなったしSSDは生きていたので、データの移植は簡単に終わって致命傷にならずに済みました。

今ではローカルLLMをllm-swapで動かしたりもしています。便利。Plamoの翻訳用LLMとかも動かせてすごく便利です。以下のブログを参考にさせてもらいました。

ローカルLLMをEVO X2でホストする方法まとめ – さくらんぼの技術備忘録

勉強会

年4回のペース絵勉強会をやりたかったのですが、2回のみ（2月と10月）となってしまいました。

10月の勉強会では10分セッションのみで開催を予告してからスピーカーを募集してみました。 25分のセッションよりも集まりがよい気がしたので、10分のセッションを毎回盛り込みたいなと考えています。また、定期開催したいので、開催日をほぼ固定して早めに告知しつつスピーカーを募集する形に変えてみようかなと考えています。まずは、1月末に予定です。そのあとはうまくいけば4月、7月、10月とやりたいなと。

Search Engineering Tech Talk 2026 Winter - connpass

来年の抱負

さて、最後は来年の豊富です。

フリーランス継続
プログラミング継続
新しいプロダクトを触る
本を読んだブログを書く？
勉強会を4回開催＋録画をマスターする？
産業キャプテンのロケット打ち上げ
なんか新しいことを始める

安定してフリーランスの仕事をいただけているので本当にありがとうございます。ちょいちょい新しいことも調べたりできているし。

プログラミングは今年と同じ感じでAmazon Qを使いつつ続けていければなと。作りたいものをサクっと作れるのはほんと便利になったなぁ。こんなの作りたいなぁって思いながら重い腰が上がらなかったけどその障壁が低くなってるのは楽しいですね。

OpenSearchを触ったり調べたりはしているんですが、Elasticsearchの系統ではあるのでもう少し違うものも触っていきたいなぁと。最近はオブジェクトストレージを経由する検索エンジンなども増えてきているので、そのあたりの仕組みを調べつつ触っていくのがよさそうかなぁ。

読書はコメントを残しているのをちょっとだけまとめてブログにする習慣づけが必要かな。

勉強会4回開催のために、日付をほぼ決め打ち（上に書いた月末に開催できるように場所を交渉）してスピーカーを募集しつつ集まらなかったらアンカンファレンスか懇親会のみで会場で話したい人を募集する感じにしたいな。録画は。。。ワイヤレスマイクまで買ったので絶対やります。。。あと、録画とかのノウハウある人と話したいなぁ。今は、スピーカーの方にGoogle Meetに接続してもらってから録画している感じです。

産業キャプテンはまぁ、がんばります。イージーモード？でやってるので、鉄道のモチベーションが出てこないのがちょっとあれだけど。ロケット発射台はできてるので、ロケット用の材料をコツコツ作っていくだけだから。。。

50歳になったし、これまでやってないことも始めたいなぁと考え中です。楽器かなぁ？サイレントでできるような楽器か、デジタル音楽かもっと他のものか。来年の年末ブログで何を始めたか紹介できればなぁと。

さて、back numberを聞きながら締めをと。

ということで、今年もあと少しというところでブログが書き終わった。来年は体調に気を付けつつ、ちょっとずつ外に出かけるようにしようと。来年もよろしくお願いいたします、よいお年をー

Named Queryとスコア

Fri, 19 Dec 2025 08:26:56 +0000

この記事はElastic Stack (Elasticsearch) Advent Calendar 2025の19日目の記事になります。

なんとなく思い立ったので、Named Queryのことでも書いてみようかな。

named queryとは？

ElasticsearchのBoolクエリを書いていて、条件が複数ある場合にどの条件が検索結果に出てきたドキュメントに影響があるのか？というのを知りたくなることがあります。

例えば、タイトルと説明文に検索するようなBoolクエリを書いてみます。

GET esci-sample/_search
{
  "query": {
    "bool": {
      "should":[
        {
          "match": {
            "product_title": "ライトニングケーブル"
          }
        },
        {
          "match": {
            "product_description": "ライトニングケーブル"
          }
        }
      ]
    }
  },
  "_source": ["product_title"]
}

取得できるのはこういうデータです（説明文は長いので省いています）。ヒットしているデータはわかりますが、どっちの条件がヒットしてるのか？というのはスコアから想像するとわかるような気もしますが、難しいです。

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 4,
      "relation": "eq"
    },
    "max_score": 3.4320617,
    "hits": [
      {
        "_index": "esci-sample",
        "_id": "B07RJQJDY1",
        "_score": 3.4320617,
        "_source": {
          "product_title": "ライトニングケーブル Type-Cケーブル Micro USB ケーブル 3in1 充電ケーブル 3A急速充電 データ転送 高耐久編組ナイロン USB Type C/ライトニング/Micro USB iOS / Androidに多機種対応1.2m (ブラック)"
        }
      },
      {
        "_index": "esci-sample",
        "_id": "B086HNZN58",
        "_score": 2.949997,
        "_ignored": [
          "product_bullet_point.keyword"
        ],
        "_source": {
          "product_title": "Allroundo® ライトニングケーブル 伸縮式 3in1 充電ケーブル 1.8A急速充電 高速データ転送 USB Type-C/Lightning/MicroUSB 多機種対応 高耐久 断線防止 絡み防止 持ち運びに便利 収納ボックス付き"
        }
      },
      {
        "_index": "esci-sample",
        "_id": "B0829TWWMM",
        "_score": 2.697413,
        "_ignored": [
          "product_bullet_point.keyword"
        ],
        "_source": {
          "product_title": "ライトニングケーブル 3in1 巻き取り 充電ケーブル 3in1 3A 急速充電 高速データ転送（ios） USB Type-C/ライトニング/Micro USB 充電ケーブル 一本三役 iOS/Android 同時給電可能 iPhone/Galaxy/Huawei/Macbook等全機種対応 120cm 1年間品質保証 (ブラック)"
        }
      },
      {
        "_index": "esci-sample",
        "_id": "B08913D1SL",
        "_score": 2.5449233,
        "_ignored": [
          "product_bullet_point.keyword",
          "product_description.keyword"
        ],
        "_source": {
          "product_title": "【Quick Charge 3.0】Amuvec 車載充電器 USB2ポートカーチャージャー シガーソケットチャージャ しがらいたーソケット usb 急速充電（6A/40W) LightningとタイプCデュアル80cm 巻取り式ケーブル ために iPhone XS/ Max/ XR/ X/ 8 /7/ 6/ Plus /Galaxy S9/ S8/ Note 8 LG V30 Google Pixel 2 XL/SamSung 対応 (赤) …"
        }
      }
    ]
  }
}

そういう時に便利な機能としてNamed Queryと呼ばれるものがあります。

Boolean query | Reference

クエリに名前を付けることができる機能で、さらにその名前が検索結果に帰ってくるようになります。


GET esci-sample/_search
{
  "query": {
    "bool": {
      "should":[
        {
          "match": {
            "product_title": {
              "query": "ライトニングケーブル",
              "_name": "match_title"
            }
          }
        },
        {
          "match": {
            "product_description": {
              "query": "ライトニングケーブル",
              "_name": "match_description"
            }
          }
        }
      ]
    }
  },
  "_source": false
}

matchのクエリの書き方が少し変わっていて、フィールド名のあとがオブジェクトになっています（_nameもこの中に指定するため）。この中に、_nameというのがNamed Queryになります。クエリの結果が次のようになります（titleが長いので、省いちゃいます）。

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 4,
      "relation": "eq"
    },
    "max_score": 3.4320617,
    "hits": [
      {
        "_index": "esci-sample",
        "_id": "B07RJQJDY1",
        "_score": 3.4320617,
        "matched_queries": [
          "match_title"
        ]
      },
      {
        "_index": "esci-sample",
        "_id": "B086HNZN58",
        "_score": 2.949997,
        "_ignored": [
          "product_bullet_point.keyword"
        ],
        "matched_queries": [
          "match_title"
        ]
      },
      {
        "_index": "esci-sample",
        "_id": "B0829TWWMM",
        "_score": 2.697413,
        "_ignored": [
          "product_bullet_point.keyword"
        ],
        "matched_queries": [
          "match_title"
        ]
      },
      {
        "_index": "esci-sample",
        "_id": "B08913D1SL",
        "_score": 2.5449233,
        "_ignored": [
          "product_bullet_point.keyword",
          "product_description.keyword"
        ],
        "matched_queries": [
          "match_description"
        ]
      }
    ]
  }
}

結果を見ていただくと、各ドキュメントにmatched_queriesという属性が増えています。ここに、ヒットしたクエリの名前が入るようになります。今回の検索結果の場合、3件目まではタイトルにヒットしていますが、4件目は説明文にヒットしていることがわかります。

じゃあ、スコアは？

ここまではどの条件が検索結果に関係があったかどうか？だけがわかる仕組みでした。 Elasticsearchの8.8から更なるオプションとしてinclude_named_queries_scoreが追加されました（追加の時のPRはこちら）。

_searchエンドポイントのクエリパラメータとして（URLの一部）指定します（効果をわかりやすくするために、上記のクエリとは文字列を変えています）。

GET esci-sample/_search?include_named_queries_score=true
{
  "query": {
    "bool": {
      "should":[
        {
          "match": {
            "product_title": {
              "query": "USBケーブル",
              "_name": "match_title"
            }
          }
        },
        {
          "match": {
            "product_description": {
              "query": "USBケーブル",
              "_name": "match_description"
            }
          }
        }
      ]
    }
  },
  "_source": false
}

検索結果は次のようになります。

{
  "took": 2,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 19,
      "relation": "eq"
    },
    "max_score": 16.192907,
    "hits": [
      {
        "_index": "esci-sample",
        "_id": "B07ZNCJB3B",
        "_score": 16.192907,
        "_ignored": [
          "product_bullet_point.keyword"
        ],
        "matched_queries": {
          "match_description": 8.697643,
          "match_title": 7.495263
        }
      },
      {
        "_index": "esci-sample",
        "_id": "B07SG28ZS8",
        "_score": 12.9889765,
        "_ignored": [
          "product_bullet_point.keyword"
        ],
        "matched_queries": {
          "match_description": 4.4317617,
          "match_title": 8.557215
        }
      },

単なるNamed Queryの時はmatched_queriesの部分はクエリの名前がリストで返ってきていました。が、今回はオブジェクトに変わっており、クエリの名前に対してそのクエリのスコアが返ってくるようになっています。

explainパラメータを使って、スコアの内訳をみることもできますがレスポンスが肥大化してしまいますし、見るのがつらいことが多いです。簡易的に、どの条件がどのくらいスコアとして寄与しているのか？を見るためにはこちらのオプションを利用するのが便利でしょう。

まとめ

ElasticsearchのNamed Queryがどんなものなのか？と8.8から追加されたinclude_named_queries_scoreパラメータについて簡単に紹介しました。 Elasticsearchでの検索結果改善の参考になればと。

Weaviateを使って個人的備忘録を作ってる

Thu, 18 Dec 2025 12:41:50 +0000

本記事は、情報検索・検索技術Advent Calendar 2025の19日目の記事です（今年はなんか参加者が少なくてさみしいけど、きっと検索の人たちは検索流行ってて忙しいんだなということにしておこう）。

こちらの秋の検索勉強会で話をした内容になります。録画に失敗したので記事を書いておくかなと。。。

発表の資料と作ってるGitHubのリポジトリです。

なんで作ってるの？

仕事柄（検索システムに関するコンサルなどをやっていたりします）、検索に関する記事をよく読んでいます。 Xだったり、どこかのSlackだったり、Googleニュースだったりといろんなところから出てくる記事になんとなく目を通したり、仕事で調べた検索に関する各社の公式ブログや論文などにも目を通しています。

それなりの量を日々読んでいて、お客さんの話や質問で上がってくる内容に関連しそうな記事があったなぁと思うことが多々あります。ただ、最近読んだことは覚えていても、どの記事だったかが見つけられないことがあるんです（年齢的な問題？）。

なので、なんとなく読んで面白かった記事について、ブックマーク＋メモを残す仕組みをWeaviateを使って作ってみているという話です。

ちなみに、コードやドキュメントはAmazon QのVS Code拡張を使いながら書いてもらっています。個人ツールはそれっぽい名前を付けてもらうために、作りたいものの概要を説明してから「中二病っぽい名前の候補を10個作って」とLLMにお願いして名前を付けています。

なんでWeaviate？

ベクトル検索を主体にしたいなぁというのがあります。

うろ覚えなのでなんとなくで検索できるようにしたい
絞り込み検索もしたい（どのサイトとかは覚えてたりする）
Weaviateを宣伝したい（Community作ろうとしてます）

スライドではUIや前段のスクレイピングなどの話も記載していますが、今回のブログではWeaviateの部分を簡単に紹介する形にします。 Weaviateに登録する前段で記事の要約をして、関連するキーワードをLLMをつかって抽出する処理を入れてあります。

スキーマの定義

Weaviateでは、コレクションに対してデータを登録すれば自動的にデータに合わせてスキーマを定義してくれる機能があります。この場合、コレクションに作られるベクトル空間は1つとなります。

ただ、今回はベクトル空間をいくつか用意したい（タイトル、要約、自分のメモなど）と思っているので、あらかじめコレクション作成時にこちらでスキーマを指定します。


# コレクション作成
client.collections.create(
    name="GrimoireChunk",
    description="Grimoire Keeperで管理するWebページのチャンク",
    properties=[
        Property(name="pageId", data_type=DataType.INT),
        Property(name="chunkId", data_type=DataType.INT),
        Property(name="url", data_type=DataType.TEXT),
        Property(name="title", data_type=DataType.TEXT),
        Property(name="memo", data_type=DataType.TEXT),
        Property(name="content", data_type=DataType.TEXT),
        Property(name="summary", data_type=DataType.TEXT),
        Property(name="keywords", data_type=DataType.TEXT_ARRAY),
        Property(name="createdAt", data_type=DataType.DATE),
        Property(name="isSummary", data_type=DataType.BOOL),
    ],
    vector_config=[
        Configure.Vectors.text2vec_openai(
            name="content_vector", source_properties=["content"]
        ),
        Configure.Vectors.text2vec_openai(
            name="title_vector",
            source_properties=["title", "summary"],
        ),
        Configure.Vectors.text2vec_openai(
            name="memo_vector", source_properties=["memo"]
        ),
    ],
)

GitHubのコードはこちら

コレクションの定義をしている部分のコードです。コレクションの名前（name）、説明文（description）、プロパティ（properties：フィールド、カラムのようなもの）をまず定義しています。プロパティにも説明を書いた方がいいのですが、今回は記述していないです（ Query Agent | Weaviate Documentationという機能も提供されており、エージェントがコレクションを検索するときのヒントになるので、コレクションやプロパティに説明を付けてあげたほうが今後の役に立つことになります）。

ここまでは、よくあるスキーマの定義になりますが、最後のvector_configがこのコレクションのベクトルに関する設定になります。

今回は名前を付けたベクトル（named vectors）を3つ設定しています。

title_vector：タイトルと要約から生成するベクトル空間
content_vector：記事本文をチャンキングしたものから生成するベクトル空間
memo_vector：メモから生成するベクトル空間

すべて、入力としてはpropertiesで定義したデータの型（今回はすべてテキスト）のデータになります。 Weaviateの内部で、ベクトル化モジュールがOpenAIのembeddingモデルをAPI経由で呼び出して、テキストからベクトルに変換して保存してくれます。アプリとしては、タイトルや要約などはテキストとしてWeaviateにデータを登録するだけになります。

modelパラメータを設定することで、自分でモデルの選択もできますが、今回はデフォルトのモデルを使用するようにしています。

データの登録

collection = client.collections.get("GrimoireChunk")
for i, chunk in enumerate(chunks):
    weaviate_object = {
        "pageId": page_data.id,
        "chunkId": i,
        "url": page_data.url,
        "title": page_data.title,
        "memo": page_data.memo or "",
        "content": chunk,
        "summary": page_data.summary or "",
        "keywords": json.loads(page_data.keywords or "[]"),
        "createdAt": (
            page_data.created_at.replace(tzinfo=None).isoformat() + "Z"
            if page_data.created_at.tzinfo is None
            else page_data.created_at.isoformat()
        ),
        "isSummary": i == 0,
    }

    result = collection.data.insert(properties=weaviate_object)

GitHubのコードはこちら

登録の処理の抜粋です。前処理として本文の部分（content）をチャンクに分割しているので、それらを登録しています。それとは別に、title_vectorやmemo_vectorのベクトル空間を検索した時に、不要なデータが表示されないようにisSummaryということで、最初のチャンクにフラグを立てて、それで絞り込めるようにしてあります。

検索処理

                collection = client.collections.get("GrimoireChunk")

                # フィルター条件構築
                where_filter = self._build_weaviate_filter(filters) if filters else None
                exclude_filter = self._build_exclude_filter(exclude_keywords) if exclude_keywords else None

                # ベクトル別フィルター追加
                summary_filter = None
                if vector_name != "content_vector":
                    from weaviate.classes.query import Filter

                    summary_filter = Filter.by_property("isSummary").equal(True)

                # フィルター結合
                filters_list = []
                if where_filter:
                    filters_list.append(where_filter)
                if summary_filter:
                    filters_list.append(summary_filter)
                if exclude_filter:
                    filters_list.append(exclude_filter)

                final_filter = None
                if len(filters_list) == 1:
                    final_filter = filters_list[0]
                elif len(filters_list) > 1:
                    final_filter = Filter.all_of(filters_list)

                # クエリ実行
                response = collection.query.near_text(
                    query=query,
                    target_vector=vector_name,
                    limit=limit,
                    filters=final_filter,
                    return_metadata=MetadataQuery(certainty=True),
                )

                # 結果変換
                return self._convert_search_results_v4(response)

GitHubのコードはこちら

検索処理です。入力されたキーワードや文章をベクトル検索するのにはnear_textメソッドを利用します。 target_vectorが検索対象となるベクトル空間の名前（例：title_vector）の指定です。クエリ実行前にいくつかのフィルタ条件を組み立てて、条件として追加してあります（期間だったり除外するキーワードなどの条件）。

検索するときもこちらでベクトルに変換するなどの処理は行っておらず、テキストをqueryに渡せば、よしなにWeaviate側でベクトル空間の設定をもとにエンベディングして検索をしてくれます。

まとめ

とりあえず、トラディショナルな感じのRAGのベースを自分でも試してみるかな？と思いながら作ってます。が、いろいろと使ってみて気づくことが多いなとなってるところです。

データはWeaviateに入れる前の時点でファイルとして保存するような作りにしているので、いろいろと改善できそうなことに手を出しながら触っていこうかなと思います（late interactionっぽいことやってみたり、チャットのUIを用意したり、チャンキングの仕組みを変えてみたり）。

なんとなく、Weaviateの使い方がこんな感じかな？というイメージを持ってもらえたら幸いです。

今年の輪読会で読んだ本

Mon, 08 Dec 2025 14:18:59 +0000

johtaniです。この記事は、pyspa Advent Calendar 2025 の9日目です。

昨日はrokujyouhitomaさんの「守る力を強化した本年の話 - rokujyouhitoma’s blog」でした。資格取得すごいなぁ。全然とってない。。。

輪読

知り合いと毎週1回のペースでオンラインで気になる技術書の輪読してます。それぞれ忙しいしということで、事前に読んでくる形じゃなくてその場で読む感じ（読み上げる感じ）でやってます。

放っておくと、書籍が積みあがって読まないのもあって、毎週1回そのタイミングを作る感じです。

今年は以下の3冊を読みました（最後の1冊はまだ途中）

Real World HTTP 第3版

Goの勉強もしてたので、Goでサンプルが出てくるのがよかったです。あと、知らないことが結構ありました。昔はそんなのあったねぇみたいなのも思い出したりしましたが。最近はこう変わってるよなどの話や、セキュリティに関する話など普段はあまり縁がないので勉強になりました。

Go言語で学ぶ並行プログラミング

輪読してる知り合いがGoに精通しているのもあって、教えてもらいながら読みました。大学のころにセマフォとか聞いた気がするなぁと思いながら読んでました。チャネルに関する話に触れられたので、今後のGoのプログラムを読んだりするのに役立ちそうかな。自分で並行処理を書くことがあるかは不明だけど。

オブザーバビリティ・エンジニアリング

先週時点で16章まで読みました。オブザーバビリティの話自体は、Elasticsearchなどでも触れていたのですが、勘所やモニタリングとかとの違いを明確に勉強してたわけでもないし、OpenTelemetryもキーワードとしてちょっと知ってたくらいなので勉強になってます。副読本としてSLOの本も読んだ方がいいんだろうなぁ。

あと、ローカルでさくっと動かせる環境があるとさらに便利なんだろうなぁと思いつつ、まだ手元に環境はできてない。実際に個人で作ってるツールでも、なんかうまく動いてないのがあるなぁ？みたいなことがあるので（外部要因が多かったりする）、環境を整えたいなと思っているところ。

ターミナルでOpenTelemetryのトレースを閲覧できるツール「otel-tui」を作りました

こういうのもあるみたいだし。

先週、「効率的なデータストア」のところを読んだのだけど、「リアルタイムでデータをクエリーする」がまだしっくり来てない。 Elasticsearchの仕組みを知ってるおかげで想像がつく部分は多々あるんだけども。

今年中に読み終わるかなぁ？と思ってたけど無理そうかな（週1章のペースでは進んでるんだけども）

来年も続けていたい習慣

もうあんまり覚えてないんだけど、10年以上続いてるので、今後の10年も続けていきたいなと思っている習慣です。最近はオンラインだし、どこ読んでるかわかるように声に出して読み上げてるんだけど、誤植を見つけやすかったりします。

その代わりの犠牲といってはあれだけど、読む方に注力してしまって、メモが取れてないんだよなぁ。ほんとはメモ取るといいんだけど、そこができてないんだよなぁ。なんかいい手を思いつけばいいんだけども。。。

ということで、知り合いのおかげで思ったよりも長続きしている習慣の話でした。

明日のpyspa Advent Calendar 2025

明日はotiai10さんです。

Weaviateを使って個人的備忘録（まだ途中）

Thu, 30 Oct 2025 00:00:00 +0000

Weaviate入門（Quickstart - Go言語編）

Mon, 14 Jul 2025 09:41:28 +0000

いくつか用語も説明したので（ベクトルデータベース、オブジェクト、コレクション、モジュール）、そろそろちょっと触ってみる、クイックスタートを紹介します。

英語で書かれたQuickstart (with cloud resources) | Weaviate Documentationもあるのですが、実は日本語のページが用意されてます。

Weaviate ベクトルデータベース | Weaviate

こちらに沿って、簡単ですがクイックスタートを紹介します。

日本語のクイックスタートでは、Weaviateのクラスターに対して、「Jeopardy!」のデータを登録し、VectorizerモジュールとGeneratorモジュールにOpenAIのAPIを利用して、簡単なベクトル検索とRAG（検索拡張生成）を体験できます。

0 OpenAIのAPIキーの取得

このクイックスタートではOpenAIのAPIを利用します。クイックスタートの「3.簡単なデータの取り込み」の「登録はこちら」リンクからOpenAIにサインアップするか、すでにOpenAIのAPIを利用されている方は、今回のためにAPIキーを生成して用意してください。

1 Weaviateデータベースの作成

マネージドサービスとして、Weaviate Cloudが用意されています。

ちょっと触ってみるのにはアカウントを作成してから、Sandboxクラスターを利用するのが簡単です。アカウント作成やSandboxクラスターの作成方法は以下のドキュメントを参考にしてください。

なお、Sandboxクラスターは14日間で自動で削除されるのでそこだけ注意が必要です。容量の制限もあるので、大量データで利用する場合は別途、Serverlessなどを選択する必要があります。

2 Weaviate Clientライブラリのインストール

クイックスタートで選択できる言語は以下の通りです。

Python
JavaScript / TypeScript
Go
Java（最近クライアントが新しくなった）

各言語向けのクライアントのインストール方法が表示されています。 Dockerなどで環境を用意してインストールをしてもいいですし、ローカルにインストールすることもできます。

私は、Pythonを利用する場合はDevContainerの環境を用意したりします。 GoやJavaだとローカルで済ますかな？

たとえば、Goのプロジェクトを作っておいて以下を実行します。

go get github.com/weaviate/weaviate-go-client/v5
go install

3. 簡単なデータの取り込み

クライアントの接続

まずは、Weaviate Cloudのクラスターへの接続情報が必要にです。

1.で作成したクラスターをクリックし、Cluster detailsの画面で以下の情報をコピーし、環境変数に設定します。

Informationのセクションの「REST Endpoint」の文字列を環境変数WEAVIATE_URLに設定
API Keysのセクションで、「+ Create API Key」ボタンをクリックし、出てきたダイアログで
1. Name：なんでもOK（例：go-sample-client）
2. Role：adminを選択
生成されたAPIキーをコピーして、環境変数WEAVIATE_API_KEYに設定（APIキーは生成するタイミングでダウンロードもできます）。

Weaviateにあるモジュールを経由して、OpenAIのAPIを実行するために、OpenAIのAPIキーをリクエストヘッダ経由で設定します。実際の値はOPENAI_API_KEYという環境変数から取得しますので、APIキーを環境変数OPENAI_API_KEYに設定します。

	cfg := weaviate.Config{
		Host:       os.Getenv("WEAVIATE_URL"),
		Scheme:     "https",
		AuthConfig: auth.ApiKey{Value: os.Getenv("WEAVIATE_API_KEY")},
		Headers: map[string]string{
			"X-OpenAI-Api-Key": os.Getenv("OPENAI_API_KEY"),
		},
	}

クイックスタートで使用する環境変数は以上の3つ（WEAVIATE_URL、WEAVIATE_API_KEY"、OPENAI_API_KEY）です。

ここまでのプログラムも実行できるので、実行してみましょう。 Weaviateへの接続情報に問題がなければ、「true」とだけ表示されます（現時点ではOpenAIのAPIへの接続は未確認です）。（このあとには、// Check the connectionの処理の部分は変更します）

データコレクションの作成

Weaviateでは、データを登録する前にコレクションを作成しておく必要があります。今回の処理では、models.Classという構造体を使ってスキーマを定義します。

コレクションの名前（Class）
使用するベクトライザー（text2vec-openai）
使用するモジュール（text2vec-openai、generative-openai）

使用するベクトライザーは、このコレクションでエンベディングのベクトル生成に利用するデフォルトのベクトライザーになります。

このクイックスタートでは、プロパティについては、データ登録時に自動で設定するようにしています。プロパティ個別にベクトライザーやその他の設定を行うこともできます（Basic collection operations | Weaviate Documentation）。

なお、今回の処理では、エラーが出力されなければ問題なくコレクションが作成されたということになります。エラー出ない場合のメッセージの処理がないためです。

Weaviate Cloudのコンソールで「Collections」をクリックし、先ほど作成したクラスターを選択した後に、「Question」というコレクションが表示されているかを確認することで処理の成功を確認できます。

データ登録

コレクションの作成もおわったので、Jeopardyのデータを登録します。処理の流れとしては次のようになっています。

Weaviateのクライアント接続
JSONファイルのダウンロードしてmapの配列に
1データずつ、models.Objectの構造体に変換
ObjectsBatcher()を利用して、バッチ登録
1. Weaviateがデータを受け取って、text2vec-openaiモジュールを使ってベクトルに変換してからベクトルインデックスに登録
2. JSONのプロパティからWeaviateのスキーマを自動で生成してくれる

3の構造体を作るときに、JSONの文字列のデータを入れているだけで、このタイミングではベクトルは生成していません。 4.1に書いたように、Weaviate内部でOpenAIのAPIを利用してエンベディングの生成を行います。ですので、この処理を実行するときにはOpenAIのAPIキーを設定しておく必要があります。

コレクションの作成と同様に、エラーがなければ成功です。

ちなみに、OpenAIのAPIキーを設定せずに実行すると、次のようなエラーが出ます。

panic: ([]*models.ErrorResponseErrorItems0) 0xc000008870

goroutine 1 [running]:
main.main()
	....weaviate-quickstart-go/main.go:68 +0x745

上記のサンプルのままでは、res.Result.Errosrs.Errorは配列のためエラーが発生してしまいました。

次のように修正することで、登録時のレスポンスにエラーが含まれている場合に、エラーの内容がきちんと表示できます。

	for _, res := range batchRes {
		if res.Result.Errors != nil {
			for _, items0 := range res.Result.Errors.Error {
				println(fmt.Sprintf("Error is %v", items0))
			}
		}
	}

APIキーの設定を忘れているとこんな感じのエラーメッセージになります。

Error is &{API Key: no api key found neither in request header: X-Openai-Api-Key nor in environment variable under OPENAI_APIKEY}

データ登録できたかどうかは、この後のクエリで確認もできますし、先ほどのコンソールでのコレクションを見ると「10 objects」となってデータが登録されているのも分かります。

4. クエリ方法

最後は検索です。クイックスタートでは、ベクトル検索とRAG（検索拡張生成）を試すことができます。

ベクトル検索

入力テキストからベクトライザーでベクトルを生成して、そのベクトルをもとにベクトルインデックスを検索する処理です。

今回のクイックスタートでは、検索には次の情報が指定されています。

検索結果に含めるプロパティ（フィールド）
- []graphql.Fieldに指定しているもの
クエリ文字列
- nearTextに調べたい文章（今回はbiologyという単語）を設定
検索対象のクラス名（コレクション名）
- 「Question」
取得する件数（最もベクトルが近いものn件）
- WithLimitに2を指定

返却されるresultに検索結果が入っています。中身はWebに掲載されています（ローカルだとインデントされてないですが）。

RAG

ベクトル検索では、入力のテキストに近いオブジェクトを取得するだけでした。 RAGのサンプルコードでは、ベクトル検索をして結果を取得するところまでは同じ流れですが、取得した後に、それぞれのオブジェクトのデータを使って文章の生成をモジュールを使用して行う処理が追加されています（WithGenerativeSearch()メソッド）。

generativeSearch := graphql.NewGenerativeSearch().SingleResult("Explain {answer} as you might to a five-year-old.")

{answer}に、ベクトル検索の結果のオブジェクトのanswerプロパティの文字列が入ります。そして、生成モジュールを通して、テキストが生成され、その結果が_additionalのgenerateの中に帰ってきています。

クライアントアプリ側では、特にOpenAIのAPIの呼び出しを行っていませんが、文字列の生成までできています。

まとめ

ということで、日本語に翻訳されたクイックスタートについてGo言語のサンプルコードをもとに紹介をしました。数件しかデータを入れていないですが、簡単に動作を確認できるかと思います。

クイックスタートはまだほんの入り口にすぎません。Weaviateでできることはほかにもあるので、ちょっとずつこれからも紹介していこうかと思います。

最後に

日本のコミュニティとしてConnpassにグループを作りました。

Weaviate JP Community - connpass

どうやってイベントをやるかはまだ考え中ですが、興味がある方は登録しておいていただければと。

どんな情報、どんなイベントがあれば興味をもっていただけるか？Weaviateを使ってみようと思うけど何から始めよう？など疑問に思うことがあればXやブログのコメントなどをいただければと思います。

Weaviate入門（モジュール）

Tue, 08 Jul 2025 08:25:32 +0000

今回も用語の話です。今回は仕組みの用語「モジュール」です。

モジュール

Weaviateを利用する際にいくつかの機能についてモジュール化されています。根幹となるベクトルデータベース周りに便利な処理を提供するのがモジュールです。

ベクトライザーモジュール

たとえば、Weaviateはベクトルデータベースですが、登録するデータのベクトルを生成する「ベクトライザー」と呼ばれるモジュールを備えています。これにより、データ登録や検索時にアプリケーション側で独自にベクトルを生成してからWeaviateに問い合わせる必要がなくなり、より簡単に検索やデータ登録をできるようになっています。ベクトライザーと呼ばれるモジュールには、様々なモデルやモデルプロバイダー（OpenAIやCohere、Weaviate、Jina AI、Hugging Faceなど）のモジュールが用意されています。必要に応じてモジュールを有効にすることができます。

また、カスタムモジュールということで、独自のモジュールを作成できるようにもなっています。利用可能なモデルプロバイダーがなかったり、機能の追加をしたい場合はドキュメントをご覧ください。

もちろん、ベクトライザーを使用せずに、独自のベクトルのデータを登録したり、検索に使用することも可能です。

生成モジュール

ベクトライザーはエンベディングの生成の用途でしたが、生成モジュール（生成AIモジュール？）と呼ばれるものもあります。こちらは、検索した結果をもとに、回答を生成することもできます。RAGのGenerateの部分です。検索するだけでなく、回答の生成のためにLLMを呼び出す仕組みも用意されています。

Weaviateの公式ドキュメント

今回はモジュールについて少しだけ紹介しました。モジュールの概念に関するWeaviateのドキュメントをModules | Weaviate Documentationご覧いただくとそのほかのモジュールについても記載があります。また、モデルプロバイダーに関するページも参考にしてください（Model provider integrations | Weaviate Documentation）。

最後に

日本のコミュニティとしてConnpassにグループを作りました。

Weaviate JP Community - connpass

どうやってイベントをやるかはまだ考え中ですが、興味がある方は登録しておいていただければと。

Weaviate入門（オブジェクト、コレクション）

Fri, 04 Jul 2025 03:16:01 +0000

ソフトウェアやサーバーによって用語って変わりますよね？ベクトルデータベースのWeaviateも、私がこれまで触ってきたものとは違う用語が使われているので、いくつかの用語を紹介しようと思います。

データオブジェクト

1件のデータのことをデータオブジェクトと呼びます。データオブジェクトはプロパティ（名前とデータ型）を持っており、コレクション（クラスと呼ばれることもある）と呼ばれるデータの集合（RDBでいうテーブルのようなもの）に属します。データオブジェクトはJSONドキュメントとして表現されます。データオブジェクトを登録する場合は、コレクションに対して登録します。

ベクトルデータベースなので、データオブジェクトに直接自分で作成したベクトルを含めて登録することもできますが、Weaviateでは、ベクトライザーと呼ばれるベクトルエンベディングをWeaviateのモジュールが生成してくれる機能があります（OpenAIのAPIを利用したエンベディングなど、さまざまなエンベディングのAPIを呼ぶ設定ができるようになっている）。コレクションの作成時にこのベクトライザーを定義しておくと、コレクションにデータを登録するとベクトルを生成して検索できるようにしてくれます。

コレクション

RDBでいうテーブルのようなものです。コレクションに対してデータオブジェクトを登録、更新などを行えます。コレクションにはスキーマが定義されており、コレクションに属するデータオブジェクトがどのようなプロパティを持っているのかがわかります。

コレクション作成時にスキーマを定義することもできますが、チュートリアルなどでは、自動生成されるスキーマを利用している場合があります。また、上記でも説明したようにベクトライザーと呼ばれるベクトル生成のためのモジュールの設定などもこちらで定義できます。

コレクションごとにベクトル空間があり、その中でベクトル検索ができるようになっています。また、バージョン1.24からは、名前付きベクトルと呼ばれる機能が追加され、1つのコレクションに対して複数のベクトル空間を作ることもできるようになっています。

ベクトル以外にも、転置インデックスの設定もできるようになっており、いわゆるハイブリッド検索（転置インデックスを利用した検索＋ベクトル検索）も可能になっています。

Weaviateの公式ドキュメント

今回紹介したデータの概念などに関するWeaviateのドキュメントはData structure | Weaviateにあります。

図などもありますので、参考にしていただければと。

最後に

日本のコミュニティとしてConnpassにグループを作りました。

Weaviate JP Community - connpass

どうやってイベントをやるかはまだ考え中ですが、興味がある方は登録しておいていただければと。

Weaviate入門（ベクトルデータベース、ベクトル）

Tue, 01 Jul 2025 06:11:01 +0000

Weaviateって聞いたことありますか？

Goで書かれたOSSのベクトルデータベースです（GitHubリポジトリはこちら）。昨年、Kagomeを使えるようにPRを送って、発表をしてきました。

改めて、Weaviateはどんなものなのか？というのを少しずつアウトプットしていこうかと思いブログを書き始めたところです（日本で広めていく手伝いもすることになったので）。まずは、用語などの説明から少しずつ始めていこうと思います。

ベクトルデータベース？

最近では、RAG（Retrieval-Augmented Generation）などで利用されるものというイメージが多いかもしれないです。

ベクトルデータベースとは、データオブジェクトとそれを表現するベクトルを保存してベクトルの近いものを検索することができるものです。データオブジェクトはベクトルのもととなるテキストなどに加えて、メタデータを含んだ情報です。

検索する際に、クエリをベクトルに変換したものに近いベクトルを持ったデータオブジェクトを探してくることができます。近いベクトルというのは、類似のベクトルを探してくると言い換えることもできます。これにより、ベクトルとして似ているものを検索して並べることが可能となります。

ベクトルデータベースは、大量のベクトルデータに対してさまざまな技術を用いて素早く検索をする仕組みを提供します。

ベクトル？

RAGという観点だとテキストの検索のイメージがありますが、ベクトルにできるものはテキストだけではありません。画像、動画、音声、何かしらの特徴量をベクトルにするといったことも可能です。 LLMの流行の前から画像の検索などにベクトルが用いられてきました。

また、LLMの活用によってテキスト情報をベクトル埋め込みと呼ばれる手法でベクトルにすることで、これまでのキーワードによるテキストや単語の完全一致ではなく、意味的な類似によって情報を検索できるようになってきています。このため、ベクトル検索はセマンティック検索（意味的な検索）とも呼ばれています。

ベクトル空間に異なるデータのベクトルを統合することで、マルチモーダルなベクトル検索を可能にすることなどもできます（昨年やったデモはキーワードで画像を検索してみました）。

Weaviateの公式ブログ

Weaviateの公式ブログにはさらっと私が書いたこと以上にベクトルデータベースに関する記事（ A Gentle Introduction to Vector Databases | Weaviate）やベクトル検索に関する記事（Bring your own vectors | Weaviate）が公開されています。こちらも参考になるかと。

これ以外にもWeaviateのブログではLLMやRAGにまつわる技術の紹介などがされているので興味がある方はご覧いただければと（たとえば、Late Interactionの話とか）。

最後に

ということで？、日本のコミュニティとしてConnpassにグループを作りました。

Weaviate JP Community - connpass

どうやってイベントをやるかはまだ考え中ですが、興味がある方は登録しておいていただければと。

今年の振り返りと来年の抱負（2024）

Tue, 31 Dec 2024 01:27:20 +0000

いやー、紅白のB’zよかったですね（毎年恒例のブログを紅白見ながら書いてます）。

振り返り（2023年に書いた抱負から）

まずは振り返りです。

フリーランス継続

今年は出だしはそれほど忙しくなかったのですが、後半は新規のお客さんも増えて、個人事業主としてやって行けてます。今のところそのまま、来年も継続していただける感じなのでありがたいことです。調べものして、レクチャーするというのが多いかな？

プログラミング継続

昨年末はTypeScriptって書いてましたが、結局Goがメインで時々C#のサンプル書いたりって感じです。あとは、AtCoderを初めて見ました。そんなにできる気はしないんですがいい刺激になるかなと。やりっぱなしで、復習してないからそこは改善しないとかもな。あとは、この後の話にも続きますが、PythonもLLMや検証結果を提示するためにJupyter Notebook書いたりに使ってます。全然Java触ってないな、そういえば。

ベクトル検索の使い方をいろいろ試す

試せてる？とまでは行けてないですが、Weaviateをちょっとずつ触ってます。ベクトル検索に関して調査したりはしてますが、使い倒すところまではいけてないなぁ。進化が早いのもあって、追いつけてない気がする。。。

本を読んだブログを書く

ブログに書いたのは1冊だ。。。

「続ける思考」を読んだ | @johtaniの日記 3rd | @johtani’s blog 3rd edition

ただ、この本のおかげで歯磨き読書は続いています。

振り返り（今年あったできごと）

今年もおかげさまでずっと自宅で仕事してました。仕事で外出したのは数回かな。

ゲーム
- FactorioのSpace Explorationは途中で仕事が忙しくなって放置してしまった
- FF16（クリア）
- ゼルダのカリモノ（クリア）
- バイオRE2（クリア）
- ELDEN RINGのDLC
- TUNIC
- DEATHLOOP

結構やってるな、前半暇があったからかも？ FactorioのDLCが待ってるので頑張らないとなぁ。バイオRE3も待ってる。

仕事環境としてはPC組み替えました。4年前に組んだPCでもそれほど問題ないのですが、ローカルでLLM動かしたりもしたいなと思いつつ。移行でWSL2の環境を吹っ飛ばしてしまったので痛い目にあいましたが。。。今回は空冷で、黒いケースで、光らないPCにしました。

今年はZOZOさん向けにElasticsearchのハンズオンをやりました。ハンズオン資料はLLMを使ってざっくり作るということをやってみました（ブログ：AI活用しきれていない話）。知ってる内容だととても便利ですね（おかしいところは自分で補完できるし）。改めて、利用している機能、していない機能に関係なくハンズオンしてもらうことで、何かのヒントになればという感じで。

検索技術勉強会もリアルに参加して、5月と10月に2回ほど司会をさせていただきました。来年も企画中なので楽しみにしていてください。もちろん、絶賛スピーカーを募集中です。

来年の抱負

さて、最後は来年の豊富です。

フリーランス継続
プログラミング継続
Weaviateをもと触る
本を読んだブログを書く？
勉強会の録画をマスターする？

今年はありがたいことに後半に仕事が増えてPC組み替えたりもできました。つながりのないところから舞い込んだ仕事などもあったりと、大変ありがたいことで。

プログラミングはGoをメインで継続していくつもりです。 AtCoderもGoで書いてますし、WeaviateもGoで書かれているのもありちょうどよい題材かなと。あとは、PythonはLLM周りで使うんだろうなぁ。 AtCoderは復習を緒とはするようにしないと伸び悩みそう。。。

Weaviateに日本語のトークナイザーのコントリビュートをしましたが、ほかにもいろいろと触っていきたいなぁと。プログラミングの勉強にもなるのでソース読んだり、ほかの機能のコントリビュートしたりもやっていきたいなぁ。新しいことを触ることで自分へ刺激になるのが一番の理由だったりします。

読んだ本のブログのネタを集めるために、Slackのボットを書いて、読書で気になった点や面白かった点を書き出すような仕組みを作りました。これを改良しつつ、ブログに簡単にまとめられるようにしたいな。あとは、読書にもChatGPTなどを活用していきたいな（知り合いの真似をしながら）

勉強会で録画させていただいているのですが、今回は音声がいまいちだったかなぁと。ノートPCでMeetに録画しながらやってみたんですが、ノイズキャンセリングのせい＋ノートPCのマイクだったので、もっとよい環境で録画、録音できるようなノウハウを手に入れたいですね。

来年の抱負も固定化してきつつあるから、やっぱり何か刺激を入れないとなぁ。

ということで、とりあえず今年もあと少しというところでブログが書きあがりました。来年も検索技術勉強会を開催するつもりなので楽しみです（自分がいろんな話を聞きたいからやってる）来年もよろしくお願いいたします。よいお年をー

ElasticsearchのRetrieverについて調べたので雑にメモ

Fri, 27 Dec 2024 04:09:21 +0000

ElasticsearchにRetrieverという仕組みが8.16でGAしたので、ざっくり調べた時のメモを残しておこうかなと。

ElasticsearchのRetriever

Retrieverという検索の機能が8.16でGAリリースされた。

Retrieverとは？

これまでの検索処理（_serachエンドポイント）では、検索してsearch_afterで検索結果を絞り込む（Aggregationは最初の検索処理の結果）ことや、rescoreで検索結果の一部を別のクエリでスコアリングして並べ替えるといったことが可能でした。しかし、複数の検索処理それぞれ実施してその結果を並べ替えたり、入れ子にした検索の処理を行ったりといった検索パイプラインのような処理はできませんでした。

8.16でリリースされたRetrieverは1回のリクエストで、複数のクエリを実行した結果をRRFで結合したり、rerankerでリランキングしたりといったことが可能になります。 rrfがリリースされたタイミング（8.8）では1つのパターンのみが考慮されていました。

queryが通常の転地インデックスを利用した検索、knnがベクトル検索、rankが2つの検索結果を統合するためにrrfを利用するという命令となります。

{
  "query": {
    "match": {
      "product": {
        "query": "brown shoes"
      }
    }
  },
  "knn": {
    "field": "product-vector",
    "query_vector": [54, 10, -2],
    "k": 20,
    "num_candidates": 75
  },
  "rank": {
     "rrf": {
        "window_size": 100,
        "rank_constant": 20
     }
  }
}

この形以外で検索結果を統合する自由度がありません。また、rankについてもrrfのみのでGAしていません。これらの拡張性を提供する形でRetrieverが提供されています。

上記のクエリは次のようなRetrieverとなります。

{
  "retriever": {
    "rrf": { 
      "retrievers": [ 
        {
          "standard": { 
            "query": {
              "match": {
                "product": {
                  "query": "brown shoes"
                }
              }
            }
          }
        },
        {
          "knn": { 
            "field": "product-vector",
            "query_vector": [54, 10, -2],
            "k": 20,
            "num_candidates": 75
          }
        }
      ],
      "rank_constant": 20, 
      "rank_window_size": 100  
    }
  }
}

それぞれ検索結果のリストを返すものを「Retriever」と呼び、rrfなどは、複数の検索結果を混ぜて返すため、入れ子で別のRetrieverを読んでいる形となります。

複数のretreiverをパイプライン処理のようにつなぎたい場合は、入れ子にしていくことで前段のretrieverの結果をもとに、後段のretrieverの処理を実施可能です。

GET retrievers_example/_search
{
    "retriever": {
        "text_similarity_reranker": {
            "retriever": {
                "text_similarity_reranker": {
                    "retriever": {
                        "knn": {
                            "field": "vector",
                            "query_vector": [
                                0.23,
                                0.67,
                                0.89
                            ],
                            "k": 3,
                            "num_candidates": 5
                        }
                    },
                    "rank_window_size": 100,
                    "field": "text",
                    "inference_id": "my-rerank-model",
                    "inference_text": "What are the state of the art applications of AI in information retrieval?"
                }
            },
            "rank_window_size": 10,
            "field": "text",
            "inference_id": "my-other-more-expensive-rerank-model",
            "inference_text": "Applications of Large Language Models in technology and their impact on user satisfaction"
        }
    },
    "_source": false
}

提供されているRetriever

standard: これまでの検索クエリの実行を行うretriever。
knn: knn検索のためのretriever。
rrf: RRFを用いて検索結果を生成するretriever。
- 複数のRetrieverを呼び出せる。
text_similarity_reranker: NLPモデルを利用して検索結果の上位k件を並べ替えるretriever。
- inference APIで登録してあるものを呼び出すもの。
- 別のRetriever（1つだけ）の結果を指定したRerankerで並び変える
rule: クエリルールを利用して、特定のクエリに対して処理を実施する
- 8.17時点では、pinnedとexcludeのみ

Text Similarity Re-ranker Retriever（8.17時点）

Create inference APIを利用して、text_similarity_rerankerのエンドポイントを設定。こちらは、テキストの類似性を計算できるもの。

現在利用できるRerankerは次の通り

Elastic Reranker： Elasticが作ったクロスエンコーダモデル。
Cohere Rerank inference endpoint:Cohereのrerankタスクを利用
Google Vertex AI inference endpoint:Vertex AIのrerankタスクを利用
Elandというツールを使って、アップしたモデルを利用（サポートされてるモデルに制限あり）

Elandを利用するパターンはサポートされているモデルは現状2種類なので、あまり選択肢がないと思われる。 Vertex AIで定義したものがどのくらい自由度があるのかは別途調査する必要がある。 Enterpriseの契約でなければInference APIが利用できない。

使い方（例）

既存の検索の仕組みとの組み合わせの例などが記載してある（ハイライト、collapse、inner_hits、aggsなど）。

Retrievers examples | Elasticsearch Guide ［8.17］ | Elastic

QueryのRescorerは？

Query Rescorerという仕組みが用意されており、通常の全文検索のqueryに対して、上位N件の結果を別のクエリを用いてスコア計算をする方法が用意されている。

このquery rescorerはretrieverでは現時点（8.17）では利用できない模様（Issue 118327）これに対し、すでにPRが作成され、次期バージョンに取り込まれるrescoreと呼ばれるretrieverが実装されている。

ElasticのLtRとRetrieverの組み合わせはどうなるのか？

上記のPRが実装されることで、「おそらく」ElasticのLtRの検索もrescoreのretrieverで呼び出せるはず（要確認）。

O19nのLtRは？

こちらもRescoreで呼び出す形であれば、上記のPRで対応されるのでは（要確認）。

そのほかに気になる観点（そのうち調べるかも？）

使えないクエリとかあるのか？
- Retrieverと現在の_searchの組み合わせに関しては制限の記載あり
- 個別のRetriever内部で制限があるかは未調査
Query Profileとかどうなるのか？
分散トレーシングのSpanとかはどうなるのか？どのRetrieverがどのくらいの処理時間みたいなのがわかるのか？
SlowQueryはShardに対してなので、末端（葉）のクエリの処理での計測になるのか？
- Fetchも同様か？
Fetchはどのタイミングで実行されるのか？一番最後？
Rescoreとの違い、組み合わせはどうなるのか？
- そのうちなくなりそう、rescore?
クエリの実行順序を明確に指定できる形にできるから、処理早くしたりできる？？？
複数Shardの場合の処理の流れってどんな感じ？

まとめ

とりあえず、雑に調べてたので、雑にメモに残しておきます。まだちゃんとしたデータで動かしてないので、それは宿題かなぁ。

Weaviateで日本語を利用した検索という話をしました

Tue, 17 Dec 2024 13:22:01 +0000

この記事は情報検索・検索技術 - Qiita Advent Calendar 2024 - Qiitaの17日目（ちょっと遅刻？）の記事となります。

「【日本初主催】新世代のソフトウェアのためのAIネイティブデータベース Weaviate Japan Summit | Peatix」というイベントでKagomeでテキスト検索できる仕組みを実装したものを取り込んでもらった話をしてきました。

Weaviateとは、ベクトル検索やキーワード検索、RAGなどを手軽に体験できるデータベースになります。 OSSで公開されており、SaaSも提供されています。Goで実装されていることもあり、日本語の検索にKagomeが利用できるかも？ということでちょっと調べて実装してみました。

先週の発表に利用した資料は次のリンク先で公開してあります。

スライド：Weaviateの日本語対応とマルチモーダル・多言語検索デモ

セッションでは、日本語のキーワード検索だけではなく、ベクトル検索やキーワードとベクトルを組み合わせたハイブリッド検索をデモしました。今回はセッションで話をあまりしていない、デモの仕組みに関してブログにまとめようと思います。

デモデータについて

今回は日本語を用いたデモ（今回取り込んでもらった機能を紹介するデモ）が必須であったため、次のような要件でデモを考えていました。

日本語テキストに対してキーワード検索
ベクトル化したデータも検索（Weaviateの得意分野）
せっかく日本でやるイベントなので日本語を使ったベクトル検索がいい
ハイブリッド検索やフィルタ検索（ベクトル検索した結果をキーワードでフィルタリング）のデモをやりたい

テキストだけで当初はデータを探そうと思っていたのですが、ベクトル検索とキーワードの検索での違いが分かりにくくなりそうかも？という懸念がありました。それよりも、画像を日本語で検索でき、画像に日本語の文章の説明がついているデータがデモをするときの流れも作りやすいのでは？と思い、まずは、Weaviateのマルチモーダルのデモを探すことに。

デモのシステムのベース

Weaviateの方たちは様々なデモを用意してくれており、マルチモーダル検索のデモも用意されていました。ベースとしたのは、次のリンク先で公開されているサンプルになります。

weaviate-examples/clip-multi-modal-text-image-search/README.md at main · weaviate/weaviate-examples

このサンプルは3つの要素から構成されています。

Weaviate Server
CLIPモデルを用いたServer（Hugging Faceを利用したサービス）
Node.jsによるフロントエンド

最初の2つはDockerで起動するコンテナとなっています。

Weaviateにはモジュールという概念があります。このモジュールの中で、入力されたデータをもとにベクトル化するものをVectorizerと呼んでいます。今回はmulti2vec-clipというVectorizerを利用して、Weaviateから2のCLIPモデルを用いたサービスを呼び出し、画像やテキストをベクトル化してWeaviateに保存したり利用する形をとっています。

上記のサンプルでは、特定のディレクトリ（images）に入れた画像をWeaviateに登録する処理（Goで書かれたコマンド）が用意されています。

フロントエンドでは、検索窓が用意されておりテキストを入力すると、画像が検索結果として出てくるデモです。

テキストを入力としてベクトル検索をするデモの部分はこれでよいのですが、今回はこれに加えてキーワードで検索できるようなデータが必要となります。

デモデータの準備

キーワード検索をするために、画像＋テキスト（しかも日本語がよい）ということで、いくつか物色した結果、採用したでものデータは次のものになりました。

MS COCOデータセット
日本語のキャプションデータ

MS COCOと呼ばれる、画像に対していくつかのメタデータを追加してあるデータセットが公開されています。追加されてデータは次のようなものになります。

オブジェクト（画像内の位置と移っているオブジェクトのカテゴリ名）
キャプション（画像に関する説明文が5つ）

ただし、キャプションデータはもちろん英語となっています。このデータに対して、千葉工業大学の研究センターの方が日本語でキャプションデータを生成したものを公開してくれています。

MS COCOの画像のうち商用利用可能なライセンスの画像を今回のデモ用に利用させていただきました。それぞれのファイルをダウンロードし、MS COCOの画像ファイル名をキーにして英語と日本語のキャプションデータを配列で持つようなJSONデータを生成し、それをもとにWeaviateにデータ登録する形です。

処理の内容は省きますが、上記のデータセットをもとに次のような1ファイル1JSONを作って、JSONLファイル（1行1JSON）として保存したものを読み込んでWeaviateに登録しています。

{
    "id": "200109",
    "license_id": "4",
    "license_name": "Attribution License",
    ...
    "filename": "COCO_val2014_000000200109.jpg",
    "date_captured": "2013-11-22 02:26:57",
    "caption_en": [
        {
            "id": "645817",
            "content": "A slice of pizza partially obscuring a cell phone."
        },
        ...
    ],
    "caption_jp": [
        {
            "id": "41320",
            "content": "食事をしながらメールチェックをする"
        },
        ...
    ],
    "category": [
        ...
    ]
}

英語のキャプションは登録はしましたが、今回のデモには利用しませんでした（日本語で検索できるところを見せたかったので）

スキーマの定義

上記のデータをもとに考えたWeaviateのスキーマは次のようなものになります。 Weaviateで利用できる日本語のトークナイザーのうち、GSEとKagomeを利用してデモをできるようにそれぞれをTokenizationに指定したフィールドをcaption_ja_gse、caption_jaとして用意しました。

画像からベクトルを生成して保存する定義は、Vectorizerという部分のmulti2vec-clipになります。実際に、画像からベクトルを生成するのは、multi2vec-clipという名前のコンテナで動いているCLIPのモデルを通して処理をします（コンテナ内部で動いている処理などはこちらで公開されています）。

multiModal := &models.Class{
		Class:       ClassName,
		Description: "Sample class holding all the images",
		ModuleConfig: map[string]interface{}{
			"multi2vec-clip": map[string]interface{}{
				"imageFields": []string{"image"},
			},
		},
		VectorIndexType: "flat",
		Vectorizer:      "multi2vec-clip",
		Properties: []*models.Property{
			{
				DataType:    []string{"string"},
				Description: "The name of the file",
				Name:        "filename",
			},
			{
				DataType:    []string{"string"},
				Description: "The Flickr URL",
				Name:        "flickr_url",
			},
			{
				DataType:    []string{"blob"},
				Description: "Base64 encoded image",
				Name:        "image",
			},
			{
				DataType:     []string{schema.DataTypeTextArray.String()},
				Description:  "Caption in English",
				Name:         "caption_en",
				Tokenization: models.PropertyTokenizationLowercase,
			},
			{
				DataType:     []string{schema.DataTypeTextArray.String()},
				Description:  "Caption in Japanese",
				Name:         "caption_ja_gse",
				Tokenization: models.PropertyTokenizationGse,
			},
			{
				DataType:     []string{schema.DataTypeTextArray.String()},
				Description:  "Caption in Japanese",
				Name:         "caption_ja",
				Tokenization: "kagome_ja", // TODO 1.28リリース時には定数を利用可能
			},
			{
				DataType:     []string{schema.DataTypeTextArray.String()},
				Description:  "Category in English",
				Name:         "category",
				Tokenization: models.PropertyTokenizationLowercase,
			},
		},
	}

あとは、GoのWeaviateのSDKを利用してデータを登録するだけです。登録処理はサンプルをもとに、上記のフィールドのデータを追加した程度です。

これで、Weaviateに日本語と画像のベクトルのデータが保存できました。あとは検索です。

検索処理

参考にしたサンプルでは、Node.jsで処理が書いてあるのですが、私自身はあまりNode.jsを記述したことがありません。ということで、さくっと作るためにStreamlitを利用して検索画面を作成しました。

コードはこちら

Weaviateの接続部分は簡略化（別の便利関数を作った）してありますが、流れはなんとなくわかっていただけるかな？

デモのできることとしては次のような検索です。

GSEのフィールドでキーワード検索
Kagomeのフィールドでキーワード検索
ベクトル検索（テキストをCLIPでベクトル化して検索）
ハイブリッド検索（ベクトル検索＋Kagomeフィールドでキーワード検索）
ベクトル検索＋Kagomeのフィールドでキーワードでフィルタリング

まとめ

駆け足ですが、Weaviateで日本語のマルチモーダル検索をやるときにどんなデモデータでどんなデモをやったかを紹介しました。完全なものではないので恐縮ですが。。。

Weaviate 1.28（2024/12現在最新版）からKagome JAという日本語のキーワード検索用のトークナイザーが利用できるようになっています。興味がある方は、ちょっと触ってみてはどうでしょうか？

もう少し時間が取れて整理整頓出来たら、Docker Composeなども含めた形でリポジトリで公開しようと思います。 Weaviateで動かしてみようとしたり、ブログで不明点などがあればXなどで連絡をいただければと。

Weaviateの日本語対応とマルチモーダル・多言語検索デモ

Wed, 11 Dec 2024 00:00:00 +0000

AI活用しきれていない話

Thu, 05 Dec 2024 15:00:00 +0000

この記事はpyspa アドベントカレンダー 2024の6日目です。

公私ともにAIを活用しきれてないけど、こんな感じで使いましたというお話です。

Elasticsearchのハンズオン

お客さん向けにElasticsearchのハンズオンを1時間 x 15回という形で提供しました。新しい人も入ってきたので慣れてもらうために、また、知ってる人もハンズオンすることで普段は触らない・知らない機能を触って刺激になってアイデアが浮かぶかもしれないしという感じのモチベーションです。

ただ、資料作成にそれほど時間をかけるのももったいないですよねとお客さんとの会話にも出たので、そういう時にこそAIでしょ！となり、使ってみました。

こんな感じで。

Google AI StudioのGeminiに壁打ちの相手してもらってるところだけど、賢いなぁ（驚き屋みたいになってるな） pic.twitter.com/swyvbTdYxt
— Jun Ohtani (@johtani) May 1, 2024

このツイートではGoogleのAI Studioを使っていますが、ChatGPTでも同じように作ってもらって、最終的にはChatGPTで最後の回までを作ってもらいました。プロンプトを工夫したりはできていないので、まだまだ使い切れてる感じはしないですが。。。

流れとしては、次のような感じで作ってもらいました。

15回で初心者向けのハンズオンの流れを考えてもらう
- 「Elasticsearchのハンズオンを15回程度で考えているところです。全文検索のユースケースを想定しています。カリキュラムを考えてみてください」
- 戻ってきた答えにはロギングなどのユースケースも混ざっちゃってたので何度かやり取りして直してもらいました
大体出来上がったらそれぞれの回のハンズオンについて詳しく書き下してもらいます
- 最初の流れでは、1行程度の説明しかなかったので、ここでそれぞれのハンズオンでの流れが出来上がります
あとは、個別にさらにいくつか会話をしていって、仕上げていきました
- 「図を用いて説明して」「手順を書いて」「Dockerを使う形のインストールだと？」

題材がElasticsearchということもあり、世の中に資料がたくさんあって学習されているようで、REST APIやクエリもなんとなく作ってくれます。おかげでハンズオン資料もそれなりの形にできたのではかどりました（出てきたクエリなどは個別に確認しますが、ざっくりした項目は上げてあるのであとは説明すればいい）。

ただ、Elasticsearchはバージョンアップも頻繁なので、「資料があふれている＝古いバージョンの書き方もある」という状況がよく起こります。私はある程度知っている内容なので、「ここがおかしい」「これは古い」という形で自分ですぐに修正が入れられるので良いのですが、知らない分野だとそれぞれの調査で時間がかかるだろうなぁという感じです。

慣れてる内容を再度まとめたり、文章を書いてもらってちょっと修正などは作業がすごく楽になって助かりました。

GoでSlackのボット作成（第2弾）

もう一つの使い方としてプログラムも書いてもらいました。こっちはうまく指示が出せずに失敗という感じになってしまいましたが。。。

3月に「続ける思考」を読んだ記事を書きました。で、本をちょっとずつ読んだり、ガンプラをちょっとずつ作ったりしています。それらの記録をつけるのに、Slackのボットを作ってみるか→じゃあ、AIに手伝ってもらいながらコーディング？という流れで、壁打ちしながらコードも書いてもらってみたのですが。。。

ペアプロってこんな感じなのだろうか？ pic.twitter.com/KWxYERNgX3
— Jun Ohtani (@johtani) May 1, 2024

G.W.に壁打ちしながらコードは書いてもらったんですが、実際にGoLandにもってきて動かそうとすると、まぁ、うごかないのです。。。（そもそもmainの関数なのにpackage mainになってないとか。。。）結局、お蔵入りして8月に骨格をもとにしながら最低限（Google Driveじゃなくてローカルファイルに保存）の実装にして動くようになって活用していますが。

反省点はこんな感じ

複数ファイルにまたがるような形で設計してもらおうとしたのがよくなかった
そもそも指示の出し方がよくない？（プロンプト書くのが下手？）
GitHub CopilotのようなIDEで使えるもののほうがよさそう（もってきて動かすのがめんどくさい）
テストとか書いてもらうのがいいのかなぁ？

もちろん、メリットもありました。

プロジェクト、プログラムの命名
- 「こんなプログラムを作りたいんだけど名前をいくつか考えて？」「もっと中二っぽい名前がいいな」という感じ会話をして10個くらい名前を考えてもらってそこから採用した
変数名、関数名などの命名
READMEの記述
REST APIのレスポンスJSONとかをもとに構造体作ってもらったり
書いてもらったプログラムの個々のパーツは書き方の参考になった

あとは、JetBrainsのAIアシスタントに課金はしていないのですが、GoLandの補完が賢くなっており、定型的なエラー処理やログメッセージなどを予測して補完してくれるのがすごく楽ですね。テストケース書く時もいい感じに補完してくれるのかしら？（書きなさいよテストケース）

まとめ

まだまだうまく使えてない自信があります（なんだそれ）。プロンプトを工夫したりなどはしていないので、なんとなく会話してもらってAIに壁打ちしてもらう形程度にしか使えてないと思っています。あとは、プログラミングでの活用も課金してたりはしていないので、試してみないとなぁ。

世の中的には、プロンプトエンジニアリング、RAG、エージェントRAG、グラフRAG、画像生成などいろいろ流行っていますが、なんとなく概念を知っているかな？くらいになっています。来年はRAGだとかエージェントRAGだとかをもっと触って使ってみたり作ってみたりしないとですね。（本も買って積んでるし。。。）

検索技術勉強会2024 Summerで司会しました

Thu, 31 Oct 2024 13:12:49 +0000

どーも、johtaniです。

Search Engineering Tech Talk 2024 Summerを10/10にビズリーチさんの新オフィスで開催し、また司会をしてきました。今年2度目になります。資料と録画をべ協会のページの資料のところにアップロードしてありますので、当日参加できなかった方、気になっている方は見ていただければと思います。

発表内容については資料などを見ていただくこととし、今回も運営周りでのメモを残しておこうかなと。司会はあいかわらず緩い感じだったので、もう少しちゃんとやらないと。。。

継続したいこと

スピーカーとSlackでやりとり

前回同様に、スピーカーの方たちに初手の連絡は、スピーカー登録フォームに記載していただいた連絡先に連絡を入れましたが、その後は、search-tech-jpのSlackでやり取りをさせていただき、スムーズにやり取りができました。スタッフとも共有しやすいので便利でした。発表当日の連絡や、その後の動画の確認などもこちらが使えるのは楽ですね。

検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff
— takuya-a (@takuya_b) March 31, 2021

会場へのアクセスのスライドを用意

会場提供をしていただいている方には少し負担になっているかもしれないですが、渋谷の新しいビルということもありスライドを用意してもらいました。オフィス入り口は商用のテナントとは別の入り口だったりするので迷子になることも多いと思います。私自身はスライドのおかげですんなり会場に到着できました。ほかの皆さんはどうだったんだろう？

名札を印刷

今回も次のツールを使って名札を印刷しつつ、ネームホルダーを用意してみました。懇親会で首からぶら下げていただいたのでよかったかな？

MasayaAoyama/connpass-nametag-generator： Connpass のイベント参加者の名札を生成するツール群

飲食提供をやめてみました

会場での飲食自体はOKだったので、おなかがすいた人は食べながら聞いてもらうのもありにしてみました。といっても、食事してる人はいなかったかも？懇親会にも結構な人が残っていただき大変盛り上がりました。今後もこれでいいのかもな。

改善点

録音環境の改善

録音したものを見ていただくとわかりますが、音がこもっています。スピーカーの方にGoogle Meetで入って画面共有してもらいつつ録画し、私のノートPCのマイクだけをONにして録音してみました。録画自体は会場のWi-fiをスピーカー限定で利用したので途切れたりすることもなくきれいに録画できていました。

ただ、音に関してはノートPCのマイクだから＋圧縮されたりノイズキャンセル機能が動いていたりで少しこもった感じがしています。会場のマイク経由での音はそれなりに拾えていますが、マイクなしでの声や拍手は入っていなかったりです。

携帯できるマイクもあったので、次回は持って行って再チャレンジかな？みんなどうしているんだろう？この辺のノウハウが足りないし、3か月に1度の開催なので身についてない気がする。

Summer?Fall？

Summerという名前を付けてしまいましたが、当日は寒かったかもなぁ。。。

そのほか

connpassのQRコード読み取りを活用

参加者の管理と受付 — connpassご利用ガイドドキュメントにあるQRコードを利用した受付をしました。私自身は受付をしてないので、スムーズだったかどうかは定かではないのですが、受付人数の確認がものすごく楽です。名札を印刷しているのもあるので、参加者数は把握できるのですが、実際にどなたが来ていたのか？などがすぐにわかるのは大変便利ですね。 Connpassの開発者の方ありがとうございます！

まとめ

話をしていただいたスピーカーの皆さん、参加していただいた参加者の皆さん、会場を提供していただいたビズリーチさん、準備で奔走してもらったスタッフの皆さん、ありがとうございました。おかげさまで今回も楽しめました（自分が楽しむために開催してます）。そのあと風邪をひいてしまったのでブログや録画の公開が遅くなってしまい申し訳なかったです。

さて、次回も3か月後くらいに開催できるようにスピーカー探し頑張らないとな。スピーカーおまちしております！（スピーカー登録フォーム）

OpenSearchのderivedフィールドタイプについて

Wed, 24 Jul 2024 04:55:34 +0000

Derivedフィールドタイプとは、OpenSearch 2.15から導入された新しいフィールドタイプです。

以下の記事は、2.15.0のドキュメントおよびOpenSearchを利用して確認した内容になります。

どういうもの？

既存のフィールド（_sourceのフィールドもしくはdoc valuesから）新しいフィールドを「動的」に作成できます。 derivedフィールドタイプを利用できるできないの設定が用意されており、不要であればオフにすることも可能です。デフォルトでは利用可能な状態になっています。

スクリプトを定義して、元のフィールドから特定の箇所の文字列などを抜き出し、特定の型（dateとかlongとか）として扱えるようにします。例えば、date型の場合はformatを指定することで、日付文字列としてパースしたりといった具合です。

なにができるの？

通常、OpenSearchの検索条件に利用するフィールドは指定されたフィールド型でインデックスに登録され、検索用のデータ構造が生成されている必要があります。これは、データ登録を行う時点でどんなデータがあり、どういった検索をしたいか？というのを決めておく必要があるということです（Schema on Write）。例えば、ログなどを保存しておいて解析したい場合に、あらかじめ、ログ文字列から必要な情報（日付、サーバ名、IPアドレス、ユーザID、サービス名など）を抜き出してインデックスイン登録してあげる必要があるということです。あとから、ログ文字列の中から特定の項目を取り出して検索したい場合は、これまでの場合はスキーマにフィールドを追加してから、データの再登録（再インデックス）を行う必要がありました。

このderived fieldを利用することで、データ登録時ではなく、データ利用時にデータをパースしながら検索できるようになります（Schema on Read）。あらかじめデータを切り出して保存する必要がないため、保存しているデータ量の削減ができます。その代わり、検索時に毎回パース処理が実行されるため検索時のコストが増えます。

derived fieldを定義する方法は2つ用意されています。

インデックスのマッピングに定義する
検索リクエストで定義する

derivedフィールドの利用方法も現時点では2種類あります。

検索条件のフィールドとして利用
検索結果のデータに含めるフィールドとして利用

データ登録時点ではスキーマが決まっている必要がない
- 通常、検索や集計に利用する場合は、登録時にスキーマ（フィールドの型）が決まっている必要がある
prefilter_fieldを指定することで、元のフィールドを用いた絞り込みを実行できる
- Prefilter field / Derived - OpenSearch Documentation

前提条件

前提条件として、derivedの対象とする元のフィールドは以下を満たす必要があります。

_sourceもしくはdoc valuesが存在する（元データを取り出す必要があるため）
- スクリプトを利用してデータを抜き出すから
search.allow_expensive_queries: trueが設定されている（クラスターの設定）
- 処理が重くなるので、コストのかかるクエリがオフの設定の場合は動作しない仕組みとなっている（ソースコード）
derivedが利用可能になっている
- cluster/indexレベルでそれぞれオンオフの設定がある(どちらも動的設定)
  - indexレベル：index.query.derived_field.enabled
  - clusterレベル：search.derived_field.enabled
パフォーマンスに関する考慮が必要
- 参考：Performance節

何ができないの？

制限事項がいくつかあります。

Aggregationやスコアリング、ソートにはまだ未対応（対応する予定がありそう（[META] Derived Fields #12281））
OpenSearch Dashboardの表示には未対応。フィルタリングは仕組みを知っていれば利用できる
derived fieldに対して、2つ以上のパースの設定はできない
join field typeは未対応
concurrent segment searchには未対応

データはどういう持ち方なの？

derived field自体はデータを持っているのではなく、次のような情報を定義する。

type : scriptでパースした後のデータの型を指定
script : フィールドのデータを作り出すためのスクリプト。基本的には元になる別のフィールドを使って、パースする処理となる

あとは、typeに合わせていくつかのオプションがあるが詳細はparametersを参照。

動作としては、検索時に検索対象となるデータに対して、scriptを実行してtypeに変換し、typeごとに対応するクエリの処理が実行され、derived fieldのクエリにヒットするかどうかの判定が行われる。あくまでも検索時に実行される処理となるため、データ登録時には特にエラーなどは起きない。

ignore_malformedというオプションが用意されており、クエリ実行時にエラーがある場合はそのデータを無視するオプションが用意されています（詳細は後述）。

実際に検証してみる

公式ドキュメントに簡単なサンプルが用意されており、それを試してみることで簡単な動作の確認ができます。ただし、次のような場合にどんな挙動になるのか？というのが気になったので確認してみました。以下のサンプルとして提示するクエリはOpenSearch Dashboardで実行できる形式を模しています（私自身はVS CodeのRest Client拡張を普段利用しているのでそこから編集して転記しています）。

一部のデータに参照している元のフィールドがない場合にどうなるのか？
一部のデータがパースに失敗する場合はどうなるか？
上記のようなパースに失敗するデータがある場合に、それ以外のデータだけを対象とするような条件とderived fieldを利用した場合はどうなるか？

1. 一部のデータに参照している元のフィールドがない場合にどうなるのか？

公式ドキュメントのサンプルにあるデータは必ず対象となるフィールド（request）にデータが入っています。対象となるフィールドがあったりなかったりする場合もあると思いますが、その時にどういう扱いになるかを確認します。公式ドキュメントのサンプルインデックスに次のデータを追加します（公式ドキュメントのExample Setupから「Searching derived fields defined in index mappings」まで1度実施済みとします）。

PUT /logs/_doc/8
{ 
  "clientip": "61.177.2.0" 
}

データ登録時には特に何も言われません。derivedフィールドはデータ登録時には動作しないためです。

まずは、「検索結果のデータに含めるフィールドとして利用」するサンプルです。検索リクエストで、fieldsパラメータにderivedフィールドを含めた全件検索を実施します。

GET /logs/_search
{
  "fields": ["request", "clientip", "timestamp"]
}

実施後のレスポンスにはエラーが出てきています（抜粋）。

{
  "error": {
    "root_cause": [
      {
        "type": "script_exception",
        "reason": "runtime error",
        "script_stack": [
          "org.opensearch.index.fielddata.ScriptDocValues$Strings.get(ScriptDocValues.java:555)",
          "org.opensearch.index.fielddata.ScriptDocValues$Strings.getValue(ScriptDocValues.java:571)",
          "emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[0]))",
          "                                          ^---- HERE"
        ],
        "script": "emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[0]))",
        "lang": "painless",
        "position": {
          "offset": 42,
          "start": 0,
          "end": 71
        }
      }
    ],
    "type": "search_phase_execution_exception",
    ...
    ]
  },
  "status": 400
}

同様に、クエリにderivedフィールドを利用する方法も試します。


GET /logs/_search
{
  "query": {
    "range": {
      "timestamp": {
        "gte": "1970-01-11T08:20:30.400Z",   
        "lte": "1970-01-12T08:26:00.400Z"
      }
    }
  },
  "fields": ["request", "clientip"]
}

こちらも同様のエラーが出ます。 scriptが動作した時に対象データがrequest.keywordというフィールドを持っていないためにエラーとなります。

公式ドキュメントのパラメータに、先ほども説明したignore_malformedというオプションがあります。マッピングの修正用のリクエストです。デフォルトでは、ignore_malformedはfalseになっているのでそれぞれに追加します。

PUT /logs/_mapping
Content-Type: application/json

{
  "derived": {
    "timestamp": {
      "type": "date",
      "format": "MM/dd/yyyy HH:mm:ss",
      "script": {
        "source": "emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[0]))"
      },
      "ignore_malformed": true
    },
    "method": {
      "type": "keyword",
      "script": {
        "source": "emit(doc[\"request.keyword\"].value.splitOnToken(\" \")[1])"
      },
      "ignore_malformed": true
    },
    "size": {
      "type": "long",
      "script": {
        "source": "emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[5]))"
      },
      "ignore_malformed": true
    }
  }
}

上記を実行後、先ほどの2種類（fieldsに指定する利用方法、クエリに利用する方法）を試してみると、クエリを利用する方法（rangeクエリ）については、フィールドが存在しないデータ以外のデータが検索に返ってくることがわかります。ただ、残念ながら、fieldsに利用したクエリについては、同じエラーが出てしまいました。ドキュメントのignore_malformedの説明には以下のような記述があります。

A Boolean value that specifies whether to ignore malformed values when running a query on a derived field.

残念ながらクエリの処理についてのみ対象としているのかもしれないですが、バグなような気も。。。（あとでIssue作っておくかな）

回避する方法についてはエラーにヒントが含まれています。上のエラー例では省略しましたが、次のようなメッセージがエラーに含まれていました。

  "type": "illegal_state_exception",
  "reason": "A document doesn't have a value for a field! Use doc[<field>].size()==0 to check if a document is missing a field!"

公式のサンプルでは、簡略化もかねてなのかscriptの処理でいきなりemit()を呼び出していますが、安全のためにフィールドの存在確認をするほうがよいでしょう。ということで、上記のチェック処理を入れたサンプルは次の通りです。 emit()の処理の外側にif文でフィールドのデータのサイズが0ではない（フィールドが存在する場合）という条件を記述することで、フィールドが存在しない場合は処理がなくなる仕組みとなります。

### インデックスマッピングでderivedを定義(ignore_malformed:trueかつフィールド存在チェック処理追加)
PUT /logs/_mapping
{
  "derived": {
    "timestamp": {
      "type": "date",
      "format": "MM/dd/yyyy HH:mm:ss",
      "script": {
        "source": "if(doc[\"request.keyword\"].size() != 0) {emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[0]))}"
      },
      "ignore_malformed": false
    },
    "method": {
      "type": "keyword",
      "script": {
        "source": "if(doc[\"request.keyword\"].size() != 0) {emit(doc[\"request.keyword\"].value.splitOnToken(\" \")[1])}"
      },
      "ignore_malformed": false
    },
    "size": {
      "type": "long",
      "script": {
        "source": "if(doc[\"request.keyword\"].size() != 0) {emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[5]))}"
      },
      "ignore_malformed": false
    }
  }
}

上記の修正後はエラーになっていたfieldsを指定するリクエストに関してもエラーにならなずに検索結果が返ってくるようになります。 request.keywordのないデータは検索結果にはtimestampは含まれていません。

{
        "_index": "logs",
        "_id": "8",
        "_score": 1.0,
        "_source": {
          "clientip": "61.177.2.0"
        },
        "fields": {
          "clientip": [
            "61.177.2.0"
          ]
        }
      }

2. 一部のデータがパースに失敗する場合はどうなるか？

フィールド自体が存在しない場合は検証しました。次は想定していないデータが対象となるフィールドに存在する場合について考えます。

フィールド自体が存在しない場合は検証しました。次は想定していないデータが対象となるフィールドに存在する場合について考えます。 1.で登録したデータや変更などを一度削除して、公式ドキュメントのサンプルインデックスに次のデータを追加します（公式ドキュメントのExample Setupから「Searching derived fields defined in index mappings」まで1度実施済みとします）。

PUT /logs/_doc/7
{ 
  "request": "hoge GET /english/images/france98_venues.gif HTTP/1.0 200 778", 
  "clientip": "61.177.2.0" 
}

1.の時と同様に、データ登録時には特にエラーなどは出ませんが、検索時に登録したデータが処理されるとエラーがでます。

GET /logs/_search
{
  "fields": ["request", "clientip", "timestamp"]
}

1.とは異なり、フィールド自体は存在しますがパース処理で失敗するため、次のようなエラーになります。

{
  "error": {
    "root_cause": [...
    ],
    "type": "search_phase_execution_exception",
    "reason": "all shards failed",
    "phase": "query",
    "grouped": true,
    "failed_shards": [
      {
        "shard": 0,
        "index": "logs",
        "node": "gKwPMrF9SHSfoNzKdMSWoA",
        "reason": {
          "type": "script_exception",
          "reason": "runtime error",
          "script_stack": [
            "java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)",
            "java.base/java.lang.Long.parseLong(Long.java:709)",
            "java.base/java.lang.Long.parseLong(Long.java:832)",
            "emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[0]))",
            "                                                                  ^---- HERE"
          ],
          "script": "emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[0]))",
          "lang": "painless",
          "position": {
            "offset": 66,
            "start": 0,
            "end": 71
          },
          "caused_by": {
            "type": "number_format_exception",
            "reason": "For input string: \"hoge\""
          }
        }
      }
    ]
  },
  "status": 400
}

caused_byの部分で「hoge」という文字列をLong.parseLong()で処理しようとしてエラーが出ていることがわかります。

こちらも1.と同様に、"ignore_malformed": trueを付与すると、検索クエリで該当データが出てきた場合はエラーが無視されてそれ以外のデータが検索結果に帰ってくるようになりますが、 fieldsに指定した場合はエラーになります。

次のようにtry-catchで例外発生時には値を返さない処理を追加するとエラーなく検索できるようになります。もちろんエラーの出るデータについては検索結果には出てきません。

PUT /logs/_mapping
{  "derived": {
    "timestamp": {
      "type": "date",
      "format": "MM/dd/yyyy HH:mm:ss",
      "script": {
        "source": "if(doc[\"request.keyword\"].size() != 0) {try{emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[0]))} catch(NumberFormatException e) {return}}"
      },
      "ignore_malformed": false
    },
    "method": {
      "type": "keyword",
      "script": {
        "source": "if(doc[\"request.keyword\"].size() != 0) {emit(doc[\"request.keyword\"].value.splitOnToken(\" \")[1])}"
      },
      "ignore_malformed": false
    },
    "size": {
      "type": "long",
      "script": {
        "source": "if(doc[\"request.keyword\"].size() != 0) {try{emit(Long.parseLong(doc[\"request.keyword\"].value.splitOnToken(\" \")[5]))} catch(NumberFormatException e) {return}}"
      },
      "ignore_malformed": false
    }
  }
}

3. 上記のようなパースに失敗するデータがある場合に、それ以外のデータだけを対象とするような条件とderived fieldを利用した場合はどうなるか？

derivedフィールドは検索時に処理が実行されます。ということは、1.や2.でエラーとなるデータを追加していても、そのデータが含まれない検索条件で検索した場合はエラーが出ないと想定されます。こちらも確認してみましょう。

まずは、公式ドキュメントのサンプルデータの状態に戻します。公式ドキュメントのサンプルインデックスに次のデータを追加します（公式ドキュメントのExample Setupから「Searching derived fields defined in index mappings」まで1度実施済みとします）。次に、1.と2.のデータを追加します。

PUT /logs/_doc/7
{ 
  "request": "hoge GET /english/images/france98_venues.gif HTTP/1.0 200 778", 
  "clientip": "61.177.2.0" 
}

PUT /logs/_doc/8
{ 
  "clientip": "61.177.2.0" 
}

この状態だと、次の検索ではエラーが発生します。これまで説明したとおりです。

GET /logs/_search
{
  "fields": ["request", "clientip", "timestamp"]
}

例外の発生するデータがヒットしないクエリを追加して実行するとエラーなく結果が返ってきます。

GET /logs/_search
{
  "query": {
    "bool": {
      "must_not": [
        {
          "ids": {
            "values": [7,8]
          }
        }
      ]
    }
  },
  "fields": ["request", "clientip", "timestamp"]
}

まとめ

新しく追加されたderivedフィールドについて簡単に調べてみました。きれいなデータであればスクリプトもシンプルですみますが、検索時にエラーが出ないようにする場合は、きちんと各所でチェックを入れるスクリプトの書き方が重要になってくるかと思います。とくにignore_malformedの挙動が検索クエリの時のみに限定されているので、安全なスクリプトにするほうが良いと思います。

また、インデックスのmappingsにderivedフィールドを定義する場合は、定義のタイミングではコンパイルなどはされないため構文エラーなどの発生もすべて検索するタイミングとなります。さらに、後から来たデータでエラーになることも考えられますので、利用するのは注意しながらがよいかなと思います。

ただ、これまでよりも柔軟にデータ登録してあとから検索を考えるなどができるので便利になりそうですね。

残課題

JSONオブジェクトをderivedフィールドに指定する例もドキュメントにあるのでそれの使用感
大量データを入れて、速度的にどのくらい影響が出るのか？
- prefilter_fieldを使うといい感じになりそうか？
検索時にエラーにならないスクリプトの書き方の説明をしたが、エラーになるようなデータがあるかどうかを調べるにはどうするか？
derivedフィールドが使えないバージョンで作成したインデックスに対してderivedフィールドを作ろうとするとどうなるのか？
- おそらくエラーになると思われる。ローカルでインデックス作ってデータを入れて、バージョンアップをして検証してみる？

検索技術勉強会2024 Springで司会しました

Sat, 01 Jun 2024 13:31:37 +0000

どーも、johtaniです。

Search Engineering Tech Talk 2024 Springを5/31にLegalOn Technologiesさんの新オフィス（渋谷サクラステージ）で開催し、司会をしてきました。昨年末の12月に4年ぶりの復活開催から2回目（計6回目）となります。フリーランスになってからこういう場で司会をしたのは初めてかも？

前回は諸事情で裏方スタッフとして手伝っていましたが、今回はオープニングと司会をやってきました。ひさびさにオフラインで人前でしゃべったので、ちょっとグダグダ感が出てしまったかもですが、面白い話をいろいろ聞けて楽しかったです。

今回（前回も含め）はいくつか新しい試みも行ったので自分用のメモとして記録しておこうかなと（セッションの感想などは参加者の皆さんにおまかせします！）。

新しい試み

スピーカーとの連絡方法

スピーカー登録については、知り合いに声をかけてみたり、勉強会のページに用意してあるGoogleフォームで登録をしてもらっています。こちらのGoogleフォームに登録されると、メールやTwitterでコンタクトをとり、今回の開催で日程が合うかどうかを調整しています。

実際に登壇していただく形になったあとに、前回からはsearch-tech-jp（以下のツイートから参加可能なはず）のSlackでプライベートチャンネルを作って連絡をするようにしています。個別に連絡するよりもスタッフの誰かが反応できるようになっているので便利になったかなと。

検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff
— takuya-a (@takuya_b) March 31, 2021

会場へのアクセススライドを用意してもらった

新しいビルでかつ新しいオフィス（すごくかっこいいオフィスエントランスだった！）ということもあり、入り口がわかりにくいかも？という話が事前のスタッフ打ち合わせで出ました。他社のブログに写真付きでオフィス受付ロビーへの案内を作られているものがあったのですが、さすがに流用するのもわるいですよね？ということになり、スタッフでLegalOn Technologiesの方にスライドを作成していただきました（案内スライド）。

そのうち会社としてアクセスのわかりやすいページなどもできると思いますが、わかりにくい入り口などの場合はこういうのを用意すると便利かもなと。

当日は何人かLegalOn Technologiesのかたに誘導役として経路に立っていただいたので、そちらもわかり安かったのではないかなと思っていますがどうでしょう？（感想聴くの忘れてた。。。）

名札を印刷して持って行った

懇親会で交流してもらいやすくするために次のリポジトリで公開されている名札生成ツールを利用させていただきました。

MasayaAoyama/connpass-nametag-generator： Connpass のイベント参加者の名札を生成するツール群

できたものはこんな感じ（名札に入れた写真を撮り忘れた。。。）。

さてと。便利なツールありがとうございます！https://t.co/Q0r84v0ZDp pic.twitter.com/IcSQRZtVf6
— Jun Ohtani (@johtani) May 31, 2024

当日に印刷して裁断して持参しました。アイコンが登録してあると見やすくていいですね。

スタッフ、スピーカーについては参加者一覧には出てこなかったため、別途追加して印刷するところだけは次回以降も忘れないようにしないとかな。（うまくやれば、Connpassの参加者一覧としてダウンロードできるCSVにスタッフやスピーカーも追加できたりするのかな？）

LTもあり

前回まではスピーカーに登録していただくのは25分のセッションのみとしていました。ただ、これだと初めての方やちょっとしたこと（ちょっと困ってること、こんなこと試してみたよ）を話したい方にはハードルが高いかもしれないなと。あと、LTあればスピーカーするのにという声も見かけました。

当日参加のLTではありませんが、スピーカー登録フォームにLT枠も設けてみました。実際に今回はLTを2本用意していただくことができましたし、いろいろな話題も含められそうだなと。

事前の調整などもあるので今後も当日飛び込みのLTの予定はないですが、LT枠への募集は行っていく予定です。

懇親会が1.5h

今回は開始時間を19時からとしたため、懇親会の時間を長くとることができました（ちょっと懇親会の準備に手間取ってしまいましたが）。そのため、いつもよりもスピーカーや参加者の皆さんの間で話が弾んだんじゃないかな？と思っています。どうだろう？

改善点

いくつか改善できるかも？という点もあるのでこちらもメモを。

名札の配り方

オフィスに入るためにセキュリティゲート前に受付を用意し、記名と引き換えにQRコードを渡して会場まで来ていただき、会場の後ろの机に名札を広げておいて置く形にしました。

印刷したあとで気づいたのですが、受付票にある番号も名札に印刷しておくと名札を受付で渡せたのかもしれないな？と思いました。効率よく名札をつけてもらいつつ入ってもらうのにはどうするのがいいのかなぁ？悩ましいところです。番号あったほうがいいのかな？

スピーカーとのファーストコンタクト

Googleフォームで入力してもらったX（旧Twitter）あてに連絡を入れようとして、フォローされていない方にDMが打てないことがありました。連絡がつかないとしょうがないので、メンションをしたのですがそれでも返信がもらえずに連絡取れないという状況になっていたりします。

メールアドレスのみにするか、search-tech-jpのSlackに登録してもらい、そのアカウントを記入していただくようにしてSlack上でDMをやり取りをしたほうがいいのかもしれないと考えているところです。

事前にSlackに登録していただく必要が出てきてしまうとスピーカー登録のハードルが上がってしまわないかが心配ですが、連絡が取れないよりはいいのかなぁ？どうしたものか。

とりあえず、GoogleフォームにSlackへの導線とSlackアカウントでもOKという記載をして試してみるのがいいのかもな。

開始時間

19時開始となったために、キャンセルしてしまった方とかいるかどうか？というのはちょっと気になる所です。スタッフのみんなにもセッションを聞いてもらいたいので、受付は基本的に勉強会開始のタイミングで閉じるようにしているので。できれば遅いほうがいいなどの意見があるようだったら聞いてみたいけど、そういう人はいたのだろうか？次回開催時にアンケートみたいなのをとるのがいいのかなぁ？

まとめ

話をしていただいたスピーカーの皆さん、参加していただいた参加者の皆さん、会場やフードを提供していただいたLegalOn Technologiesさん、準備で奔走してもらったスタッフの皆さん、ありがとうございました。おかげさまで今回も楽しめました（自分が楽しむために開催してます）。

いくつかチャレンジしてみたこと、チャレンジしてみたいことまだまだありますが、次回の改善につなげられればいいなということでメモを残してみました。

3ヶ月ごとに1度が目標なので、スピーカーや会場探しを次回に向けてがんばらないとなー。

今後も定期的に開催したいので、スピーカー登録、会場やドリンクスポンサー登録をお待ちしております！

デイリールーティーン（その後）

Fri, 05 Apr 2024 07:36:45 +0000

「続ける思考」を読んだのブログで追加しようと思っていることをいくつか挙げていました。

あれから2週間たったので記録として。

今のルーティーン（＋追加できたこと）

今のルーティーンはこんな感じです。歯磨き読書までは午前中（起きて仕事前）に必ずやってますが、それより後の項目については、仕事の様子なども見ながら、午前中だったり午後だったり、仕事が一区切りついてからやっているので、タイミングはまちまちです。

ヤクルト飲んで体重計
歯磨きしながら読書（今はリモートワーク大全読んでる）
アニメ見ながらorゲームしながら30分ほどフットステップ
フットステップ後にストレッチ（4種類）（※）
マンガのスキャン（1日1冊）（※）
スキャン後にプラモデル1コマ（※）

※が最後についている、後半3つが追加でき継続できています。

プラモはこちらのツイートに返信していってます。時々ツイート忘れちゃうので、「昨日」になってたりするけど。ここまでは2週間続いてます。まぁ、忘れないようにこれからも続けていければと。

昨日のプラモ。 pic.twitter.com/9Hfl8ASXKR
— Jun Ohtani (@johtani) March 23, 2024

追加で来てないこと

追加しようと思ってできていないのがこちら。

MediumのDaily Digestを読む
Software Designを読む
Factorio
ブログ書く

さて、どうやって入れようかなぁ？

ちょっと別の作業もかねて、LiteLLMを使って英語を翻訳してみたりしていたので、 MediumのDigestなどはこれを使って、翻訳＋要約させてストレッチのあととかに差し込むのがいいかも？

Factorioの代わりに風来のシレンは続いているかも？毎日じゃないけど。 Factorioはセーブデータが大きくなってるのもあり、起動に時間がかかるのでちょっとやるみたいなのに向かなくなってるから、なんか考えないとなぁ。

あとは、「Software Designを読む」などは、ルーティーンに組み込もうとして忘れてしまっているので、どうやって思い出せる仕組みにするかを考える必要がありそうです。 Google KeepとかSlackのリマインダー使うといいのかなぁ？時間は固定しないけれど、思い出す仕組みってほかになにができるだろうか？という感じで、悩み中です。

記録のつけ方

歯磨き読書の記録は前回書いたJourneyにつけています。プラモデルはツイートしてる感じです。日々やったことは、PCで起動しているVS Codeのメモを4年くらいつけているので、それに書いている感じです。ただ、やはり、スマホでSlackに投げ込む仕組みを書こうかなぁと考えているところです。 Journeyに課金をしていないのもあり、検索ができない不便さもあるので。。。

ということで、現状でした。毎週これについてブログ書くと、ブログを書くことも続けられて一石二鳥かもなぁ。

「続ける思考」を読んだ

Fri, 22 Mar 2024 09:11:10 +0000

「続ける思考」という本を読みました。続けるのが結構苦手だし、やろうかな？と思ってることで積んであるものがいくつかあったしということで。

Amazon | 「やりたいこと」も「やるべきこと」も全部できる！続ける思考 | 井上新八

読了して簡単な感想をツイートしたのがこちら。

「続ける思考」読み終わった。なにかとセットにしてやることで、継続しやすくなるとのことだったので、朝歯磨きしながらこの本を読んでた。
読みやすい本でわかりやすかった。
歯磨きしながらの読書のほかにもいくつかルーティーンに組み込んでみよう。https://t.co/nNdbG9HG28
— Jun Ohtani (@johtani) March 21, 2024

とても読みやすく、サクッと読めました。「毎日やること」、「なにかとセットにすること」というのがいいとのことだし、実践しないと続かないよなということで、毎日続けていこうかなぁと思っているルーティーンを記録しておこうかなと。

ルーティーン

とりあえず、数日前から始めたことを。仕事前にやってることになります。とりあえず1週間は続いたかな？

起きたらヤクルトを飲んだら体重計に乗る
朝食後に、歯磨きをしながらちょっと読書する
- 「続ける思考」を読んでる途中で思いついて始めました。今はリモートワーク大全（積んどくしてあったやつ）を読んでいます。
アニメ見ながらorゲームしながら30分ほどフットステップ
- 「ダンジョン飯」とかを録画しているので、ついでにということで。ゲームは「風来のシレン」

（お約束のアフィリンク貼っておきますね）

Amazon | リモートワーク大全電子書籍: 壽かおり: Kindleストア

Amazon | ダンジョン飯 1巻 (HARTA COMIX) | 九井諒子 | 青年マンガ | Kindleストア

Amazon | 不思議のダンジョン風来のシレン6 とぐろ島探検録 -Switch : ゲーム

追加しようと思ってること

まだ、どのタイミングにしようかは悩んでいますが、ルーティーンに追加しようとしていることがいくつかあります。

プラモデル
- ちょっとずつやるってことで、1日1マス？手順？を昼食後とかにやろうかな？
マンガのスキャン
- 本棚があふれてきたので。。。1冊ずつ
ストレッチ
- フットステップの後に入れるといいかな？
MediumのDaily Digestを読む
- これは、仕事前に入れたいな
Software Designを読む
- 定期購読してるけど、読んでない記事が大量にあるので。。。これも仕事前？
Factorio
- ダラダラやっちゃうから時間を決めてすこしずつ進めていくのがよさそう。次はここまでとか、これをやるみたいなメモを残しつつ。
ブログ書く
- 気を抜くと間が空いちゃうので。。。

とりあえず、「やりたいこと」が優先されてるような感じになってますが。ほかにも慣れてきたらちょっとずつ追加していく感じかなぁ？

記録のつけ方をどうしようかな？

仕事などでPCの前で作業している場合は、VS Codeに簡単な作業メモのようなものをつけています。本当に簡単なメモをGoogle Driveに月ごとのファイルで。

ただ、読書したりアニメ見たりしたとき、外出してるときなどのログを残すのにスマホで何かできないかなぁと。 iPhoneだとジャーナルアプリがあるようなのですが、Androidユーザーなのでほかのツールを探しています。

欲しい機能、やりたいことは今のところこんな感じ。

タイムスタンプ付きでメモをとれる
サクッと起動して書ける
記録する内容ごとにタグのようなものが付けられる
画像が貼り付けられる（読んだ本の表紙とか、組み立てたプラモとか）

とりあえず、Journeyというツールをインストールして試用中という感じです。無料の範囲で使ってるので、エクスポートとかはできなそうだけど。

Slackに種類＝チャンネルって感じで投げ込んで、ボットで収集するとかもありかもなぁ？Slackの使い方としてちょっと変かもだけど。

みんなはこういうログ、記録とかどうやってつけてるんだろうか？

まとめ？

ということで、続くといいですね（続けるぞ？ｗ）

【4/5】追記：続きをかいた

Elasticsearchの新しいJavaクライアント（2024年3月版）

Thu, 21 Mar 2024 06:55:57 +0000

以前、Elasticsearchの新しいJavaクライアントについてブログを書きました。

あれから、ほぼ2年経ちましたが、差分を調べたのでブログに残しておきます。

前回の問題点

前回のブログを書いている時点では、2点ほど気になることがありました。それぞれ解決しているので、まずはその紹介をしようと思います。

どんなリクエストを投げているかが不明

Elasticsearchの公式ドキュメントでは、各エンドポイントやクエリの書き方の紹介では、JSONのサンプルが紹介されています。自分で書いたリクエストが想定した形になっているか？、プログラムで書いたクエリがJSONだとどんな形になっているか？というのを確認したくなります。前回記事を書いた時点では、JSON文字列にするためにJsonGeneratorを利用していくつか処理を書く必要がありました。こんな感じに。

    private void printRequestBodyJsonForDebug(RequestBase request) {
        //for debug
        Logger.log("** Debug print start **");
        StringWriter writer = new StringWriter();
        SimpleJsonpMapper mapper = new SimpleJsonpMapper();
        JsonGenerator generator = mapper.jsonProvider().createGenerator(writer);
        mapper.serialize(request, generator);
        generator.close();
        Logger.log(writer.toString());
        Logger.log("** Debug print finish **");
    }

v8.3から、各種RequestクラスにtoString()メソッドが実装され、簡単にJSON文字列が取り出せるようになっています。

    private void printRequestBodyJsonForDebug(RequestBase request) {
        //for debug
        Logger.log("** Debug print start **");
        Logger.log(request.toString());
        Logger.log("** Debug print finish **");
    }

実際の出力内容は次のようになります。

PutIndexTemplateRequest: PUT /_index_template/wikipedia-index-template {"index_patterns":["wikipedia-*"],"template":{"mappings":{"properties":{"images":{"type":"nested","properties":{"target_type":{"type":"keyword"},"link_target":{"type":"keyword"},"taget":{"type":"keyword"},"text":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}},"analyzer":"kuromoji"}}},"contents":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}},"analyzer":"kuromoji"},"headings":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}},"analyzer":"kuromoji"},"links":{"type":"nested","properties":{"link_target":{"type":"keyword"},"text":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}},"analyzer":"kuromoji"}}},"id":{"type":"keyword"},"categories":{"type":"keyword"},"title":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}},"analyzer":"kuromoji"},"revision_id":{"type":"keyword"},"timestamp":{"type":"date"}}},"settings":{"number_of_shards":"3","number_of_replicas":"0","refresh_interval":"0"}}}

最初にクラス名: があり、移行がKibanaのDev Toolですぐ使える形式になっています（リクエストボディのJSONの前で改行するだけ）。デバッグや確認などが簡単にできそうですね。

変更された時のPull Requestは次のものになります。

Add toString() implementations by swallez · Pull Request #269 · elastic/elasticsearch-java

プラグインなどで提供されるクエリが書けない

Elasticsearchはプラグインを使って拡張することができ、LtRプラグインなどでは、クエリの拡張が行われています。

以前調査したタイミングではelasticsearch-specificationで定義されたリクエストしか受け取れない実装になっていました。 v8.5（実際には8.4.xにバックポートされている）からは、プラグインなどが追加しているクエリなどのカスタムな記述ができるようになっています。

_custom()というメソッドが各所に追加されており、これを利用することで定義にないJSONの属性などが追加できるようになっています。公式ドキュメントにも利用方法が追加されています。

Variant types | Elasticsearch Java API Client ［8.12］ | Elastic

レスポンスでも同様に_custom()が追加されており、プラグイン独自のレスポンス形式などにも対応できます。

変更された時のPull Requestは次のものになります。

Add support for plugin-defined custom components in union types by swallez · Pull Request #370 · elastic/elasticsearch-java

それ以外に変更されたポイント

各バージョンで導入された変更点がリリースハイライトとしてドキュメントにまとめてあります。いくつかピックアップして簡単に紹介します。

BulkIngesterヘルパーの追加（8.7）

Bulk APIをより楽に利用することができるヘルパークラスです。Pythonのクライアントにあったstreaming_bulkなどに似ています。どのくらいの数・サイズの操作をまとめて送るか、定期的にrefreshするのか？などを設定してインスタンスを作った後は、インスタンスにadd()していくと、指定されたタイミングで定期的にBulkのリクエストを送信してくれます。自分でループを回しながら定期的にAPIをたたくよりも便利です。詳細についてはドキュメントがあるので参考にしてください。

Bulk： indexing multiple documents | Elasticsearch Java API Client ［8.12］ | Elastic

OpenTelemetry対応（8.10）

OpenTelemetryを利用してトレースすることができるようになっています。JavaクライアントからEsへのHTTPのリクエストの処理時間やリクエスト本体をスパンに含めてくれるようになっています。自分たちのプロジェクトがOpenTelemetryを利用していれば、Esのリクエストに関連する部分が追加でとれるようになっています。詳細は公式ドキュメントに利用方法が記載されています。

Using OpenTelemetry | Elasticsearch Java API Client ［8.12］ | Elastic

まとめ

約2年ぶり触ってみると、さらに便利になっていました。前回はカスタムパラメータが利用できないなど、切り替えできない可能性もありましたが、だいぶ問題点は減っていそうです。

とはいえ、利用しようとしている機能が使えない、バグなどがあるかもしれないので、何か気になる点があった場合は、Issueのリストをチェックするのがいいでしょう。

Issues · elastic/elasticsearch-java

とくに、新しくElasticsearchでリリースされたけど、Javaクライアントにはまだ利用できないパラメータなどが時々あります。ということで、簡単ですが補足情報でした。

参考

Slackボットで音楽検索＆再生

Thu, 14 Mar 2024 09:24:04 +0000

年末に、GoでSlackのボットを作ったという記事を書きましたが、少し改良したので話の続きを。

やってみたいこととして、キーワードを指定して再生する仕組みを上げていました。

キーワードに関連する曲の再生
- OwnTone自体に検索の仕組みがついているので、キーワードを受け付けてそれに関する曲を流す

コマンドの判別の仕組みの変更

これまでは、単純なコマンドを実行してもらう形で実装していたため、Slackで入力された文字列をそのままコマンド名にマッチするかどうかの判定だけをしていました（レーベンシュタイン距離でタイポ対応はしてましたが）。

この場合、やってみたいことに挙げていた「キーワードを受け付けて」の部分が想定から抜けています。なので、コマンド名の判別処理を入力文字列そのままではなく、次のような処理にしました（処理切り替え時のPR）。

入力された文字列をスペース区切りでSplitして配列に
登録済みのコマンド名もスペース区切りでSplitして配列に
入力の配列に登録済みコマンドの配列が含まれていればコマンドにマッチした
- 入力の配列の残り（コマンド部分を抜いたもの）をスペースで連結してからコマンドの引数として渡す

また、このタイミングでコマンド名を1つの文字列にするために使っていたハイフンも除去することにしました（コマンドと引数の切れ目をわかりやすくしようと思ってハイフンを入れていたのですが、連結しておく必要もなくなったので）。

キーワードを受け取って検索

コマンドごとに引数をどのように利用するかは異なるので、コマンド側で引数の処理を行います。

Owntoneには単語で簡単に検索できるAPIが用意されています。とりあえずは、引数の部分の文字列をそのままこのAPIのqueryパラメータに渡すだけの簡単な処理を実装しました。取得件数（limit）などもありますが、まずは固定で5として実装しました（その時のPRはこちら）。

APIのレスポンスには、アーティスト、アルバム、曲ごとに項目が返ってくるので、それを表示しています。「検索するだけ(search music)」のコマンドと「検索した結果を再生するsearch play」コマンドの2種類を追加しました。

Search Results...
# Artists (1)
 Southern All Stars
# Albums (4)
 Paint The Sky With Stars: The Best Of Enya / Enya
 SOUTHERN ALL STARS / サザンオールスターズ
 STARS / Superfly & トータス松本
 江ノ島 (SOUTHERN ALL STARS GOLDEN HITS MEDLEY) / Z団
# Tracks (20)
 All Of The Stars / Ed Sheeran
 ...

簡易版のクエリパーサーを追加

ちょっと使ってみると、ほかにもできそうなことが出てきます。

検索結果を見るとわかりますが、情報のタイプごとに結果が返ってきています。検索のAPIの仕様に、このタイプを絞り込む条件も渡すことができるようになっています。

いろんな曲が混ざるのもいいのですが、アルバム名で指定したかったり、アーティストで指定して曲をかけたくなります。また、取得件数も指定できるのがいいかも？ということで、引数にちょっとだけパース処理を入れてみました（Parse関数）。

パーサー用のライブラリなども調べてみましたが、そこまで凝った条件を書くわけでもないので、スペース区切りで分割した後に、「limit:数値」や「type:artist」など特殊なキーが単語の先頭についているかどうかの判断をする処理でお茶を濁しました。。。

search music stars type:artist

と入れた場合は、「stars」を含むアーティストだけが結果としてかえるようになります。

そして新たな課題

とりあえずなんとなく検索して再生できるようになりました。ただ、OwntoneはSQLiteに入っているデータに対して、入力された単語で部分一致検索をしているだけのようです。また、曲ごとに異なるアーティスト名になっている場合にアルバムのアーティストがVarious Artistsのようになっており、いい感じに検索できないこともあります（トラックごとのアーティストにも検索してほしい）。

また、私の問題なのですが、海外の歌手名のつづりを覚えていなかったりもするので、もうちょっといい感じに検索できる仕組みが欲しくなってきています。

ということで、今後は類義語（英語名の歌手のカタカナ名とか）や細かなアーティスト名やコンポーザーなどでも検索できるようになにかしらの検索エンジンにデータをいれて、検索はそちらでやりつつ、音楽を流せるような仕組みを作りたくなってきました。

曲のメタデータを増やしたりどうやってやるのがいいかなぁ？

kagome-botのユーザーサービス化

Thu, 25 Jan 2024 09:30:53 +0000

日常でよく、形態素解析したくなることがありますよね？そして、Slackも日常的に立ち上がってますよね？ということは、Slackのボットとして常駐してもらえばできるのでは？

kagome-bot

知り合いがkagomeという形態素解析ライブラリを開発しています。その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。

https://github.com/ikawaha/kagome-bot

ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。ボットについては、上記のリポジトリを見てもらえればいいかなと。

とりあえず動けばいいや、ということで、適当なshell scriptにnohupで起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。

systemdでユーザーのサービスとして登録

参考ブログにある手順ほぼそのままでした。知見ありがたいです。

サービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。

$ systemctl --user --force --full edit kagome

これで、参考ブログにあるようにkagome.serviceというファイルが~/.config/systemd/user/ディレクトリに作られます。ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。

[Unit]
Description=kagome bot

[Service]
ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh
ExecStop=/bin/kill ${MAINPID}
Restart=always

[Install]
WantedBy=default.target

start_kagomebot_service.shの中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。サービス起動時のパスは~/のようなのですが、念のために。

あとは、次の手順でサービスを登録して開始します。

$ systemctl --user enable kagome
$ systemctl --user start kagome

ログを見るのはjournalctlコマンドです。

$ journalctl --user -u kagome

あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。（忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。

$ sudo loginctl enable-linger username

参考ブログ本当にありがたいですね。備忘録のついでにブログにしておきます。

参考ブログ

ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き -

今年の振り返りと来年の抱負（2023）

Sun, 31 Dec 2023 07:49:21 +0000

今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。

振り返り（2022年に書いた抱負から）

まずは振り返りをと。

フリーランス継続

今年も個人事業主として乗り越えられました。 ZOZOさんには今年も引き続きお世話になっている感じです。そのほかにベクトル検索のお手伝いをしたり、OpenSearchを調べたりといった仕事を手伝っています。今年も完全にリモートで作業していましたが、イベントに出かけたりできました。来年はもう少し出かける感じになるかな？今年はすこしのんびり仕事をしていたので、来年はもう少し仕事探さないとかな（営業しないとなあ）

プログラミング

今年はプログラムを書いたほうかなと。 Goで個人用ですが、Slackのボットを書いてみたり（GoでSlackのボットを作った話 | @johtaniの日記 3rd | @johtani’s blog 3rd edition）、公開されているAmazonのプロダクトデータを使って検索アプリを書いてみたり。プロダクト用のアプリを書いているわけではないですが、ちょっとずつコードを読んだり書いたりしています。

ベクトル検索まわりをさわる

がっつりとまではいかないですが、Elasticsearchのベクトル検索の調査をやったりしました。 Amazonのプロダクトデータを使ってもうちょっとやろうと思いつつ、そこまでは手が回せてない感じですが。速度という面でどうやって折り合いをつけつつ導入するのか？どういうシーンでつかうのがいいのか？どのモデル選ぶのか？とか気になることだらけ。なんか、みなさんがどうしてるのか気になってしょうがないので、話をしてもいいよという方は連絡をもらえるとうれしいかもなぁ。ベクトル検索とかLLMの周りの動きがはやすぎてついていけてるのかどうか。。。

本を読む

今年は比較的読んだかも？

単体テストの考え方/使い方
ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング
ザ・ダークパターンユーザーの心や行動をあざむくデザイン
これまでの仕事これからの仕事
機械学習による検索ランキング改善ガイド
ソフトウェア設計のトレードオフと誤り
初めてのGo言語

買って読んでない本ももっとあるんですが。。。

振り返り(今年あったできごと)

ここからは今年の出来事を。今年もずっと自宅でしごとしてました。あとは少し仕事が少なめだったのでゲームが多くなってしまったかも？（本読めばいいのに。。。）

ゲーム（ONI、ゼルダ、FactorioのSpace Exploration）
Dev container導入
検索技術勉強会の再開

ゼルダの新作面白かったですね。年初はOxigen Not Includedをやっていたのに、ゼルダが出てからはご無沙汰中です。ゼルダが終わった後は、ゼルダロスになってPythonを書いたりしていたのですが、うっかりFactorioのSpace Explorationを始めてしまい大変なことに。。。全然終わる気配がないｗ

ローカルでの開発環境などをDev containerにちょっとずつしています。 Slackのボット、検索の遊び場、このブログ環境など。Dockerが必要にはなりますが、VSCodeとDev containerで環境を隔離できるし、VSCodeの拡張もコンテナごとに入れるのもできたりと便利です。

最後は、検索技術勉強会を再開したことです。再始動という感じで4年ぶり？に再開しました（12月に開催した時のページ）。残念ながら私は裏方をしてただけで、当日は参加できてないのですが、次回（たぶん4月くらい）は参加するつもりです。再開の声を上げてくれた@takuya_aさんありがとう。絶賛スピーカーを募集中です。

来年の抱負

さて、来年の抱負です。

フリーランス継続
プログラミング継続
ベクトル検索の使い方をいろいろ試す
本を読んだブログを書く

今年もなんとかフリーランスを継続できましたが、そろそろ営業をしないといけないのかも？ということで、外でしゃべったりもしていかないとなぁと。あとは、検索ってどうやって導入すればいいのか？検索どうすれば改善できる？みたいなところのお手伝いをもっとしたいと思っています。昨年出したこの本もあるので（『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート）、勉強会をやろうとしているところに顔を出したりしたいなあ。外部の人を呼んで社内勉強会とかをできるというところがあれば参加したいので、声をかけてもらえればと。

プログラミングはGo言語を触ったし、今年後半には検索の画面回りのプロダクトを触ってTypeScriptを勉強していこうかなという気になっています（なっているだけかもしれない？）。

ベクトル検索の使い方は、LLMだったりRAGだったりが世の中を席巻しているのもあり、いろんな記事が出てきて全然追いつけていません。だれか、少人数で勉強会とかやると興味ある人とかいるかなぁ？こんなブログ見つけたよ、こんな論文があったよ、こんな使い方したらよかったよとかの共有をやるとみんな楽になったりしないかなぁ？

今年は時々出かけて移動するタイミングで書籍を読んでいました。読んだだけになってるのもあるので、少しでもいいからブログか何かに残しとかないとな。

さて、今年は少しゆっくりできたので、来年はもうちょっといろんなところに顔を出しつつ、新しい仕事もできるといいなぁ。勉強会もスピーカー集めをがんばるぞと。

ということで、今年もあと少しというところで無事書き終わりました。来年もよろしくお願いいたします。よいお年をー

Oramaという検索エンジンでブログ検索を作ってみた

Fri, 15 Dec 2023 00:00:00 +0900

この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。

昨年に続き2回目の情報検索のAdvent Calendar参戦です。

今年は、夏にオンライン参加したBerlin Buzzwordsの「The Debate Returns (with more vectors) Which Search Engine?」というセッションでPhilippさんが話題に出したOrama searchという検索エンジンを紹介してみようと思います（Oramaが正式名称なのかな？）。

Oramaという検索エンジン

公式サイトのトップにも記載がありますが、エッジで動作する全文検索＆ベクトル検索エンジンというもののようです。なにそれ？という感じがしますが、オープンソース版のドキュメントを見るともう少しわかりやすい説明になっています。

Orama is a fast, batteries-included, full-text and vector search engine entirely written in TypeScript, with zero dependencies.

OramaはTypeScriptで書かれた、依存なしで利用できる検索エンジンということです（batteries-includedって初めて見たかも。「必要なものがそろってる」とかいう意味みたい（参考：英語のWikipedia））。

以下は公式サイトにあるサンプルです。

createでスキーマの定義をした検索エンジンのインスタンスを生成します。
insertで先ほど生成した検索エンジンにデータをインデックスします（後で紹介しますが、一括でインデックスするメソッドも用意されています）。
searchで検索し、検索した結果が返ってきます。

以上です。あとは、必要に応じてGUIを用意するだけです。

import { create, insert, search } from '@orama/orama'

const db = await create({
  schema: {
    title: 'string',
    director: 'string',
    isFavorite: 'boolean',
    year: 'number'
  }
})

await insert(db, {
  title: 'The Prestige',
  director: 'Christopher Nolan',
  isFavorite: true,
  year: 2006
})

const searchResults = await search(db, {
  term: 'prestige',
  where: {
    isFavorite: true,
    year: {
      between: [2000, 2008]
    }
  }
})

サクッと動きそうですよね？依存関係がなくTypeScriptで書かれているということは静的なサイトなどでコンテンツを検索するのに使えるのでは？

ということで、自分のブログに組み込んでみました。今回は組み込んだ時の流れと気になった点などを紹介します。 Hugoに組み込む際になるべく簡単にしたかったので、unpkg.comで公開されているJavaScriptだけを利用する形で検索ページを作ってみました。 JavaScriptやTypeScriptは不慣れなので効率がよくなかったり、間違っている点があればコメントなどをいただけると嬉しいです。

構成

私のブログサイトはHugoで生成（参考：Hugo導入時の記事）して、GitHub Pagesとして公開しています。現在のブログ検索にはAlgoliaを利用しているのですが、テスト目的としてOramaも使えるようにしてみました（右上のメニューでOramaをクリックすると以下で説明するOramaによる検索を試すことができます。

今回実装してみたのは次のような流れです（日本語検索対応については後で説明します）。

HugoでJSONのリストを生成（これまでと一緒）
1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成
2.で作成したファイルを公開
画面で3.のファイルをダウンロードして検索

1. HugoでJSONのリストを生成（これまでと一緒）

HugoでJSONのリストを生成します。Algoliaに記事を登録するのにも利用している仕組みです。検索に利用する記事の情報を1記事を1つのオブジェクトとして出力します。1つの配列に記事ごとのオブジェクトが入っているJSONファイルになります。

少しだけ特殊なことをしています。ブログ記事にTagsというフィールドのありなしで処理を分岐しています。 Oramaが配列にNullを受け取った場合にうまく動かなかったので出力するJSON側で調整しています（あとで再確認してIssueあげておかないと）

2. 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成

最初に紹介した公式のサンプルの場合、毎回Oramaのインスタンスを生成した後にインデックス登録の処理を行わなければいけません。ただ、Hugoで生成したコンテンツは特に動的に更新があるわけでもないので、検索画面を表示するたびにインデックス登録するのも無駄が多い気がします。 Orama単体で最初に実装した時には、1.で作成した記事一覧のJSONをOramaで実装した検索ページのスクリプトが呼ばれたタイミングでフェッチし、insertMultiple（複数登録用のメソッド）を呼び出す実装にしていました。

Oramaでは、あらかじめ作成したOramaのデータベースを永続化・リストアするためのData Persistenceプラグインが提供されています。インデックスに登録する処理コストはHugoでコンテンツを生成した直後に行い、検索画面では作成済みのインデックスファイルをフェッチしてリストアする形にすることにしました。インデックスと記事のJSONデータを含んだファイルになるので、元の記事一覧のJSONよりはファイルサイズが大きくなってしまいますが、処理時間も含めて考えると許容できるサイズではないかなと。

次のスクリプトは1.で生成したJSONファイルを読み込んで、Oramaでインデックスした後にdpackというバイナリ形式でファイルに保存しています。こののプラグインで選択できる形式は現時点ではjson、binary（デフォルト＝msgpack）、dpackの3種類になります。残念ながら今回試したところ、binaryではエラーが発生したので、dpackを使用しました。

3. 2.で作成したファイルを公開

単にGitHub Pagesに公開しているだけです。ブラウザが2.で作成したインデックスファイルをフェッチしてから利用するためです。

4. 画面で3.のファイルをダウンロードして検索

あとは検索画面です（長すぎるので、styleの部分は省略しています）。

まず、必要なライブラリなどを読み込みます（下のソースコードの1行目から14行目）。

Oramaだけであれば問題ないのですが、OramaのプラグインがOramaをモジュールとして参照しているため、importmapとして定義しています。 Oramaのプラグインがいくつか利用しているものがあったので、まとめてimportmapに定義してあります。

次に、検索窓（search-searchbar）や検索結果（search-hits）などのHTMLタグを用意します。ヒット件数と検索にかかった時間も取れるので、表示する場所としてstatsも用意してあります。

22行目からが実際の処理になります。

28行目で、手順2.で作成したインデックスのファイルをフェッチします。 32行目でフェッチしたファイルから取り出した文字列をリストアして、Oramaのインスタンスを生成します。 34行目のtokenizerに関しては日本語対応で説明します。

48行目のquery関数がクエリの組み立て＋検索の処理です。search-inputで入力されたテキストをtermとして渡して検索をしています（56行目）。検索した結果のリストをもとに検索結果のHTMLタグを組み上げていきます。検索結果には後述する@orama/highlightのモジュールを利用してスニペットを追加しています。

日本語対応

残念ながらOramaは公式には日本語をサポートしていません（サポートしているスキーマに設定できるlanguageの一覧（＝STEMMERSにあるものだけ指定可能）。一覧と実装分けたほうがいい気がするけど？）。ただ、tokenize関数を変更できるようにしてくれています。これを利用して、少しトリッキーな形で日本語対応しました。

先ほどの手順2.でOramaのcreate関数として、componentsに次のtokenizerを渡します。

languageはenglishですが、日本語をtokenizeする処理に次のように書き換えました。 stemmingは今回は行わない（＝用意されているstemmerを使えない）のでfalse、normalizationCacheは空のMapを用意しておかないとエラーが出るので、new Map()しています。この設定を使ってcreateすることで、

  components: {
      tokenizer: {
        language: "english",
        stemming: false,
        normalizationCache: new Map(),
        tokenize: (raw) => {
              return tokenize(raw)
        },
      },
    },

少しわかりにくいですが、tokenizerのtokenize関数の中で呼び出しているreturn tokenize(raw)の部分はwakachigakiというライブラリのtokenize関数となっています。

wakachigakiというライブラリ

Elasticsearchなどのサーバー上で動作させる検索エンジンではkuromojiなどの辞書を内包した形態素解析器を利用するのが通常です。ただ、今回はブラウザだけで完結した簡単な検索を行う仕組みをOramaを使って提供しようと考えました（kuromoji.jsというのもありますが、辞書のサイズがそこそこのサイズです）。ですので、辞書ファイルのない軽量の形態素解析ライブラリとして、wakachigakiというライブラリ（＝6.2Kbの軽量日本語分かち書きライブラリ）を利用してみました。

最初はTinySegmenterの利用をしていたのですが、wakachigakiのサイトにもあるように、TypeScriptやES Moduleでも利用できる形式となっていたのでこちらに切り替えました。

辞書もっていないため、品詞でのフィルタリングや読みを利用した処理はできませんが、日本語の文章を分かち書きしてくれます。

tokenize関数の設定

OramaのTokenizerインタフェースのtokenizeは入力の文字列をstring[]として返すことを期待しています。 wakachigakiのtokenizeも文字列を引数にとり、string[]を返すので、そのまま呼び出すだけにしてあります。

ただ、今回のブログ検索の実装では、検索窓に入力された文字列も特に何も処理せずにtokenizeに渡す形にしています。クエリパーサーなどを考える場合は、検索窓に入力された文字列を前処理したりする必要がありますが今回はいったんこれで。。。

data-persistenceはcomponentsはpersistしない

手順2.で導入した、data-persistenceプラグインですが、現在の実装ではOramaが生成したデータベース（転置インデックス）だけを永続化しています。独自に設定したtokenizerは残念ながら含まれていませんでした。手順4.の検索画面のコードの34行目の部分（下記）で、フェッチしたインデックスデータからrestoreした後のOramaのインスタンスのtokenizerに手順2.と同じ設定のtokenizerを設定することで検索時にも同じトークナイズがされるようになります（今の仕組みだと修正した場合には、両方のソースコードを修正しないといけないのがちょっと面倒かも？）。

db.tokenizer = {
      language: "english",
      stemming: false,
      normalizationCache: new Map(),
      tokenize: (raw) => {
            return tokenize(raw)
      },
    }

tokenizerはOramaの検索エンジンのインスタンスに紐づく設定となっているので、フィールドごとに切り替えるといったことも現在では想定されていない気がします。

ハイライト

ハイライトのために、インデックスデータに単語のポジションを保存するためのプラグインも提供されています。このポジションは検索の単語がヒットしドキュメントのどの位置に出てくるのか？をあらかじめデータとして保存しておくことで、ハイライトのたびに単語の位置を毎回計算しなくてもよくするためのものと思われます。

これを利用してもよかったのですが、今回は@orama/highlightというモジュールを利用することにしました。検索にヒットしたドキュメントの元の文章と検索のキーワードを入力すると検索キーワードの周りにハイライトのHTMLタグを埋め込んでくれるライブラリを利用しました。これは普通に他でも便利かも？

余力があればプラグインを利用した時のインデックスのサイズの違いや検索時の速度の違いを調べてみるのもいいかもしれないです。

そのほかの機能

今回は利用していませんが、Oramaにはそのほかの機能も用意されています（公式ドキュメントの検索の紹介のページ）。詳細は公式ドキュメントをご覧ください。

Typo tolerance
Facet/Filter
Vector Search
Geo Search
Grouping
Threshold
Preflight

Oramaで（まだ？）できないこと

今回触ってみて、現在のOramaの実装ではできなそうなことがいくつかあったので書き出しておきます。あくまでも現時点のことです。今後実装される可能性もあります。

デフォルトでは、searchのtermに渡した文字列をtokenizeし、出力されたトークン列（単語の配列）のそれぞれのトークン（単語）にヒットしたドキュメントが全て検索結果に含まれます。検索結果のドキュメントはBM25でスコアリングされるので、多くのトークンが含まれるものが上位に来る可能性が高いです。

ただ、特定の単語を含まない検索、ANDやOR検索など凝ったクエリは現在は書けないようです（Issueがある）。

filterは別途用意されているので、例えばファセットで表示したカテゴリで絞り込んだ状態にするといったことはできそうです。

残課題

とりあえず日本語をなんとなく検索できるようにすることはできました。が、気になることもいっぱいありました。時間を見つけてTypeScriptなどを勉強しながら探っていく感じでしょうか。

インデックスを小さくする方法

今回はブログ記事のサマリー（Hugoで生成されるSummary）でインデックスを作ったので、インデックスのサイズはまだ小さくなっています（といっても1MB超えてるけど）。ブログ記事全体を検索できるようにする場合は、インデックスファイルが大きくなります。

これは、OramaがデフォルトではインデックスしたJSON自体もインデックス（ドキュメントストア）に保存しているためです。ですので、Oramaに登録したJSONデータ＋検索用のインデックスがインデックスファイルとなります。ただ、検索だけができればよい場合は、出来上がったインデックスがあればドキュメントのIDは取得できます。

公式ドキュメントでもそのことに触れているページがあります（参考：Remote document storing）。

まだちゃんと実装を見ていませんが、ブログ記事本体の文字列はドキュメントストアに保存しないようにすれば検索はできるが、容量が大きくならないといった工夫ができそうです。

ただ、検索結果にハイライトを含んだスニペットを表示したい場合は、コンテンツ文字列が必要になってくるので、代わりに何かしらの仕組みを考える必要が出てきます（例えばサマリー部分の文字列だけ保存しておいて、ハイライトはそこだけを対象とするなど）。

そのほか

そのほかに思いつくのはこの辺でしょうか？

オートコンプリート：Oramaというよりも、JavaScriptやTypeScriptでうまく実装できるのか？という話のような気がしますが。。。
ファセット対応：機能としては存在していますが、今回は実装が間に合いませんでした。
Vector Search：検索キーワードのベクトルをどうやって作るのか？という問題が残りそう。コンテンツのベクトルだけで関連ページの表示みたいなことはできるかも？（動的にやる必要がないので、事前計算して各ページに埋め込むほうがよさそうだけど）
Geo Search：緯度経度があるデータを探し出してこないと？
relevanceの処理の変更：BM25以外に切り替えることができるかどうか（Oramaのソースとにらめっこしないといけなそう）
tokenizeの改良：辞書を利用する形態素解析ライブラリやAPIを利用してみたり、「てにをは」といった1文字のひらがなを削ることで、無駄な検索ヒットを減らしてみたり。大文字小文字の正規化も必要。
検索ログの解析：検索ログを保存する仕組みなどはないので、Google AnalyticsやほかのAPIなどを用意する？

まとめ

ということで、Oramaという検索エンジン？ライブラリ？を利用して日本語のブログ検索を実装してみました。まだ、機能が少ない部分もありますが、少数のデータをブラウザだけで簡単に検索できる仕組みをGitHub Pagesだけで提供することができそうです。今回は静的なファイルだけで完結する形にしましたが、TypeScriptで利用できる簡単な検索エンジンライブラリとして使ってみるとまた別の面白さもあるかもしれないです。まだ触っていない機能は思いついたこと（＝残課題に書いたこと）もあるので、ちょっと試行錯誤してみようかなぁ。

Elasticsearch簡易検索UI構築　～Searchkit編～

Wed, 13 Dec 2023 00:00:00 +0000

GoでSlackのボットを作った話

Fri, 08 Dec 2023 00:00:00 +0900

PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。

私は、今年は昨年の続きっぽい話を。

音楽の再生とか停止とか

今年もリモートで仕事を継続しています。昨年、OwnToneという音楽サーバーを導入しましたが、ミーティング開始時や終了後に音楽の停止や再生をするのに、ブラウザで操作するのはちょっと面倒です。加えて、ミーティングする際には実際には

音楽を止める
電気をつける

といったことをっやります。音楽再生についても

音楽を再生する
アンプの音は音楽再生用の音量にする

といった複数のことを行います。

基本的にPCの前にいるし、Slackを常に開いているからSlackのBotを作ると便利になるのでは？ということで、自分専用のSlack Botを作ってみました。

GitHubリポジトリ

全く誰の役にも立たないけど、公開しています。

https://github.com/johtani/smarthome

Goで実装

知り合いに勧められたということもあり、Goをあまり触ったことがなかったので、Goでやってみました。時々新しい言語を触ってみたくなるので。。。

コマンドパターンのような作りで、コマンド（操作）を増やしていく感じで実装してはみたのですが、この書き方がいいのかはまだよくわかっていないです。

Actionという単体の操作(例：OwnToneの一時停止)を、操作したい機器の操作ごとに作成しています。インターフェースとしてはRunだけを定義しています。

type Action interface {
	Run() (string, error)
}

それらの操作（Action）をひとまとめにしたものをSubcommandという形で定義して、SlackのBotにはSubcommandの名前を送って処理を実行する形にしています。

type Subcommand struct {
	Definition
	actions     []action.Action
	ignoreError bool
}

やりたいことを追加するタイミングで時々リファクタしたりもしていますが、基本はこんな感じです。細かな実装はさておき、今回ボットを作るときの観点をいくつか。

宅内ネットワーク

音楽サーバーのOwnToneもですが、YAMAHAのアンプのAPIも見つけたのでこれらの操作をボットから行っています。どちらも自宅のネットワークにあるので、今回作成したボットも同じネットワークで動作します。

外部に公開されたHTTPのエンドポイントがあればよいのですが、今回は用意していません。 SlackのAPIではこれに対応したアプリを作るときのためにSocket Modeを用意してくれています。

ドキュメントがしっかりしているのもあり、チュートリアルなどを見つつ特に迷うことなく構築できました。

基本的には「特定のチャンネルでボットがメンションされたら動作する」という挙動だけしか実装していないので、特に今回はこれで困ることもありませんでした（世の中の人たちはもっとすごいSlackの使い方をしていそうだけど。。。）。

対象となるものたち

ボットから操作しているのは今のところ3種類です。

SwitchBot
OwnTone
YAMAHAのアンプ

SwitchBot

SwitchBotについては、go-siwtchbotを利用しています。電気、エアコン、空気清浄機、サーキュレーターのオンオフをSwitchBot経由でやっています。

室内灯の明るさのために、SwitchBot側でシーンを設定している（一番暗い明るさで電気をつける）ので、そこが少しと特殊でしょうか？

あとは、SwitchBotの温湿度計を3つ（室内2つ、室外1つ）おいてあるので、これらの温度を表示するコマンドも用意しました。

それぞれの機器の電池残量（電池の絵文字の右側）を表示してます（書斎が2つあるように見えますが、温湿度計の名前なので、同じ部屋においてあります。。。温度が高いほうがデスクトップPCの近くにある）。防水の温湿度計があるので、外の気温もわかるのは便利です。

OwnTone

JSONのAPIが用意されていますが、特にクライアントライブラリなどは用意されていません。今回は、用意されているAPIのごく一部だけを利用するので、net/httpのClientでJSONを投げています。必要になったらowntone/clientにメソッドを追加していく感じです。

https://github.com/johtani/smarthome/blob/master/subcommand/action/owntone/client.go#L45

再生、一時停止、プレイリストの取得、音量指定あたりを実装しています。音の出力先はAirPlay（次に出てくるYamahaのアンプ）になっています。

あと、JSON APIのサンプルをChatGPTに渡して、「このJSONをレスポンスに受け取る処理をGoで書いてください」と聞いて処理を書いたりしました（細かいのはどう聞いたか覚えてないけど）。

YAMAHAのアンプ

ググって探してきましたが、利用しているYAMAHAのアンプにYXC（Yamaha Extented Control）と呼ばれるAPIが用意されていました。 PDFでAPIの仕様が公開されていたので、この資料とにらめっこしながら、必要そうなAPIを実行するクライアントを実装しました。こちらは、OwnToneのAPIの処理をすでに書いた後だったので、それをもとに必要な実装を追加しただけです。

ちなみに、アンプの電源をONにするAPIは実装していません。

OwnToneで音楽を再生する(AirPlayで信号が送られるみたい)
シーン選択（Nintendo SwitchやPS5のシーンを用意している）のAPIを呼び出す

という処理をすると自動で電源がONになりました。スタンバイしている状態でもAPIはリクエストを受け付ける状態になっているようです。また、PS5のシーンを呼び出したら、PS5自体も起動するのが便利だったりします。HDMI経由で信号が飛んでるのかな？「ミーティング開始」や「音楽停止」コマンドではアンプの電源をオフするAPIを呼び出すようにしています。

タイポ対応

「入力間違いしちゃうんです、人間だもの。。。」

ということで、10月にタイポ対応の処理を入れてみました。タイポ対応前の実装では、入力された文字列がコマンドの文字列と完全一致した場合にだけ、コマンドが実行される形になっていました。結構タイポしちゃうので、完全一致で見つからない場合の処理として、入力された文字列とコマンド名のレーベンシュタイン距離が2以下のものを探し、その中で距離が一番小さな値のコマンドを実行する形にしてみました。コマンド数はたかが知れているのでコマンドのリストを全部チェックする形にしています。タイポするとこんな感じ。

レーベンシュタイン距離の計算にはGo-edlibを利用しています。OSS便利ですね。

やってよかったこと

ミーティング開始時などのいくつかの手順が簡素化できたので満足しています。 SwitchBotの操作もスマホをわざわざ操作しなくてもいいですし（仕事してるとキーボードとSlackは常に使ってるし）。また、副次的な効果として、部屋の外から電源を切り忘れていたり、エアコンの切り忘れなどの場合に、スマホから遠隔でまとめた処理ができるのが便利です。

今後やってみたいこと

こういうのがあるともうちょっと便利かもなぁ？というのもあるので今後も気が向いたらコマンドなどを追加していく予定です。今のところこんなことやりたいなというのがいくつかあります。

キーワードに関連する曲の再生
- OwnTone自体に検索の仕組みがついているので、キーワードを受け付けてそれに関する曲を流す
Flexispotの操作
- ミーティングの時は立ち上がっているので、机をスタンディングの状態にしたい
- 電子工作しないとだめかも？
Webカメラ用ライトの点灯
- ミーティング時に明かりが必要なのですが、物理スイッチのOn/Off
- これも電子工作かな？
定期的に温度をBotに表示させると面白いかも？

まとめ

ということで、新しいプログラミング言語にも触れたし、作業環境も便利になって一石二鳥でした。新しいプログラミング言語触るのはやっぱたのしいですね。

Elasticsearch簡易検索UI構築 - Search UI編-

Tue, 05 Dec 2023 00:00:00 +0000

機械学習による検索ランキング改善ガイドを読みました

Mon, 25 Sep 2023 03:32:24 +0000

「機械学習による検索ランキング改善ガイド」を読みました。

著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。

紹介とレビュー

どんな本なのか？は打田さんが書かれたブログ、「ブックレビュー：『機械学習による検索ランキング改善ガイド』 - Tomoko Uchida - Medium」に詳しく書かれているので、そちらも参考にしてもらうほうがわかりやすいと思います（丸投げ）。

読みながらいくつかツイートしていたので、そちらも参考のために貼っておきいます。

オライリーの検索ランキング本、負荷テストのことも書いてある、すごいhttps://t.co/YPnB6kxFY2
— Jun Ohtani (@johtani) August 28, 2023

私のレビュー

わかりやすく検索の基本を紹介しつつ、本書のメインであるランキング改善について全体の流れが書かれています。ランキング改善のやり方といっても、手法の話だけではなく、プロジェクトとしてどの様に進めていくべきなのか？また、関係するものはどんなものがあり（システムだけではなくチームについても書かれていたり）、どういう判断をもちながら運用していくのか？、負荷テストにまで言及されています。

読んでいて特に私が気に入ったのは以下のような話でした

ランキング改善を進める前にきちんと解ける問題なのか？それ以前にやることはないのかを考えましょう
- マッチング改善についても少しだけ触れられているが、メインはランキングについてだと明記されている
実際に体験されたのであろう落とし穴の話
負荷テストについて1章設けてある！
- ハンズオンのパートでもレイテンシの話がされている
付録としてベクトル検索についても触れてある

日本語でまとまって読める本があるのは本当に幸せですよね。

おまけ

書籍ではハンズオンで、Elasticsearchとランキング学習のプラグインであるelasticsearch-learning-to-rankを利用しています（GitHubにサンプルが公開されています）。書籍ではElasticsearchが7.13.4、プラグインが1.5.7-es7.13.4というバージョンになっていました。

ブログを書いている時点でのElasticsearchは8.x系になっています。せっかくなので、書籍を読みながら現時点で最新のものに置き換えてみるというのをやってみました。

Elasticsearchは8.10.2が最新なのですが、ランキング学習のプラグインはサードパティ製で、1.5.8-es8.8.2が最新版となっています。ハンズオンのサンプルコードをフォークして、以下の構成にして動くようにしてみました。

Elasticsearch : 8.8.2
learning-to-rankプラグイン : 1.5.8-es8.8.2
Kibana : 8.8.2
Python : 3.10

Elasticsearch、プラグイン、Kibanaのアップグレード

Elastic社が提供しているDockerイメージが利用されているので、バージョン番号を書き換えました。あとは、learning-to-rankプラグインのバージョンを書き換えるついでに、elasticsearch-pluginコマンドで直接ダウンロードさせる形に書き換えました。

https://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/search-engine/Dockerfile

Python3.10にアップグレード

本当は必要なかったのですが、Pythonのイメージもついでに3.10にしました。ただ、このおかげでインストールされるXGBoostのバージョンも1系から2系に上がってしまい、XGBoostを利用してモデル生成をする処理でエラーが出るようになってしまいました。。。

2系へのアップグレードは手間がかかりそうだということで、pipコマンドでのインストールでのバージョンを<2として、1系をインストールすることで回避しました。

https://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/Dockerfile

elasticsearch-pyのアップグレード

Elasticsearchを8系にしたので、クライアントライブラリ側も8系に書き換えました（元は7.17以下に固定されていた）。 pipで7系に固定されていたものを外して最新のもの（8系）をインストールするようにしました。これだけでも特に問題なく動いたのですが、「DeprecationWarning」が出ている部分が1か所だけあります（サンプルではDeprecationWarningが出力されない形になっていましたが、出力するように変更しました）。

Elastic公式のドキュメントにMigrate to 8.0というページが公開されています。Pythonクライアントのアップグレードを行う際はこちらを参考にすると指針が記載されています。

今回のサンプルコードではsearchの時の引数としてbodyを渡していたのですが、8系のクライアントライブラリからこちらが廃止になり、queryやrescoreなど個別の引数を渡す形に変更されています（search APIのリファレンス）。ですので、bodyを**bodyでアンパックして渡すようにしただけです。サンプルコードがわかりやすく書かれているので変更も少しで済みました。

https://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/collect_responses.py#L59

一応、これでエラーが出ないで動きました。すべて適用した、フォークして修正したブランチはhttps://github.com/johtani/building-search-app-w-ml/tree/es8で公開しています。

まとめ

すごくわかりやすいうえに、手を動かしながらどんなデータを使ってどんなことをやるのかが体験できる良い本でした。理論的な話だけでなく、システムとしてどういうものが必要で、どういうことをやらないといけないのか？というのがわかるのがイメージできるのは重要だと思います。

最後は広告ですが、ランキング改善以外の検索システムについて学べる本を検索システム ― 実務者のための開発改善ガイドブック – 技術書出版と販売のラムダノート出していますので、こちらも参考書として読んでいただけるとうれしいです。

search-UIとSearchkitと検索画面

Wed, 23 Aug 2023 05:32:44 +0000

趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。ベクトル検索などの確認なども含めて、Jupyter Notebookで簡単なAPIの呼び出しを書いていましたが、検索はやはり画面があるほうがにぎやかでいいですよね。ということで、画面周りで調べものをしていた時のことを後日の自分のためのメモとして残しておきます。

Search UIとSearchkit

ということで、それほど手がかからないで検索の画面をサクッと作る方法がないか？ということでちょっとだけ探してみました。最初にElasticsearchを利用していることもあり、すぐに検索の画面を作れるライブラリ・フレームワーク・コンポーネントがないかな？ということで思いついたのが次の2つでした。

どちらも直接Elasticsearchに接続して検索をすることができるコンポーネントです。 Elasticsearchだけで完結していればそれでおしまいだったのですが、今回はバックエンド経由でElasticsearchに検索を書ける必要があります（ベクトル検索の仕組みもデモをしたいため、クエリの文字列をLLMなどでベクトルにしてからknn検索をすることになります）。

Search UIの構成

もともとSearch UIはElasticのApp SearchのGUI構築向けのコンポーネントとして作られました。最近になって、直接Elasticsearchに接続できるコネクターを提供しています（ベータだけど）。このコネクターを利用した場合は、ざっくりですが、このような流れになります。

また、Search UIはCustom Connectorの仕組みも用意しており（ConnectorのAPIが宣言されているのでそのAPIで独自実装が可能）、これを利用することで、ブラウザではなくバックエンド（Node）でElasticsearch Connectorを利用するような構成も取れるようになっています。

改めて要件をまとめると

ということで、やりたいことは

簡単にUIが作れる
バックエンドはPythonを経由して検索したい

となります。 Searchkitも調べようかと思いましたが、いったんはSearch UIのCustom ConnectorでPythonでFastAPIでバックエンドのAPIを実装して、Search UIの想定しているリクエスト・レスポンスに変換すればいいかな？ということにしました。

とりあえずSearch UI＋Custom Connectorからのリクエスト・レスポンス（フロントからバックエンドへの出入りの部分）を記録し、 Search UI＋Elasticsearch Connectorのときのリクエスト・レスポンス（バックエンドからEsへの出入りの部分）も記録して、参考にしながらバックエンドを実装しようと試みました。 Search UIのCustom Connectorのサンプルとなっていた、Node上でElasticsearch Connectorを動かしている部分をPythonで簡単に再実装しようという試みです（まったく同じ実装にする必要はなく、必要最低限の機能（検索窓、ファセット、ページング）が動作するところを目指します）。

Elasticsearch API connectorの調査

方針が決まったので、Search UIがElasticsearch API Connectorに渡しているリクエストをブラウザのデバッグ機能を使って追いかけてみると。。。内部でSearchkitを読んでいる？？ことがわかりました。

Elasticsearch API Connectorがリクエストを変換しているのかと思っていたのですが、実は内部にもう一段変換が行われていました。

方針を決めたつもりが、Searchkitが出てきてしまったので、Searchkitも調べてみることに。。。なお、Search UIにElasticsearch API Connectorを導入したのがどうやら、Searchkitの作者で、現在はElasticのエンジニアになられているようです。

Searchkitとは？

Search UIが利用しているSearchkitは、3.0ですが、Searchkit本家のリポジトリを見ると4.x.0となっています。

どうして新しいものをSearch UIで使っていないのかな？と思いつつ調べてみたところ、Searchkit V4のブログを発見しました。

Searchkit V4 integrates with Algolia’s Instantsearch library, which is a Search UI library built by Algolia. Instantsearch is an amazing library, and it’s been used by many companies and supports many frameworks like React, Vue and Angular. ブログより引用

どうやら、V4ではコンセプトをガラッと変更されたようで、Algoliaがオープンソースとして開発しているInstantSearchのコネクター（アダプター）としてSearchkit V4を開発しているようです。これは最近出てきている検索エンジンのTypesenseやMeilisearchの戦略にもなっています。

なお、SearchkitのGitHubリポジトリやSearch UIのリポジトリを見ていると、Search UIの開発（およびSearchkitの3系）は現在は活発に行われていないように見えました。 Searchkit V4はちょっとずつ開発が進んでいるようです。

まとめ？

一応Searchkit V4の現状やInstantSearchもすこしだけ見てみたのですが、今回の私のプロジェクトでは検索画面はまだそこまで重要度は高くないので、いったん調べていたSearch UI＋Pythonのバックエンドの構成で動作する最小限を実装したところで終わりにしました。なので、Searchkit V4＋InstantSearchの構成はまた今度という感じです。

なお、Search UIの方は5月からコミットがされていないようです。どうも開発しているチームが別件で忙しそうだなというのを感じました。

VS CodeとDev Container(コンテナ名の指定)

Thu, 27 Jul 2023 01:22:49 +0000

いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを残しておきます。

コンテナ名の指定

最初のDev Container導入の記事で、起動したコンテナの名前が自動で付与されて、ランダムに変わるという疑問点を書いていました。

docker-compose.yml対応の記事ではdocker-compose.ymlを利用すると、コンテナ名はファイル内で定義されたサービス名で起動されて見やすくなると気づきました。

やはり、Dev Containerでイメージを指定している場合もわかりやすいコンテナ名がいいなと思ったところで、「runArgs」を思い出しました。 Dev Containerからコンテナを起動するときに渡す引数が書けるじゃないですか。そういえば、むかしdockerコマンドを使う時に名前を指定した記憶があったなと。ということで、Google検索です。「docker command args container name」で検索しましたｗ

--nameというオプションで起動時のコンテナの名前の指定ができます。ということで、このブログを生成するためのdevcontainer.jsonに"runArgs"でコンテナ名を指定してコンテナ起動ができるようになりました（「ブログ記述環境としてのDev Container」という記事のdevcontainer.jsonにrunArgsの行を追加しただけ）。

{
    "name": "Hugo - blog generator",
    "image": "mcr.microsoft.com/devcontainers/javascript-node:16",
	"runArgs": ["--name", "blog_generator"],
    "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",
    ...

ブログ記述環境としてのDev Container

Mon, 24 Jul 2023 09:10:32 +0000

このブログの生成には、Hugoを利用しています。ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。また、Windowsに移行したタイミングで、WSL2のUbuntuにaptでhugoをインストールして利用していました。 WSL2の環境が壊れなければこのままでもいいのですが、最近Dev Containerを触っていたので、このブログを書く環境（おもにHugo）もDev Containerにできるのでは？と気づきました。

ということで、Hugo＋αの環境をDev Container化したので、そのメモです。

必要なもの

ブログを書いて、記事を構築して、公開するところまでに利用するのは次のようなものです。

git
Hugo
node
atomic-algolia

GitHubのプライベートリポジトリでHugoのプロジェクトを管理しています。また、GitHub Pagesで公開しており、生成したHTMLもgitコマンドを利用してGitHubにpushしています。このため、gitコマンドが必要です。

コンテンツの生成はHugoコマンドを利用します（テーマの適用とかいろいろ）。

あと、Algoliaでブログを検索できるようにしており（ブログ移行日記（その4）参照）、Algoliaへドキュメントのデータをアップロードするために、atomic-algoliaを利用しています。こちらは、nodeのモジュールであるので、nodeの環境も必要です。

ベースにするイメージ

Dev Container Templatesというリポジトリが公開されています。こちらを探すと、元となるdevcontainer.jsonが見つかることがあります。 Hugoのものがあるか探してみましたが、残念ながら見つかったのはJekyllのテンプレートでした。今回は、nodeの環境が必要なのでjavascript-nodeを元に編集していきます。

手元のUbuntuのnodeのバージョンが16だったので、バージョン16のイメージを指定します(devcontainer.jsonは後述)。

Hugoの追加

Hugoのテンプレートはなかったのですが、Dev Container FeaturesにHugoのfeatureが用意されていました。 featuresに1行追加するだけでコンテナにHugoをインストールしてくれる便利ものです。

Markdownの環境

Dev Container Templatesを探索していて見つけたMarkdownのテンプレートも参考にしてみました。 VS CodeのMarkdown向けの拡張機能がいくつかリストアップされていたので、ついでに追加です。 markdown-all-in-oneやmarkdownlintはこれまでも利用していたので、他のものも便利だろうということで。他の物はどんなものかを後で調べてみる予定です。

作った.devcontainerの設定はこちら

ということで、出来上がった設定は以下の通りです。

devcontainer.json

{
    "name": "Hugo - blog generator",
    "image": "mcr.microsoft.com/devcontainers/javascript-node:16",
    "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",
    "features": {
        "ghcr.io/devcontainers/features/hugo:1": {}
    },
    "customizations": {
		"vscode": {
			"extensions": [
				"yzhang.markdown-all-in-one",
				"streetsidesoftware.code-spell-checker",
				"DavidAnson.vscode-markdownlint",
				"shd101wyy.markdown-preview-enhanced",
				"bierner.github-markdown-preview"
			]
		}

    }
}

postCreateCommand.shでは、npm installで、必要なモジュールのインストールをコンテナビルド後に実行できるようにしました。（apt updateはなくてもいいな）

postCreateCommand.sh

#!/bin/sh
# postCreateCommand.sh

echo "START Install"

sudo apt update
sudo chown -R vscode:vscode .

npm install

echo "FINISH Install"

まとめ

ということで、ここ最近Dev Containerについて色々調べていたのでサクッとDev Container化ができました。まぁ、HugoのFeatureが用意されていて、他に大したことをやっていないというのが大きいのですが。このブログは今回構築したDev Containerで生成して公開した記事になります。

WSL2のディストリビューションの環境移行

Mon, 24 Jul 2023 06:28:48 +0000

WSL2にUbuntuを入れて、開発とかはこちらを利用しています。また、Docker DesktopもWSL2のバックエンドエンジンを利用しています。

知り合いとの話で、Ubuntuの外付けのSSDをマウントしたという話が出てきて、それだと遅くない？Ubuntu自体を移動できるんじゃないかな？という流れになりました。知り合いは、特に移動とかは考えてなかったのですが、自分のディスクの容量が今どのくらい使われているのかが気になり、調べてみると、 Cドライブの使用率が90%を超えてるじゃないですか。

WizTreeというソフトを前回入れていたのを思い出して、再度調べてみたところUbuntuらしきvhdxファイルのサイズが171GB、Docker Desktopのデータ領域のvhdxファイルのサイズが81GBと、結構な割合です。

前回は、Hyper-V管理ツールで仮想ディスクの圧縮処理を行ったのですが、Dドライブに移行したほうが安心できそうな気がしたので、移動の方法を調べました。

WSLコマンドのドキュメントが公式で公開されています。こちらのコマンドを元に作業をしました。また、ググって出てきた記事も参考にさせていただきました。ありがとうございます。

まずは確認と停止

WSL2で使っているディストリビューションを確認します。コマンドは以下の通り。実行した結果も含まれています。コマンドの実行にはコマンドプロンプトを使用しました。公式ドキュメントのドキュメントではスニペットはPower Shellと書かれてますが、コマンドプロンプトでも大丈夫そうでした。

D:\>wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu                 Running         2
  docker-desktop         Running         2
  docker-desktop-data    Running         2

残念ながら、wslのコマンドでは実体がどこにあるのかを調べることができなかったですが、WizTreeでディレクトリ名などを見ていたのでなんとなう予測ができました。（これ、他に知る方法あるのかなぁ？）

ディストリビューションの移動は次のような手順になります。

wslのshutdown
エクスポート（ディストリビューションのコピー）
今あるディストリビューションを削除
インポート（今ある名前で2.のファイルをインポート）

まずは停止です。これをやらないとエクスポートができないので。

D:\>wsl --shutdown

エクスポート

次にエクスポートです。今回は以下の2種類の仮想環境をエクスポートします。

Ubuntu
docker-desktop-data

エクスポートでは、元のディストリビューションのファイル（Cドライブにあるファイル）が消えることはありません。また、エクスポートの形式として、tarとvhdxの2種類が指定できます。エクスポートのコマンドのデフォルトはtar形式ですが、エクスポート元のファイルがvhdxなので、vhdxでエクスポートしたほうがCPUにやさしかったです。ちなみに、docker-desktop-dataはtar形式でエクスポートしてインポートしました。tar形式の場合は、ディスクのサイズが小さくなる可能性があるみたいです（不要なデータがvhdxの中に残っていたりする影響かと）。

コマンドは以下の通りです（詳細は公式ドキュメントを参照してください）。出力ディレクトリはあらかじめ作っておきました（作ってない場合の挙動は未確認です。）

D:\>wsl --export Ubuntu .\wsl\Ubuntu\ext4.vhdx --vhd

docker-desktop-dataはtar形式です。

D:\>wsl --export docker-desktop-data .\Docker\ docker-desktop-data.tar

ディストリビューションの削除（こわい？）

今ついているディストリビューション名を利用したいので、いったん、Cドライブ上にあるディストリビューションを削除する必要があります。コマンドは公式ドキュメントにある--unregisterオプションを利用します。以下のコマンドはUbuntuですが、docker-desktop-dataもやりました。

D:\>wsl --unregister Ubuntu

ちなみに、このコマンドを実行すると、Cドライブの容量がいきなり空きました。コマンドいっぱつでなくなりました。きちんとエクスポートしてから実行しましょう。（なんなら、一度、別名でインポートして動作確認するのもいいかもしれないです。私はしましたｗ）

インポート

インポートするオプションも2種類あります。vhdxファイルの場合は、インプレースでのインポート（vhdxファイルをそのまま利用する形式）が可能です。 Ubuntuについてはこちらを利用しました。この場合、vhdxファイルがそのまま利用されるため、バックアップとしては利用できなくなります。今回は170GBもあるので、これでいいかと。

D:\>wsl --import-in-place Ubuntu .\wsl\Ubuntu\ext4.vhdx

tarファイル（docker-desktop-data）の場合は、通常のインポートを行いました。

wsl --import docker-desktop-data D:\Docker\docker-desktop-data\ D:\Docker\docker-desktop-data.tar

この場合、tarファイルは残ったままで、新たにD:\Docker\docker-desktop-data\ディレクトリにext4.vhdxファイルが作られました。バックアップも取りつつ移行したい場合は--importがいいかもしれません。また、WSLはバージョン1とバージョン2があり、インポートの際にこの部分も気にする必要があるようです。今回はすべてバージョン2で、かつ、wslのデフォルトのバージョンを2にしてあったので特に意識していません。

Ubuntu起動ユーザーの指定と注意点

公式ドキュメントに、既存のユーザーを変更するコマンドの記載があります。インポートしたディストリビューションは、デフォルトユーザーがrootになっていることがあるようなので、Ubuntuのユーザーを次のようなコマンドで変更しました。

 ubuntu config --default-user johtani

公式ドキュメントの警告にもありますが、実行可能ランチャーがない場合があります。今回のubuntuは、WSL2でUbuntuをインストールした時に作成されたコマンドで、unregisterした後にimportしてもきちんと動いたので問題にはなりませんでした。これは、インポートするときに、既存のディストリビューション名を利用したためと思われます。

エクスポートやインポートの検証するために、NewUbuntuという名前で別途インポートした時には、NewUbuntuという実行可能ランチャーは作成されず、上記のデフォルトユーザーの設定は別の方法が必要になります（罠だ）

docker-desktop-dataのほうは、特に変更してないけど動いてそうだからいいのかな？前の設定の確認とかやっておくのがいいんだろうな、本当は。。。

まとめ

ということで、Cドライブに300GB近い空きができて、心の余裕もできました。今回は、同じPC内で別のドライブへの移動でしたが、他のPCにもこれで移行ができそうですね。たまにはバックアップをとっておくのもいいのかも？と思いました（やるかどうかはまた別の話）

VS CodeとDev Container（docker-compose.yml対応）

Fri, 21 Jul 2023 10:13:30 +0900

前回の記事で、VS Code＋Dev Containerを導入しました。残課題として「マルチコンテナ化」があるという話もしました。今回はDev Containerのdocker-compose.yml対応をした話をメモとして残しておきます。実際、VS Code + Dev Containerに移行した後に、Esを起動してアプリからつなげるというのがうまくいかないというのがあったので対応がんばりました。。。

Dev Containerのdocker compose設定

この記事ではすでにdocker-compose.ymlが存在している状態の話をします。変更する前は、devcontainer.jsonでベースのコンテナイメージの指定、マウントの設定などを行っていましたが、docker-compose.ymlにいくつかを移動しないといけません。対応した時の作業の流れは以下のような感じです。

ワークスペース用のDockerfileの作成
docker-compose.ymlにワークスペース用のサービスを追加
devcontainer.jsonをdokcer-compose.ymlを利用する形に書き換え
アプリでの接続文字列をlocalhostからdocker-compose.ymlのサービス名に変更

参考：対応した時のコミットです。差分などはこちらをごらんください。

devcontainerのリポジトリにPython+PostgreSQLのサンプルが公開されており、こちらを参考にしながら作業をしました。

1. Dockerfileの作成

docker-compose.ymlだけでも完結するのかもしれないですが、いろいろやりたいことも出てくるかもしれないので別のファイルに切り出しました。といっても、コンテナのイメージはdevcontainer.jsonに記述していたものを使っています。

ARG VARIANT=3.11-bookworm
FROM mcr.microsoft.com/devcontainers/python:${VARIANT}

ENV PYTHONUNBUFFERED 1
ENV TZ Asia/Tokyo

TZはdevcontainer.jsonで指定していたものを、こちらに移行した形になります。 PYTHONUNBUFFEREDは参考にしたDockerfileの記載です。標準出力・エラーをバッファリングしない指定になっています。

2. dokcer-compose.ymlにサービス追加

backendという名前のサービスをdevcontainer（VS Code）から接続するコンテナのサービス名にしています。

services:
  backend:
    build:
      context: .
      dockerfile: .devcontainer/Dockerfile
    init: true
    environment:
      - TZ=Asia/Tokyo
    command: sleep infinity
    volumes:
      - .:/workspace/search-research:cached
      - venv-search-research-backend:/workspace/search-research/.venv
...
volumes:
  venv-search-research-backend:

1.で作成したDockerfileを利用します。docker-compose.ymlファイル自体は、プロジェクトのルートディレクトリに配置していますが、Dockerfileは.devcontainerディレクトリに入れたため、contextとdockerfileはこのような指定になっています。

initは、devcontainer.jsonで指定していた"runArgs": ["--init"],の設定になります。

commandの部分は、コンテナが起動したままにしておくための設定です。

volumesでは2つのボリュームに関しての指定があります。 1つ目の/workspace...は、VS Codeがコンテナにプロジェクトをマウントする場所の指定です。 devcontainer.jsonだけを利用していた場合は意識していませんでしたが、/workspace/プロジェクト名というディレクトリにプロジェクトがマウントされていました。 docker-compose.ymlを利用する場合は、明示的に指定が必要です。 2つ目のvenv-...は.venvのディレクトリをコンテナの中だけのものにする設定を移植したものになります。前回の記事ではコンテナIDをボリューム名に含めていましたが、こちらのほうがわかりやすいかと思い、プロジェクトの名前とサービス名をつけるようにしてみました。 Dev Containerで起動した場合はsearch-research_venv-search-research-backendという名前がついています（最初の部分はDev Containerがつけてるのかな？）

3. dovcontainer.jsonの変更

devcountainer.jsonから呼び出すものの準備ができたので、devcontainer.jsonを書き換えます。公式のドキュメントとしてDocker Compose向けのプロパティが紹介されています。変更したものは次のような形です。

{
  "name": "search-research",
  "dockerComposeFile": "../docker-compose.yml",
  "service": "backend",
  "workspaceFolder": "/workspace/search-research",
  "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",
  "customizations": {
...

dockerComposeFile : 利用するdocker-compose.ymlのファイルパス
service：VS Codeが利用するワークスペース用のサービス名
workspaceFoldeer：VS Codeがコンテナに接続したときに開くフォルダのパス

を指定します。これで、VS Codeでこのプロジェクトを開いた時に、Dev Containerがdocker-compose.ymlを使ってコンテナの起動（ビルドとか）を行ってくれます。

4. アプリの接続文字列の書き換え

こちらはおまけです。 PythonのアプリからElasticsearchに接続するときの文字列として、Dev Container化の前は、http://localhost:9200と指定をしていました。 Elasticsearch用のサービス（es）で、ポートフォワードをしていたためです。

アプリ側もコンテナ化したので、Docker Composeが名前の解決をしてくれるので、http://es:9200という接続文字列で接続ができるようになりました。

ということで、ここまでで、VS Codeでプロジェクトを開くと、2つのコンテナ（backendとes）が起動してVS Code上でPythonアプリからEsへの接続ができるようになりました。

追加の変更

参考のプルリクでは、上記まででしたがさらにいくつかの変更をそのあとやっています。

起動するサービスの指定(開発だけするときはEsを起動したくない)
- devcontainer.jsonでrunServicesを使って指定できます（公式ドキュメント）
GPUをコンテナから利用できるように
- devcontainer.jsonでfeaturesのnvidia-cudaを指定し、docker-compose.ymlでnvidiaのドライバーなどを設定することで対応しました。
- nvidiaが公開しているcuda対応のコンテナイメージでもよかったのですが、こちらのほうが楽そうだったという理由です。featuresとコンテナのビルド、postCreateCommandの順序などはもうちょっと勉強しないといけない気がしています。

これらの対応はこちらのコミットで対応しています。

GPUの対応は、私個人の環境はこれでいいのですが、複数の人がこのリポジトリを使う場合はどうやって切り替えたりするんだろう？という疑問が残っています。。。今回はrinna/japanese-clipのモデルを使って、テキストからベクトルを生成する部分の処理のためにGPUを使いたいというモチベーションがあり、コンテナでもGPUを使えるようにしています（CPUだと時間がすごくかかる。。。）。

サービス起動の新たな問題点

runServicesで起動するサービス名を指定したのはよかったのですが、Elasticsearchのサービスを起動して、データ登録や検索の確認を行おうと思った時に、EsのコンテナをVS Codeだけで起動する方法がまだわかっていません。。。一度コンテナをビルドした後なら、「Remote Explorer」でOther Containerというくくりで表示され、右クリックで起動や停止ができそうなのだけど、新規サービスをdocker-compose.ymlに追加した場合は、自分でターミナルなどでコンテナのビルドをしないといけないかもしれないです。もうちょっと調べてみないとなぁ。

副次的な効果

Docker Compose対応をしたことで、前回の記事での疑問点のうち、「コンテナ名」「VolumeのID」については懸念点がなくなりました。

「コンテナ名」は、docker-compose.ymlのサービス名がコンテナ起動時に名前として利用されるため、Docker Desktopで見た時などの探しにくさはなくなりました。ただ、「イメージ名」については、いまだに2つできています。「-uid」がつかないものの代わりに、search-research-backendというイメージが作られています。ただし、実際に利用されるのは前回の記事に書いたようなvsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-uidという名前のイメージです。

「VolumeのID」については、docker-compose.ymlのファイルで自分で名前をつけるようにしたので、コンテナのIDが利用されなくなったという次第です。代わりに、プロジェクト名である「search-research」という名前を直接記述しているので、変数などで置き換えたほうがいいのかも？という気がしています。

まとめ

ということで、複数のコンテナを利用するプロジェクトでVS Code+Dev Container対応ができそうだということがわかりました。ついでに、GPU対応もできたのでこれで、やっと他の検索エンジン対応などができる気がしています。（その前にpre-commitを保存時にチェックする形に変更かなぁ）やりたいことからちょっとずつ外れている気もするけれど、新しいことを調べるのは楽しいですね。

VS CodeとDev Containerの導入（まだ途中）

Thu, 13 Jul 2023 22:15:23 +0900

前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。これについて、知り合いとチャットで話をしていて、それほどPyCharmにこだわりもないよなぁということになり、であれば、ISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）を試してみるとすっきりするかもしれないとなり、Dev Container対応をブログを参考に行ってみました。

順を追ってブログで説明されているので、どういう仕組みなのか、どの設定が何を意味しているのか？がとてもよくわかりやすくすんなり対応することができました。

ブログの手順をなぞっているところでいくつか固有の手順や疑問点が出てきたのでブログに書き記しておきます。結果は、コミットしてあるものを見てください。

ブログとは違う手順

まずはISIDのブログとは違う点をいくつか。

.venvはいったん削除

ブログでは新規のプロジェクトを作成していく過程で、コンテナ化した環境を作った後に.venvをDockerコンテナのボリュームにして、最後に仮想環境のPythonを生成していました。私の場合は、すでにホストOS（実際にはWSL2のUbuntuだけど）で.venvのディレクトリを作成してある状態だったので、いったん削除する必要がありました。すでに存在する.venvがbindマウントされてしまっている状態になるため、Dockerのボリュームとの整合性が取れなくなるようです。

この作業を行う前か、途中でDev Containerを停止した状態で、.venvを削除することで問題なくDockerのボリュームに仮想環境のPythonが登録されるようになります。

postCreateCommand.shの呼び出し方

ファイルに実行権限がないと、実行権限エラーが出ました。実行権限を与えるか、次のような記述で動くようになりました。今は、ファイルに実行権限をつけるのではなく、次のような記述にしていますが、何か問題あるかな？

 "postCreateCommand": "/bin/sh ./.devcontainer/postCreateCommand.sh",

実際に動作しているログを見ると

/bin/sh -c /bin/sh ./.devcontainer/postCreateCommand.sh

となっているので、少し気持ち悪いのだけれども。。。

postCreateCommand.shの追加処理

今回Dev Containerを適用したプロジェクトでは、sentencepieceを利用します。この、sentencepieceをpoetryがインストールするタイミングで、cmakeを要求してきました。今回利用しているDocker Imageにはcmakeは含まれていないため、以下の処理を追加しています。

sudo apt update
sudo apt-get install cmake -y

また、rinna/japanese-clipも利用しているのですが、こちらは、poetryで追加してインストールでは依存するパッケージがインストールされないため、pipコマンドを利用するようにしています。

pip install git+https://github.com/rinnakk/japanese-clip.git

コンテナイメージを作った後にやりたいことを、自由にスクリプトで書けるのは便利ですね。

pre-commitのスクリプトの再生成

こちらも、既存の環境が残っているとPythonへのパスの違いの問題が出たので、作り直しました。 .git/hooks/pre-commitのファイルを削除し、pre-commit installをやったものをリポジトリにコミットしてあります。

疑問点

作業をしていて疑問点もいくつか出てきたのでメモを残しておきます。ちなみに、これらの疑問について実際に調べるまでには至っていません。時間を見て解決できればなぁと（できるのか？）。

Imageが2つ

Dev Containerの設定を書いた後に、コンテナをビルドすると、Docker DesktopのImagesにイメージが出来上がります。この時、イメージが2つできあがっています（なぜ？）。

REPOSITORY                                                                                          TAG       IMAGE ID       CREATED      SIZE
vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features-uid   latest    25c7e23416ec   3 days ago   1.69GB
vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features       latest    fcf9eaeb2187   3 days ago   1.69GB

こんな感じで、最後に-uidがついているかいないかの違いです。実際にコンテナ起動時に利用されるのは-uidがついているものになります。なぜ2つになっているのか、1つにする設定などがあるのか？といったところが気になるところです。

Containerの名前

devcontainer.jsonの設定を書き換えて、コンテナをリビルドすると起動したコンテナの名前が自動で割り振られているようです。今は、fervent_hopperとなっています。ランダムにつけられているようなのですが、名前を付ける方法はないのかなぁ？と。

devcontainer.jsonにはnameというプロパティもあるのですが、この値がどこで使われているのかはよくわかっていません。 Remote Explorerでコンテナの一覧が見えますが、ここでは、リポジトリ名が利用されているようです。

VolumeのIDはどこから？

devcontainer.jsonで次のような記述で、.venvのディレクトリようにDockerにボリュームを作っています。

  "mounts": [
    "source=venv-${devcontainerId},target=${containerWorkspaceFolder}/.venv,type=volume"
  ],

実際にコンテナでマウントされている情報を見ると

/workspaces/search-research/.venv
/var/lib/docker/volumes/venv-04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5c/_data

となっています。 04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5cがdevcontainerIdに相当するのだとは思うのですが、誰がつけたものかなどがまだよくわかっていません。もうちょっとわかりやすいものが使えるほうが嬉しいかも？と思っていたりします。（複数Dev Containerを使い始めると、Docker Desktopで見ると、どのボリュームがどのDev Containerに紐づいているかがぱっと見ではわからない）

.vscodeディレクトリどうしよう？

たぶん、VS Codeを触っている過程で、何かの設定をしてしまったのだとは思うのですが、 .vscode/settings.jsonというファイルができており、次のような内容になっています。

{
  "git.ignoreLimitWarning": true
}

何か意味があるかも？ということで、コミットしてリポジトリに入れたのですが、いらないのかもしれないなぁと。

残作業

とりあえず、VS CodeでPython環境ができて、VS CodeのTerminalでPythonのプログラムが実行できるのはわかった段階です。いくつか、今後調べながらやる必要があるものが残っているのでメモとして残しておきます。

マルチコンテナ化

今回Dev Containerに対応したプロジェクトでは、検索エンジンもDockerのコンテナとして起動して、Pythonのプログラムから接続したいと思っています。となると、docker composeでいろいろと起動するほうがネットワークなどの設定も楽になるのでは？と思っているところです。 Dev Containerのテンプレートがいくつか用意されており、その中に「Python 3 & PostgreSQL (postgres)」というのを見つけたので、このあたりが参考になるのでは？と考えているところです。

pre-commitではなく、保存時にフォーマット

pre-commit＋localのコマンドも動くようにはなったのですが、保存時にフォーマットなどをかける設定もISIDのブログで記載がありました。コミットしようとして、怒られるよりも、保存時に怒られたりするほうがいいかも？という気分になってきています。どこまでが切り替え可能なのか？なども見ながら対応してみようかなと。

もう少し開発してみて改善点を探っていく

とりあえず動いたという段階です。 PyCharmとの違いがあるはずで（たとえば、git周りのGUIの違いとか）、そのあたりでどんな違いがあり、どんなものがあると嬉しいのか？といったものを調べる必要もあるかなと考えています。 TerminalでCtrl+rがうまく使えなかったり(Auto Hot Keyで検索のショートカットに割り当ててしまっているから。。。)などもあるので、この辺も調べていきたいなと。 Windows Terminalを使えたりするのかなぁ？

まとめ

さて、とりあえず、VS CodeでPythonのDev Container環境を作って動くところまでは来ました。 PyCharmを使いこなしていなかったのもあり、それほど違和感なく移行できるような気がしています。調べることはまだまだあるし、プログラム書くつもりが、環境を整える方向に話がずれている気もしますが、まぁ面白いのでよしとするかなぁ。いろいろまだまだ知らないことだらけです。。。

pre-commitとvenvとPyCharm（困ったな？）

Mon, 10 Jul 2023 10:55:48 +0900

最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。

きちんとPythonのプログラムをプロジェクトとして書いたことがないので、 Pythonのプロジェクトのディレクトリ構成などを手探りで進めているところです。コードのフォーマットとかもやらないとなぁ？と知り合いのいるSlackでつぶやいたところ、gitのpre-commitフェーズでblackなどのフォーマットやスタイルを修正してくれるツールを実行する方法を教えてもらいました（PRまで送ってもらえたのでありがたい）。

で、pre-commit周りの設定などを変えている段階で遭遇した問題点についてログを残しておこうと重いブログを書いています。残念ながら現時点では解決してないんですけどね。。。

手元の環境

簡単に環境を書いておくとこんな感じです。

Windows上のPyCharmを開発で使用
プロジェクトのディレクトリはWSL2のUbuntu上
Python、gitはUbuntuのものを利用
プロジェクトのルートディレクトリにある.venvにvenvでPythonの仮想環境を作成してある

問題点

遭遇したpre-commitの問題点は次の通りです。

pre-commitの設定でrepo:localでローカルのプロジェクトにインストールしたコマンドを利用するように変更
すると、PyCharmでコミットすると、blackなどのコマンドが見つからない
ターミナルでコミットするときはきちんと動作する

色々調べて試行錯誤した結果、現在はrepo:localでのローカルコマンドを使用する方法はあきらめました。移行は、作業記録みたいなものです。どういう流れでpre-commitを取り込み、ローカルに切り替え、切り戻したかという話です。

pre-commitとpre-commit

最初に少し戸惑ったのは、pre-commitというツールとgitのpre-commitフックです。 gitのpre-commitのフックのために作られたPython製のpre-commitというツールがあります。

このPython製のツールを利用することで、プロジェクトに.pre-commit-config.yamlという設定ファイルを置けば設定に記述されたツールをgit commitのタイミングで実行してくれます。実際には、pre-commitというツールの初期設定のタイミングでpre-commit installというコマンドを実行して .git/hooks/pre-commitというスクリプトが生成されます。 gitコマンドはcommitされた時に（commit前のフェーズ）でこのスクリプトを実行し、そこで.pre-commit-config.yamlが参照されています。

.pre-commit-config.yamlの記述は次のようなものになります（最初にもらったPRより）。

repos:
  - repo: https://github.com/psf/black
    rev: 23.3.0
    hooks:
      - id: black
        args: ["--line-length", "120", "."]
  - repo: https://github.com/pycqa/flake8
    rev: 6.0.0
    hooks:
      - id: flake8
  - repo: https://github.com/pycqa/isort
    rev: 5.12.0
    hooks:
      - id: isort
        args: ["--profile", "black", "--filter-files", "--multi-line", "3"]
  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.4.1
    hooks:
      - id: mypy

実際に、PRを取り込んで動かしてみたところ、blackなどが動いて行末のスーペースの除去や未使用のimportについて指摘をしてくれました。便利だなと思ったのですが、ここで疑問が。

今回は対象とするプロジェクトはpoetryで依存パッケージの管理を行っています。今回、上記を動かすためにpoetryに追加されたものはpre-commitだけでした。「あれ？blackとかはどこにあって、どうやって動いてるんだ？」という疑問が出てきます。コンフィグファイルにはパスなどの記載をせず、それぞれのgithubリポジトリの記載とバージョンがあるからです。

pre-commitが使用するツールのインストール先

調べてみたところ、どうやらホームディレクトリにある.cache/pre-commitにblackなどのコマンドが見つかりました。 pre-commitツールが設定ファイルを基に、必要なコマンドをgithubからダウンロードしてきて実行時に利用しているようです。 pre-commitは便利なのだけど、せっかくPythonのプロジェクトだしそれぞれのツールはpoetryでpyproject.tomlでバージョンや設定を管理したほうがすっきりするのではないか？ということで、少し調べてみました。

同じようなことを考えている方がブログを残していてくれました（Pythonレポジトリ用のpre-commit環境を整える）。設定をpyproject.tomlに移行し、そのあと、ローカルのpetryでblackなどのコマンド類をインストールして利用する設定に書き換えています。先人の肩に乗っかって、手元で同じようにpre-commitの設定ファイルのrepoをlocalに書き換えていき（その時のコミット）、ターミナルでpoetry run pre-commit run -aで動作確認できました。

PyCharmでコミットしたらエラー

ですが、実際に変更した状態でPyCharmからコミットしたら、コマンドが見つかりませんというエラーが出ます。。。 WSL2のターミナルでgit commitした場合は問題ありません。どうして？となりますよね。。。。

.git/hooks/pre-commitはPyCharm、ターミナルのどちらからも実行されています。ですが、PyCharmではblackなどが見つからないというエラーが出ました。

.git/hooks/pre-commitを見てみると、python実行するためのpythonのパスはプロジェクトにある.venv/bin/pythonを指定しています。デバッグのために、このスクリプトにecho $PATHを差し込んで、git commitをPyCharmとターミナルからそれぞれ実行してみたところ、大きな違いがあります。

ターミナルで実行した場合は、<プロジェクトのディレクトリ>/.venv/binもPATH環境変数に存在していました。このため、.venv/binにあるblackなどを実行できています。

PyCharmはWindowsから起動しています。プロジェクトのインタプリタとしては、WSL2のUbuntuにある.venv/bin/pythonを指定しているためもあり（？）、出力されたパスは/mnt/c/などのWindowsのパスなども入っていたりしますが、<プロジェクトのディレクトリ>/.venv/binは見つかりません。

ここからはソースコードは読んでいないので憶測ですが、.git/hooks/pre-commitで呼び出されているpre-commitツール（Python製）は、設定ファイルで指定されたコマンド（blackなど）を、コマンドとして今の呼び出されたコンテキストで実行しているのではないかということです。実際、ターミナル上でもsource .venv/bin/activateを実行していない状態だとコマンドが見つからないというエラーが出ました。

対処方法は？

ということで、今考えられる対処方法としては次の通りです。

.git/hooks/pre-commitのスクリプトを修正して、<プロジェクトのディレクトリ>/.venv/binのパスを見えるようにする
PyCharmで何かしらの設定を探す
PyCharmではgit操作しない
repo:localはあきらめて、.pre-commit-config.yamlでblackなどは管理して、pyproject.tomlからは除外する

1.ですが、.git/hooks/pre-commitはprecommit intallを実行すると自動で生成されるスクリプトです。自分の環境で書き換えたとしても他の人が同じ環境を作るときにパッチを当てるなどをしないといけなくなります。

2.はそれらしい設定を見つけることができませんでした。

3.はめんどくさいですよね。。。ターミナルでgitのコメントを日本語で書くためにいくつか他の設定を考えないといけないです。。。

ということで、今回は4.の対処をとりました。やりたいことは、ツールや環境をそろえるのではなく、プロジェクトでやりたいことをやることなので。。。

まとめ

最終的には元に戻ってしまいました（pyproject.tomlに設定周りは移動した）。 Windows環境がちょっとややこしくしてるかもな？というのと、個人のプロジェクトなのでそこまで気にしなくてもいいのでは？というのもありそうです。それにしても、世の中の皆さんはフォーマッターとかどのタイミングで動かしてるんだろう？とかどういう環境構築してるんだろう？とか気になってます。最近だとこういうディレクトリ構造にする、こういうツールを使うと便利などあれば、コメントいただけると嬉しいです。

教えてもらったISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）も参考にさせてもらおうと思ってるところです。Pythonの環境をコンテナに移動したいなぁというのもあるので。ただ、PyCharmだからこのブログの通りには行かないけど（VS Codeに移るのも検討したほうがいいのかなぁ）。

参考サイト

今年もオンラインでBerlin Buzzwordsに参加した

Wed, 21 Jun 2023 01:30:45 +0900

今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。今年もハイブリッド開催をしてくれたので、オンラインで参加できました。現地ではブースが出たり、朝食なども用意されているようでした。今年は昨年と違いマスク必須でもなくなったようです。 MICESも去年同様、現地開催のみのようです（今見たら、昨年のビデオとスライドが公開されてるので、時間見つけてみてみよう）。

今年はうれしいことに検索に絡むセッションが大多数でした。世の中的にChatGPTの盛り上がりやベクトル検索がいろんな検索エンジンで使えるようになってきたこともあり、大規模言語モデルと検索エンジン、ベクトルデータベースに関する話がたくさんありました（昨年まではKafkaやストリーム処理の話も多かったんですが）。

ということで、今年もセッションを見ながら残したメモを公開しておきます。

簡単にメモ

What defines the “open” in “open AI”?

セッションページ：What defines the “open” in “open AI”?
動画： Jennifer Ding - What defines the “open” in “open AI”? - YouTube

“OpenAI"の話ではなく、オープンなAIとは？という話で、ライセンスの話であったり、コミュニティ（データセットの公開とかベンチマークの共有とか）に関する話であったり。後半は気を抜いてしまって話をうまく聞き取れてないので、興味がある方はビデオで。。。

Vectorize Your Open Source Search Engine

セッションページ：Vectorize Your Open Source Search Engine
動画： Atita Arora - Vectorize Your Open Source Search Engine - YouTube

ベクトル検索が流行ってきてるけど、これまでの検索（エンジン）に対して、どうやってベクトル検索を取り入れる？という話です。ベクトル検索ってどんなもので、どういうことの助けになりそうか？じゃあ、どうやって、これまでの検索が改善したかを見ていくのか？という、これからベクトル検索を取り入れようとしている時にどのようなアーキテクチャにして、どのような考慮するポイント（モデルの選択とかスケーラビリティとか）にどんなものがあるのか？といった紹介でした。ざっくりですが、ベクトル検索やるのにどんなことをやっていけばよいのか？という地図になるようなセッションでした。

Supercharging your transformers with synthetic query generation and lexical search

セッションページ： Supercharging your transformers with synthetic query generation and lexical search
動画： Milind Shyani - Supercharging your transformers with synthetic query generation and lexical search - YouTube

AWSの人の話でした。こちらもトランスフォーマーが検索に使えると便利だよねという話なのですが。 LLMを使うと高コストでサイズがどんどん大きくなっていて、小さな学習済みのモデルだといまいちな精度でだし、ファインチューニングしたい場合、ドメインに特化したデータはなかなかないよね。とくにデータ（検索したいもの）はあるけど、クエリがないということがよくあるよね。そこで、LLMを使って、データからクエリを作って、正解データを作り、それでファインチューニングすればいいのでは？ということで、やってみました、どうでしたという話でした。

ブログなどもあるので参考にすると面白いかも

The Debate Returns (with more vectors) Which Search Engine?

セッションページ：The Debate Returns (with more vectors) Which Search Engine?
動画：Charlie Hull - The Debate Returns (with more vectors) Which Search Engine? - YouTube

今年も検索エンジンの人を集めてパネルディスカッションです。今年は次の方たちが参加してディスカッションでした。

参加者
- Jo：Vespaの人。ランキングとかがよくできてるからVespa好き
- Alessandro：Apache Solrの人。SolrのPMCメンバー。なんでSolr？Pure OSSだし。スケーラブルだ
- Etienne：Weaviateの人。新しいAI nativeなベクトルデータベース
- Philipp：Elasticの人。
- Kacper：Qdrantの人。

質問は次のようなものでした。

最初の質問：スケールの話。スケールアウトかな？
2つ目の質問：どんなアプリケーションが適していないか？
3つ目の質問：どうやってAIをサポートできるの？
4つ目の質問：どうやってコミュニティにアプローチしてる？
5つ目の質問：自分の検索エンジンが使えない時に何を使う？
6つ目の質問：今後に何が面白そう？
最後の質問：あなたの検索エンジンが使われてるユースケースで一番好きなものは？

2つ目や5つ目の質問が面白いですよね。実際の内容はぜひビデオを見ていただくのがいいかと（メモも取ったけど、聞いてもらうほうが面白そうだし）。

What’s coming next with Apache Lucene?

セッションページ：What’s coming next with Apache Lucene?
動画：Uwe Schindler - What’s coming next with Apache Lucene? - YouTube

毎年恒例Uweさん。今年Luceneが25周年という話で、これまでの進化の話を駆け足でしてくれました。あとは、後半は来週9.7が出るよということで、9.7で入ってくるベクトルの距離計算の最適化に関して説明してくれています。次のバージョンのElasticsearchでもこの最適化が使えるようになるという話もされていましたので、ベクトル検索を使ってる方は、次のバージョンも楽しみですね。

Building MLOps Infrastructure at Japan’s Largest C2C E-Commerce Site

セッションページ：Building MLOps Infrastructure at Japan’s Largest C2C E-Commerce Site
動画：Berlin Buzzwords 2023： Building MLOps Infrastructure at Japan’s Largest C2C E-Commerce Site - YouTube

メルカリの検索システムに関係しているMLOps周りがどうやって進化してきたのか？という話でした。英語にいらすとやの絵があるスライドがドイツで使われているのがとても新鮮ですｗ

Highly Available Search at Shopify

セッションページ：Highly Available Search at Shopify
動画：Khosrow Ebrahimpour - Highly Available Search at Shopify - YouTube

Shopifyの検索プラットフォームチームの人の、Shopifyの検索プラットフォームがどういったものか？（EsとKafka使ってる）どんな工夫をしているか？という話です。 Kubeconでも他の同僚の方が話をされている見たいで、そちらも参考になるとのことでした（動画）。スキーマ変更時の話とかもあり、実践的でした。最後に将来的な話でやはりベクトル検索というキーワードが出てきていました。あとは、データ量が大きいのでスケーリングの挑戦もあるとのこと。

Using Dense Vector search at the EU Publications Office

セッションページ：Using Dense Vector search at the EU Publications Office
動画：Martin Bayton - Using Dense Vector search at the EU Publications Office - YouTube

EUのPublication Office（日本だと公文書館とかになるのかなぁ？）の検索サービスで、Googleみたいなこと（検索結果の上にスニペットが出たり、そこにハイライトされたり）をやってみたいよね？という話みたいでした。実際公開してるかはわからないですが、途中からはPureinsightsという会社のプラットフォームで似たようなことをやるデモになってました。

Googleでも12%のクエリが、質問の自然文になっているという話で、検索結果にナレッジグラフからの情報（スニペットとか、質問に対する答えとか、地図とか）が出るようになってきていますと。それをPublication Officeのデータで再現したデモを行った後に、どんな感じのアーキテクチャなのか？という概略を説明されています。国会図書館とかの検索サービスやってる方が興味を持ったりするかもなーと思ったり、思わなかったり？

Learning to hybrid search

セッションページ：Learning to hybrid search
動画：Berlin Buzzwords 2023： Learning to hybrid search - YouTube

これまたキーワード検索とセマンティック検索のハイブリッドの話です。よくハイブリッド検索というのを聞きますが、データだったりベンチマークなどの話があまりないですよね？昨年AmazonがECSIというデータセットを公開したりしています（rejasupotaroさんが年末に書かれた記事にも出てきていました）。これにLearn to Rankとかもテストできるようなデータ（レビューや評価、カテゴリーとか）を拡張したものを作って、それをもとにいろいろとハイブリッド検索で精度を測ってみたというお話でした。 Metarankというリランキングエンジンの会社の方たちで、Metarankを使ってハイブリッドな検索結果のリランキングで精度がどのように上げられるか？という話です。今年のTRECのProduct Search Trackの話もされていました。これが元ネタのブログかな？

Catch the fraud — with observability and analytics

セッションページ：Catch the fraud — with observability and analytics
動画：まだ？

最後は元同僚のセッションです。こちらは検索ではなく、ちょっと自虐的なネタをもとにしたオブザバビリティおよび分析のお話です。コミュニティの人たちの貢献（ブログ書いたりプルリク送ったり、どこかで話をしたり）を計測して、年間の貢献者に対してプレゼントを上げるというのをやっているみたいです。で、昨年の最も貢献した人にMac Bookをプレゼントするというすばらしい（暴挙）話で、チートしようとした人がいてそれを分析した話でしたｗ締め切り直前に信じられない量の貢献したという登録がブラジルからあり、何かおかしいよね？ということで、Elastic Stackのオブザバビリティの機能などを元に分析してチートした人を除外していったよという話でした。 Kibanaが使いやすくなってるのがわかるセッションで面白かったです。

まとめ

検索がまたすごく盛り上がってきたなーという時間があるカンファレンスでした。みんな似たような話（ベクトル検索、LLM、AIなど）だったりしますが、知らないプロダクトで興味が出てくるものもあったし、Amazonのデータセットがあるからいろいろ試してみることもできそうだなぁと。

すでにビデオが公開されはじめているので、気になったセッションのビデオも見てから後日またブログを書こうとおもいます（たぶん、一覧が作成されるので後日リンクを貼っておきます）。

来年の予定（6月11日から開催）も公開されていましたし。来年も楽しみですね。来年はプロダクションでベクトル検索やってみた話とかがさらに出てくるのかなぁ？

今年の振り返りと来年の抱負（2022）

Sat, 31 Dec 2022 20:38:04 +0900

今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。

振り返り（2021年に書いた抱負から）

まずは振り返りをと。

フリーランス継続

ありがたいことに個人事業主として今年も１年乗り越えられました。 ZOZOさんには引き続きお世話になっている感じです。 10月からは今月末まで別のお客さんを手伝っていたりという感じでした（アップグレードの手伝いとか）。相変わらず完全リモートで作業をさせていただいてます。

ただ、来年は今の所、余力がある感じになっているので、新しい仕事を見つけたいところだなあという感じです。検索で何かお手伝いできることあれば、気軽にお声がけいただければと。

プログラミング

Linderaの大須賀さんのおかげで、レビューは定期的にやらせていただいてますw 業務がっつりというほどではないのですが、検証用のコードを書いたりはしています。

個人用では、BGM環境のためにシェルを書いたり、文字化けしてるデータを解析したりするのにコードを書いてますが、もうちょっと量を増やしたいところです。コードがっつり書く仕事をやらせてもらうのとかやらせてもらうのがいいかもなぁ。

書くよりもどうしても読むほうが多くなってる気がします。

ブッチャー本ちゃんと読む

全部ではないですが、ZOZOさんで輪読をしたりしていました。が、自分で全部読むといったところまではできてないです。

読んだ本のブログを書く

これはできてないですね。読むのはちょとちゃってるんですが、ブログを書くところまではできてない。メモとりながら読みたいですね。

振り返り(今年あったできごと)

ここからは今年の出来事を。今年もずっと自宅で仕事した。来年は出張とかできるのかなあ？

自宅環境
今年もDIY
検索ペンギン本が出版された

仕事場を模様替えしました。今年もずっとWindows環境をメインで仕事をしていました。年末まではM1 Macを借りて作業するという経験もできたのでよかったです。今年仕事の環境は少し変わって、AVアンプ（譲り受けたもの）＋Polk Audioのスピーカーで音が良くなりましたw あと、机の天板を大きくして、作業がやりやすくなりました。写真はそのうち。

仕事場の模様替えにもなるのですが、今年のDIYはラブリコ＋有孔ボードでケーブルやキーボードをすっきり片付けられる環境を作ってみました。壁を有効活用できるのはよかったです。こちらについては、別途ブログを書こうと思います。

今年最大のニュースは検索ペンギン本を出版したことです。声をかけていただいた打田さんには感謝です。著者の皆さん検索システムを色々と手掛けられているので良い本になったと思います。

『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート

おー、届いたー pic.twitter.com/RbY5tOe9GB
— Jun Ohtani (@johtani) May 17, 2022

いろんなところで輪読も開催されているようで、顔を出してみたいなぁ。輪読やってます！外部の人を呼んでもOKという方がいたら、参加してみたいのでTwitterでメンションしてもらえると嬉しいです。

来年の抱負

ということで、来年の抱負です。

フリーランス継続
プログラミング
ベクトル検索まわりをさわる
本を読む

今年もありがたいことに仕事を継続していただけて、乗り越えられました。来年も価値を提供できるように頑張っていきます。もっといろんな会社の検索システムを見てみたいですし、検索エンジン入れてみたけどここからどうすればいい？という方も増えて来ているような気がするので、気軽に声をかけていただければと。

プログラミングは、家の音楽ファイルの文字化けを直すプログラムをもう少しちゃんと書いてからブログを書きたいなと。まぁ、個人的なプログラムなので誰も嬉しくないかもですが（色々検討した結果Javaで書いてる）。あとは、オライリーさんの初めてのGo言語を買ったのもあるので、前にRustで書いたElasticsearchへのBulk登録のツールをGoで書いてみようかなと考えているところです。みんなはデータ登録するときはどうしてるんだろう？

NLPでBERTなどによる目まぐるしい進歩の影響もあり、ベクトル検索やセマンティック検索といった検索技術が各社から出て来ています。 ElasticsearchでもGAされたのもあり、今後ますます注目を浴びる技術になるのだろうなと。ただ、これまでの検索とどう組み合わせるのがいいのか？どう言ったメリットデメリットがあるのか？向き不向きは？といったものもあるので、仕組みを調べながら色々と試行錯誤してみたいと思っています。

さいごは、毎年書いてる気もしますが、本を読むのもやらんとなぁ。あたらしいネタを仕入れては実践できる時間もとりつつ、他のことにも目を向けたいと思っています。

今年は仕事の変化も少し出て来ているので、来年は新しいことをいくつかやってみたいところです。あとは、外に出る機会が増やせるといいなぁ、少しずつ人から刺激をもらいたいと思っています。

さて、今年は年内に無事描き終わりました。来年もよろしくお願いいたします、良い年にしたいなー。

仕事中のBGM環境

Thu, 15 Dec 2022 00:05:58 +0900

PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。今年はDIYではなく、PCにまつわる話を。

仕事中はBGMが基本

フリーランスを始めて（2020年初頭）からすぐに、自宅で仕事をする情勢になりました。打合せをしていないとき、カンファレンスの発表などの動画を見ていないときは基本的にBGMをかけて作業をしています。音源としては、CDなどから音楽ファイルにしたり、AmazonやSonyのサイトで購入した音楽ファイルなどがNASにあります。

今年10月までの環境

2020年の後半に次のような環境を構築して今年の10月まで使っていました。

LibreELECをラズパイ4に入れて、Kodiのリモコンをスマホに入れたら快適になった
— Jun Ohtani (@johtani) October 20, 2020

KODIと呼ばれるマルチメディアセンター？のようなソフトで、それを動かす最小限のOSとして、LibreELECが公開されています。これをラズパイ4に入れて、NASからファイルをSSDにコピーしてそれをラズパイに接続して音楽を聞いていました。毎回ラズパイの画面を見に行くのも面倒なので、再生などの操作にはAndroid用のKodiのリモコンアプリを使っていました。

場所も取らないのでよかったのですが、使っているといくつか問題点が。

時々調子悪（音が出ない、リモコンからつながらない、無反応など）くなって、ラズパイ再起動
音楽ファイルを購入して増えた時に、外付けSSDを取り外してPCでコピーしたり
スマホじゃないと再生できない（PCのクライアントもあったのかもだけど調べてなかった）

Ubuntu on Mac mini

10月に模様替えをして、2012年製のMac Miniが宙ぶらりんになりました。さすがに古いしメインマシンがWindowsになっているのもあり、macOSである必要も特にないので、Ubuntu 22.04を入れて何かに使えるのでは？と。また、1TBのSSDに内臓ディスクを乗せ換えていたのもあり、音楽再生に使ってみようということに。なので、Kodiの環境で困っていた点も考慮して、ほしい機能を元にちょっと探してみました。

音楽再生 on Ubuntu

音楽再生でほしい要件としては次のようなものです。

Ubuntuで音楽再生できるソフト（あたりまえ）
PCから操作したい（できればブラウザ）
音楽ファイルの更新（ローカルでもいいけどNASからもってきたり）
日本語の曲情報も表示
対象音楽ファイルが豊富（そんなに制限があるものはないだろうなぁ）

上記の要件をもとに適当にググって見つけてきたのがOwnToneというソフトでした。

OwnTone

OwnToneの説明は公式サイトを見ていただくとして、OwnToneにしてよかったなというのが以下の点です。

インストールが簡単（apt-getでインストールできる）
サポートフォーマットが豊富
Web UIがついてる（ブラウザで見えるし、スマホでもOK。どのブラウザから見ても今の状況も分かる）
簡単だけど検索できる
プレイリスト対応（ファイルパスを入れるだけ）
サムネイルとかも出てくる（どうやってんだろう？ｗ）
AirPlayで再生できる（AVアンプを利用しており、そこにAirPlayで再生できてる）
OSS（まだソースは見たことないですがｗ）

再生画面例

やっぱ検索も気になるよね？

日本語も検索できるな。 pic.twitter.com/EF6WHkJKli
— Jun Ohtani (@johtani) October 19, 2022

とりあえず、インストールして画面もすぐに出て操作も簡単で、便利な世の中になったなーと感動しましたｗ

ただ、音がヘッドフォン端子に刺したアナログ出力先のスピーカーではなく、本体のスピーカーで最初はなってしまいましたｗｗ
Linuxの音周りが全然わかってない問題が発覚。

幸い、先週のPyspa Advent Calendarのエントリーを書いていたaodag先生に助言をいただき、alsamixerで音の設定を見たところ、ヘッドフォン端子がミュートされていたので、ミュートを外して無事再生できました。インストール当初はYAMAHAのアクティブスピーカーにJust Mixer経由でヘッドフォン端子（アナログ）で出力して音楽再生をしていました。今は（この記事を書いてる現時点で）、AVアンプのAirPlayにOwnToneから音を流している形で聞いています（便利なんだけど、当初の想定とは異なる、理由は後述）。

ファイルのコピーとか

さて、上にも書きましたが、NASにバックアップもかねて音楽ファイルを保存してあります。新しく買ったファイルもここに置くようになっています。 OwnToneのMac MiniからNASをネットワーク経由で見に行くのもいいのですが、できればローカルにあったほうがネットに影響も出ないなと。

ということで、定期的にNASをウォッチしてMac Miniにファイルをコピーするようなプログラム（Bashスクリプト）を書いてみました。毎回購入後に手で実行もめんどくさいので毎日夜中にcron実行するような設定になっています。

スクリプトの中身は次のような感じです。

findコマンドで特定の日時（最近コピーしたファイルの日付）以降(-newermtオプション)のファイルのリスト（音楽ファイルの拡張子に限定）を取得
取得したリストをもとに以下の操作
- ファイルをコピー
- コピーしたファイルをコピーした日付のプレイリストを作って入れる（プレイリストはパスだけ書けばOK）
- mp4形式だと聞けない端末もあるので、soundconverterコマンドでmp3に変換してNASに戻す
- 最新のファイルの日付を保存（次回のfindコマンド）
ファイルがあったら、OwnToneの再読み込みのエンドポイントをcurlでキック

NASはSambaでマウントして、見えるようにしてあります。やっぱり、自動化便利ですねぇ。気に入った曲を買ってNASに入れとけば聞けるようになるのは本当に便利。

他にもスマートプレイリストとかもあるので、活用しないとな。

今後の課題

さて、すごく便利になったのですが、課題も残っています。

音声出力問題

アナログ出力はaodag先生の助言ですぐに解決したのですが、takabowから譲り受けたAVアンプを導入してから実は音の出力がうまくいっていません。

HDMI、光端子出力でAVアンプにつなごうとしたのですが、私のUbuntu力（Linux力？）が全然不足しているのでうまくいっていません。ググりつつ、HDMI、光出力でamixerというコマンドで音声ファイルを鳴らすところまでは行ったのですが、OwnToneに設定するとうまくいかない状況です。結局、解決してないのですが、AVアンプのAirPlayのレシーバー経由で音楽再生ができてしまったので、とりあえずAirPlayで運用することにしました。時間を見つけてaodag先生の記事を読み直して再チャレンジしないとな（けど、鳴ってるしなぁ、音ｗ）。

文字化け問題

これは、OwnToneというよりはもともとあった問題です。古い音楽ファイルだったり、Wav形式のファイルなど、様々な形式のファイルを持っています。音楽サーバーとは別に、音楽ファイルの検索をできるようにしつつ、付加的な情報（Wikimediaなどのデータとか）を付与して、検索できるようにしてみようと思い、音楽ファイルからメタデータを抜き出して、ElasticのApp Searchにいれるデータを作るツールを書いたりしています。この時にも文字化けに遭遇しました。

様々な音楽ファイルにはメタデータを付与することができる仕様が決まっています（ID3タグ - Wikipediaなど）。ただ、文字コードの情報が入っていなかったり、デフォルトとは違う文字コードでデータを付与したファイルがあったり、いろいろな原因で文字化けしているものがあります。昨年Amazonで購入したmp3の中にも文字化けしているものもあったりします。Wavファイルに付与されたタグなどは、容赦なくShift-JISだったりしますが、読み込むソフトはUTF-8で読もうとしたり。。。

検索サーバーにデータを抜き出して入れるツールを書いているときは、元のファイルを変更することなく、抜き出す時点でいくつかの文字化けに対応した処理を書いたのですが、今回のOwnToneで曲を流すと結局、元のファイルをきれいにしないとダメだということに気づきました（すぐわかるだろ。。。）

ということで、書いている途中のツールをもとに、根本的な文字化けのファイルのメタデータをきれいにするプログラムを書かないといけないなぁと。

ちなみに、メタデータの抜き出しにはJavaでプログラムを書いており、JAudiotaggerというライブラリを利用しています。 Pythonや他のJavaのライブラリを試そうとしたのですが、文字コードが決め打ちで抜かれているものが多く、ライブラリから読みだした時点ですでにどうしようもない状態のものが多いといった問題からこのライブラリにたどり着きました（まぁ、まだちゃんとしたものができていないんですけどね）。

検索サーバー

OwnToneのUIはブラウザでうごきます。検索窓もついています。が、先ほども書いたように、他にもデータを追加して、いろんな検索をしてみたいなぁと（ドラマに使われてたとか、CMにつかわれてたとか）。検索が好きでいろいろとやってるので、その辺も遊んでみたいなぁと思っているところです（実際、ElasticのApp SearchにWikidataから生成した類義語を入れてみたりしている）。

こうやってブログにしてしまったので、課題をつぶしていなかったら、Twitterなどでつついてくださいｗ

まとめ

構成図とかは書かなかったですが、OwnToneを使うと簡単にWeb UIが入った音楽サーバーが使えるようになって、仕事がはかどりますよという記事でした。他にもこれに関するネタを募集してますので、コメントもらえるとうれしいです（Twitterでメンションも大歓迎）。

ElasticsearchクライアントライブラリとSpecification

Wed, 14 Dec 2022 00:00:00 +0000

ElasticsearchのアーキテクチャとStateless / Serverless

Fri, 09 Dec 2022 01:15:25 +0900

本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。

だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。という感じで、Suggesterのデータ構造とか仕組みを書こうと思っていたのですが、思ったよりも調べないといけないことが多くて挫折しました。。。（これの続きは年末年始で調べて書くはず？）

ということで、代わりにElasticsearch/OpenSearchのアーキテクチャの変更に関してさらっとまとめて~~お茶を濁して~~みようと思います。

発端はElasticON Tokyo？

先週の11月30日に、ElasticのオフラインイベントであるElasticON Tokyoが開催され参加しました。参加しようと思ったのは、10月の頭にElasticのブログで公開された「Stateless — your new state of find with Elasticsearch」というアーキテクチャの変更がきっかけです。

（図はElasticのブログから引用）

ElasticsearchはLuceneのインデックスを分散したシステムとしてスケールアウトできるようにするという目的でリリースされました。インデックスをシャードという単位で複数のElasticsearchのノードにデータを保存し、レプリカを作ることで分散する仕組みを実装していました。 Elasticsearchでは、インデックスのレプリカは、作成したインデックスを定期的にコピーするのではなく、登録するデータがElasticsearchのクラスターにやってきた時に、データ自体をコピー先にも配り、プライマリーやレプリカとなるシャードがあるノード上でそれぞれインデックスに登録する処理を行うという処理の流れです（古いけど、わかりやすい説明はこちら）。この場合、インデックスにデータを登録する処理（転置インデックスのデータ構造に変換する処理など）は、レプリカの数だけ同じ処理がクラスター上で発生します。

この基本的なアーキテクチャをもとに、保持するデータの鮮度（新しいデータのほうが検索頻度が高い、インデックス登録する時はマシンは多く、古くなったデータが入ったインデックスはコストが低いマシンになど）などを元に、クラスター内のノードの特性を異なるものが混在するような複雑な仕組みを作ってきました。いろいろなデータの持ち方などで多くのデータなどを保持できるようにしてきたのですが、クラスター全体としては、検索の負荷のピークをさばけるような構成を基本的に保持しておくというかんがえです。

ただ、昨今は必要に応じてスケールアウト（リクエストが増えたりデータ量が増えた時）、スケールイン（夜中は利用者が少ないからクラスターを小さくしたい時）できるような仕組みのほうが求められています。そこで、発表されたのが上記のブログであり、上図の新しいアーキテクチャです。計算処理（データを登録、検索する処理）とストレージを分離し、さらに登録する処理と検索する処理も分離した構成です。このようなアーキテクチャにすることで、登録処理の演算コストがレプリカごとに必要ではなくなり、検索の部分だけだったり、登録の部分だけをスケールアウト・インできるような自由度が手に入ります。また、ストレージ部分でレプリカを担保（S3とかのオブジェクトストレージで冗長性を担保）できれば、レプリカのストレージコストも必要なくなります。

というブログが発表されたのですが、詳細などはまだよくわからなかったのでElasticON Tokyoに参加して詳しい話が聞けるのかなぁと期待していました。

参加当日の朝のびっくりするニュース

11月30日の朝に起きて、出かけようかと思っていたところに、AWSのre:Inventで発表されたニュースが舞い込んできました。

ほー（まだタイトルしか読んでない）https://t.co/KK22duaBNH
— Jun Ohtani (@johtani) November 29, 2022

Amazon OpenSearchがServerlessオプションを発表というニュースです。（Amazon OpenSearchとは、AWSがElasticsearchをフォークして始めた検索エンジンで、Amazon OpenSearch Serviceというのは、AWSがそれをSaaSとして提供しているものです）

まぁ、気になりますよね、「Serverless」ってキーワードに。 ElasticON Tokyoに向かう電車でブログを読んだり、どんな仕組みかを調べたので、それを簡単にまとめておきます。

プレビュー段階（Tokyoリージョンではもう試せる）
これまでのAmazon OpenSearch Serviceとは別（オンザフライで移行はできない？）
「コレクション」という単位でクラスターを管理（スケールインとかアウトとか）
コレクションにはタイプがあり、タイムシリーズ（ログとか）か検索のユースケースなのかで使い分ける（公式ドキュメント）
インデックス処理と検索処理で計算ユニット（OCU）が別々にスケールできる（下図）
作成されたインデックスはAmazon S3に保存され、そこで冗長性は担保される。（下図）
検索処理のユニットはS3のデータをローカルに持ってきて処理をできる
データ登録とかのAPIは基本的にServerlessかどうかで違いはなさそう(これまで通りのクライアントでアクセスとかで競う)
設定した範囲でいいかんじにスケールアウトインしてくれそう（ほんとかな？）
もちろん、いくつか制限がある（サポートしてないプラグインとか操作もある）

（図はAWSのドキュメントより引用）

発表時のブログでは詳しくはわからないのですが、公式ドキュメントではさらに詳しく説明がありました。こちらを読むほうが仕組みがわかると思います。今後もどんどんドキュメントは充実していくんだろうなと。今ならまだサクッと読める量ですｗ

ただ、「サーバーレス」という定義が私はよくわかりませんでした。公式ドキュメントを読むとコレクションを作ると少なくとも4つのOCUが起動しているみたいで課金されると記載があります。

まぁ、Elasticの発表と同様に、これまでは最大負荷の時を元にクラスターを維持せずとも、より柔軟に検索だけ、登録処理だけを一時的にスケールできるとコストを下げられそうですね。すぐに誰かが使ってみたブログなどを出してくれると思うので、細かな使用感などはそのうちわかってくるかと。

今後は？

ElasticもAWSも考え方の基本となっているのは、Berlin BuzzwordsでAmazonのMikeさん（Luceneのコミッター）が2019年に発表されたものだと思っています。アーキテクチャの変更がどんな影響が出るかはわからないですが、少なくとも検索のユースケースでよりスケールアウトしやすくなるだろうなと。どちらもSaaSとしての仕組みとして提供するので、検索エンジンそのものの機能として公開されるかはわからないです。ですが、そのほかの検索エンジンも出てきていますし、今後も検索エンジンから目をはなせないです。今回は残念ながら触っていませんが、時間を見つけて使ってみたいです（Elasticも早く出してくれないかなー）

ということで、当初の予定とは違うブログになってしまいました。。。技術的な深い話はまたどこかで。。。

参考文献

ローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）

Wed, 10 Aug 2022 11:50:02 +0900

前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。

今回はもう少し、いろんなパターンを試してみたいと思います。

ローマ字入力のゆれ

前回のサンプルでも「吾輩…」のデータをサジェストするためのサンプルとして、「wagah」という「わがはい」をローマ字にしたものを利用しました。

ちなみにローマ字というとどんなものを思い起こしますか？普通は学校で習ったヘボン式あたりだと思います。 Kuromojiの読みでローマ字出力するには通常、kuromoji_readingformでuse_romajiをtrueにします。以下、「吾輩」のサンプルです。

GET _analyze
{
  "text": ["吾輩"],
  "tokenizer": "kuromoji_tokenizer",
  "filter": [
    {
      "type": "kuromoji_readingform",
      "use_romaji": true
    }
  ]
}

レスポンス

{
  "tokens": [
    {
      "token": "wagahai",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    }
  ]
}

「吾輩」の場合は特に問題ないのですが、ローマ字による日本語入力の場合、次のような単語を入力するときに、ゆれが生じます。

シャボン＝「shabon」
新橋＝「shimbashi」

括弧内はkuromoji_readingformで出力したもの（＝ヘボン式のローマ字）です。ですが、ローマ字入力の場合は「syabon」や「shabon」と入力したり、「sinbasi」や「sinnbasi」と入力すると思います。 JapaneseCompletionAnalyzerを利用したCompletion Suggesterの場合、これらのゆれも考慮してサジェストしてくれるようになっています。前回のサンプルデータを用いると次のような感じです。

GET aozora_index/_search
{
  "explain": true, 
  "suggest": {
    "title-suggest": {
      "prefix": "sha",
      "completion": {
        "field": "suggest_ja"
      }
    }
  }
}


GET aozora_index/_search
{
  "explain": true, 
  "suggest": {
    "title-suggest": {
      "prefix": "sya",
      "completion": {
        "field": "suggest_ja"
      }
    }
  }
}

これらのリクエストは、「しゃ」について2パターンになっていますが、結果はどちらも次のものが返ってきます（このレスはsyaのレスになります）。

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "sya",
        "offset": 0,
        "length": 3,
        "options": [
          {
            "text": "シャドウ・ワーク",
            "_index": "aozora_index",
            "_id": "000739",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "シャドウ・ワーク",
                "朝倉 克彦"
              ]
            }
          },
          {
            "text": "シャボン玉",
            "_index": "aozora_index",
            "_id": "045054",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "シャボン玉",
                "豊島 与志雄"
              ]
            }
          },
          {
            "text": "上海",
            "_index": "aozora_index",
            "_id": "050899",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "上海",
                "横光 利一"
              ]
            }
          },
          {
            "text": "斜坑",
            "_index": "aozora_index",
            "_id": "002095",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "斜坑",
                "夢野 久作"
              ]
            }
          },
          {
            "text": "社会事情と科学的精神",
            "_index": "aozora_index",
            "_id": "053864",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "社会事情と科学的精神",
                "石原 純"
              ]
            }
          }
        ]
      }
    ]
  }
}

「sinnba」や「shinba」も試してみました。

GET aozora_index/_search
{
  "explain": true, 
  "suggest": {
    "title-suggest": {
      "prefix": "sinnba",
      "completion": {
        "field": "suggest_ja"
      }
    }
  },
  "_source": ["suggest_ja"]
}

GET aozora_index/_search
{
  "explain": true, 
  "suggest": {
    "title-suggest": {
      "prefix": "shinba",
      "completion": {
        "field": "suggest_ja"
      }
    }
  },
  "_source": ["suggest_ja"]
}

これらも同じ結果です。

{
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "shinba",
        "offset": 0,
        "length": 6,
        "options": [
          {
            "text": "しんばい",
            "_index": "aozora_index",
            "_id": "044942",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "しんばい",
                "村山 籌子"
              ]
            }
          },
          {
            "text": "新橋",
            "_index": "aozora_index",
            "_id": "002409",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "新橋",
                "北原 白秋"
              ]
            }
          }
        ]
      }
    ]
  }
}

入力されるパターンを想定した実装がされているので対応できている形です。使い方が楽なだけでなく、より使いやすくなってるのは便利ですね。

うまくいかないパターン

万事OKかというと残念ながらそうでもありません。うまくいかないパターンもあります（これが本当にうまくいかないかは難しい話な気がしますが）。「日本」という漢字ですが、「にほん」「にっぽん」どちらとも読めますよね？これらを試してみると次のようになります（リクエストは省略します）。

まず「にほん」

{
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "にほん",
        "offset": 0,
        "length": 3,
        "options": [
          {
            "text": "日本橋",
            "_index": "aozora_index",
            "_id": "004565",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本橋",
                "泉 鏡花"
              ]
            }
          },
          {
            "text": "日本橋",
            "_index": "aozora_index",
            "_id": "045357",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本橋",
                "牧野 信一"
              ]
            }
          },
          {
            "text": "日本橋あたり",
            "_index": "aozora_index",
            "_id": "047648",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本橋あたり",
                "長谷川 時雨"
              ]
            }
          },
          {
            "text": "日本橋附近",
            "_index": "aozora_index",
            "_id": "055666",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本橋附近",
                "田山 花袋"
              ]
            }
          }
        ]
      }
    ]
  }
}

次に「にっぽん」

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "にっぽん",
        "offset": 0,
        "length": 4,
        "options": [
          {
            "text": "日本アルプスの五仙境",
            "_index": "aozora_index",
            "_id": "056269",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本アルプスの五仙境",
                "木暮 理太郎"
              ]
            }
          },
          {
            "text": "日本出版協会論",
            "_index": "aozora_index",
            "_id": "049436",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本出版協会論",
                "嶋中 雄作"
              ]
            }
          },
          {
            "text": "日本文化と科学的思想",
            "_index": "aozora_index",
            "_id": "055750",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本文化と科学的思想",
                "石原 純"
              ]
            }
          },
          {
            "text": "日本文化のために",
            "_index": "aozora_index",
            "_id": "003183",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本文化のために",
                "宮本 百合子"
              ]
            }
          },
          {
            "text": "日本文化の特殊性",
            "_index": "aozora_index",
            "_id": "055290",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本文化の特殊性",
                "戸坂 潤"
              ]
            }
          }
        ]
      }
    ]
  }
}

最後に「日本」

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "日本",
        "offset": 0,
        "length": 2,
        "options": [
          {
            "text": "日本アルプスの五仙境",
            "_index": "aozora_index",
            "_id": "056269",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本アルプスの五仙境",
                "木暮 理太郎"
              ]
            }
          },
          {
            "text": "日本出版協会論",
            "_index": "aozora_index",
            "_id": "049436",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本出版協会論",
                "嶋中 雄作"
              ]
            }
          },
          {
            "text": "日本文化とは何ぞや（其二）",
            "_index": "aozora_index",
            "_id": "002940",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本文化とは何ぞや（其二）",
                "内藤 湖南"
              ]
            }
          },
          {
            "text": "日本文化と科学的思想",
            "_index": "aozora_index",
            "_id": "055750",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本文化と科学的思想",
                "石原 純"
              ]
            }
          },
          {
            "text": "日本文化のために",
            "_index": "aozora_index",
            "_id": "003183",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "日本文化のために",
                "宮本 百合子"
              ]
            }
          }
        ]
      }
    ]
  }
}

最初の「にほん」は「日本橋」がヒットしているようです。返ってきたoptionsの数は4件しかなく、どうやらこれがすべてのようです（取得件数はデフォルト5件）。 2番目の「にっぽん」は「日本」という単語から始まるものがヒットしていますが、「日本橋」はなさそうでした。最後に「日本」という漢字を入力にした場合は2つの合計が帰ってきているようです（今回のレスポンス例にはありませんが、サイズを大きくすると「日本橋」が帰ってきていました）。

どうしてそうなるの？

JapaneseCompletionAnalyzerの基本的な動作としては、

Kuromojiが単語に区切る
区切られた単語ごとに読みを持っている
元の単語と読みをローマ字にしたものが最終的に出てくる

というような動きです。この時、単語には「1つ」の読みが対応しています。読みから単語を探そうとすると、読みの違い（ゆれ）を吸収することはできないためです。 JapaneseCompletionAanlyzerは3点目のローマ字のゆれに対応していますが、入力となる読みのゆれまでは対応できないです。対応しているといいかどうかというのも難しい判断になる気もします。。。

そのほかの例としては次のようなものもあります。これは、今回のオートコンプリートの話とは少しずれてるかもしれませんが、1番目の処理の結果が変わってくる例です。「南方熊楠」という名前の間にスペースがあるかないかで、出力される読みが変わってくる例です。

GET _analyze
{
  "text": ["南方 熊楠"],
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["kuromoji_readingform"]
}

GET _analyze
{
  "text": ["南方熊楠"],
  "tokenizer": "kuromoji_tokenizer",
  "filter": ["kuromoji_readingform"]
}

# GET _analyze
{
  "tokens": [
    {
      "token": "ナンポウ",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    },
    {
      "token": "クマグス",
      "start_offset": 3,
      "end_offset": 5,
      "type": "word",
      "position": 1
    }
  ]
}
# GET _analyze
{
  "tokens": [
    {
      "token": "ミナカタ",
      "start_offset": 0,
      "end_offset": 2,
      "type": "word",
      "position": 0
    },
    {
      "token": "クマグス",
      "start_offset": 2,
      "end_offset": 4,
      "type": "word",
      "position": 1
    }
  ]
}

人名や地名は1つの漢字に対して多くの読みが存在しているので大変です。。。どうしてこれは出てこないんだろう？と不思議に思った場合は、_analyze APIを使ってどういう動きなのかを見てみるのがいいかと。

まとめ

ということで、少しだけですが、こんなことができるよ、できないよというのを書いてみました。挙動をしっていれば、なんでこうなってるんだっけ？といったことを調べる役に立つかと思います。入力された文字をもとにどれをサジェストするかなどについてはもう少し違う動きなので、中の仕組みをそろそろ書かないとなぁ。

参考

同形異音語 - Wikipedia

日本語用オートコンプリートのためのAnalyzer

Tue, 09 Aug 2022 16:00:02 +0900

風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCENE-10102）。 Elasticsearchでも使えるかなぁ？ということで調べたところ（調べた？聞いた？）、どうやら8.1から利用できるようになっている（GitHub Issue #81858）みたいです（まだ、公式ドキュメントには記載がないのですが）。

8/17追記

作者の打田さんがブログ書いてたの見落としてた（もしくは見たけど忘れてた）ので貼っておきます。マルチテナンシー下での Query Auto Completion 設計・運用戦略 - LegalForce Engineering Blog

ということで、こんな感じで使えるよというのを試してみました。

どういうもの？

日本語入力方法を考慮したオートコンプリート用のトークンを生成してくれるTokenFilterと、それをLuceneのSuggesterで動くようにしたAnalyzerが用意されています。 Elasticsearchでは、Kuromojiプラグインにそれらを使えるようになっています（バージョン8.1.0以降）。 KuromojiTokenizerと一緒に利用する前提の仕組みとなります。

オートコンプリートとは？

検索窓などでキー入力をしていると、入力した文字で始まる単語の一覧が現れることがあると思います。あの機能がオートコンプリートと呼ばれるものです。search-as-you-typeとも呼ばれることもあります。（検索ペンギン本にも書いてあるので興味のある方はぜひ！（ステマ））入力された文字列を含むパターンもありますが、今回紹介するものは入力された文字で始まる単語を見つけてくる機能になります。

何がなんで追加されたの？

日本語の入力方法は、かな入力の人もいればローマ字入力の人もいます。ですので、オートコンプリートでの入力として、「しゃ」という入力が来る場合もあれば、「sha」というローマ字入力途中のものが来る場合もあります。これらを考慮したトークンの扱いができるように、 JapaneseCompletionFilterというクラスが追加されています。内部的にはKuromojiTokenizerでトークンに分割された後に、もともとのトークンと同じポジションで読みをローマ字にしたものを出力します。 JapaneseCompletionAnalyzerは上記Filterをすぐに使えるようにしたAnalyzerです。

動かし方

百聞は一見に如かずということで、Elasticsearchでの使い方を見たほうが分かりやすいので、簡単に動かしてみることにします。

インストールとインデックスの用意

Elasticsearch（8.1以上）とKuromojiのプラグインをインストールします（今回試したのは8.3.1）。

サンプルデータ

なにかいいデータはないものか？と思っていたところ夏休みだというのを思い出しました。夏休みといえば読書感想文だ、ということで、書籍のタイトルがいいかもなと。青空文庫の著者名と書籍のタイトルの一覧を見つけたのでそちらのデータを使って試してみました。

CSV to JSON

CSVファイルは最後の参考にある青空文庫のページから、「公開中　作家別作品一覧：全て(CSV形式、zip圧縮）」をダウンロードしたものを利用しました。 CSVファイルだったので、jqコマンドで必要な部分だけをNDJSONの形でとりあえずファイルに出力します。

cat list_person_all_utf8.csv | tr -d '"' | jq -c -R 'split(",") | {"auth_id": .[0] | tonumber, "author": .[1], "id": .[2] , "title": .[3], "suggest_ja": [.[3], .[1]]}'

次のようなJSONが1行ずつ出力されます。

{"auth_id":1257,"author":"アーヴィング ワシントン","id":"056078","title":"駅伝馬車","suggest_ja":["駅伝馬車","アーヴィング ワシントン"]}

suggest_jaがオートコンプリートの対象となるデータになります。今回は著作と著者にしてみました。あとは次に紹介するスキーマでインデックスを作成して、適当なプログラムを使ってBulkでElasticsearchに登録しましょう（私は個人作のツールで入れました）。

インデックス

オートコンプリート用のSuggesterを利用するための特殊なフィールド（completion）を利用したフィールドを用意します。ちなみに、今回はLUCENE-10102に記載があった設定をそのまま使わせていただきました。そのほかのフィールドは今回は特に必要はないのでおまけです。

PUT aozora_index
{
  "mappings": {
    "properties": {
      "suggest_ja": {
        "type": "completion",
        "analyzer": "japanese_completion_index",
        "search_analyzer": "japanese_completion_query",
        "preserve_separators": false,
        "preserve_position_increments": true,
        "max_input_length": 50
      },
      
      "auth_id": {
        "type": "long"
      },
      "author": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword",
            "ignore_above": 256
          }
        },
        "analyzer": "kuromoji"
      },
      "author_id": {
        "type": "integer"
      },
      "id": {
        "type": "integer"
      },
      "title": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword",
            "ignore_above": 256
          }
        },
        "analyzer": "kuromoji"
      }
    }
  },
  "settings": {
    "index": {
      "number_of_shards": "1",
      "analysis": {
        "analyzer": {
          "japanese_completion_index": {
            "mode": "index",
            "type": "kuromoji_completion"
          },
          "japanese_completion_query": {
            "mode": "query",
            "type": "kuromoji_completion"
          }
        }
      }
    }
  }
}

動作確認

ここまでで、インデックスとデータの用意ができました。オートコンプリートを実現するためにはElasticsearchのSuggesterという機能の、Completion Suggesterを利用します。検索の仕方が通常のものとは少し異なります。ちなみに、速度重視のためにインメモリで動いているとの記載がドキュメントにあります。

Completion Suggesterのクエリ

Suggester用のクエリがあるのでこちらを使います。例えば、「wagah」という入力がある時に、サジェストする内容を取得するには次のようなリクエストになります。

GET aozora_index/_search
{
  "suggest": {
    "title-suggest": {
      "prefix": "wagah",
      "completion": {
        "field": "suggest_ja"
      }
    }
  },
  "_source": ["title", "author"]
}

最初の「suggest」がsuggest用のパラメータを意味しています。
次の「title-suggest」は好きな名前をつけられます。レスポンスにこの名前がついた配列がサジェストの結果になります（同時に3. 複数suggestを呼び出せるので、対応した結果が分かるように名前が付けられます）。
「prefix」に入力の文字列を渡します。
「completion」がsuggesterのタイプの指定です。今回はCompletion Suggesterなので「completion」を指定します。その中に「field」でcompletionに利用するフィールド名を指定します。先ほどのスキーマでcompletionタイプを指定したフィールドです。今回は「suggest_ja」になります。
「_source」は結果を見やすくするために、ヒットしたデータの一部だけ取得するオプションです。

すると、次のような結果が返ってきます。

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "wagah",
        "offset": 0,
        "length": 5,
        "options": [
          {
            "text": "『吾輩は猫である』中篇自序",
            "_index": "aozora_index",
            "_id": "002671",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "『吾輩は猫である』中篇自序",
                "夏目 漱石"
              ]
            }
          },
          {
            "text": "わが俳諧修業",
            "_index": "aozora_index",
            "_id": "003771",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "わが俳諧修業",
                "芥川 竜之介"
              ]
            }
          },
          {
            "text": "わが母をおもう",
            "_index": "aozora_index",
            "_id": "003997",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "わが母をおもう",
                "宮本 百合子"
              ]
            }
          },
          {
            "text": "わが母を語る",
            "_index": "aozora_index",
            "_id": "049723",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "わが母を語る",
                "上村 松園"
              ]
            }
          },
          {
            "text": "吾輩は猫である",
            "_index": "aozora_index",
            "_id": "000789",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "吾輩は猫である",
                "夏目 漱石"
              ]
            }
          }
        ]
      }
    ]
  }
}

「suggest」の「title-suggest」がCompletion Suggesterのレスポンスになります。
最初の「text」は入力の「prefix」の値です。「offset」、「length」もこの文字に関する情報なので特に気にしなくてもいいかと。
「options」がサジェストされた内容になります。それぞれの「text」がサジェストされた文字列になります。「suggest_ja」には著作と著者名を入れましたが、今回は著作が「text」に帰ってきていることがわかります。

次に著者名でもやってみましょう。「太宰」という入力が来たものとしてリクエストを投げます。

GET aozora_index/_search
{
  "explain": true, 
  "suggest": {
    "title-suggest": {
      "prefix": "太宰",
      "completion": {
        "field": "suggest_ja"
      }
    }
  }
}

レスポンスは次のようになります。

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "太宰",
        "offset": 0,
        "length": 2,
        "options": [
          {
            "text": "太宰 治",
            "_index": "aozora_index",
            "_id": "000236",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "ア、秋",
                "太宰 治"
              ]
            }
          },
          {
            "text": "太宰 治",
            "_index": "aozora_index",
            "_id": "001572",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "I can speak",
                "太宰 治"
              ]
            }
          },
          {
            "text": "太宰 治",
            "_index": "aozora_index",
            "_id": "001578",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "愛と美について",
                "太宰 治"
              ]
            }
          },
          {
            "text": "太宰 治",
            "_index": "aozora_index",
            "_id": "046597",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "青森",
                "太宰 治"
              ]
            }
          },
          {
            "text": "太宰 治",
            "_index": "aozora_index",
            "_id": "004357",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "青森",
                "太宰 治"
              ]
            }
          }
        ]
      }
    ]
  }
}

先ほどとは異なり、「options」の中の個々の「text」はすべて「太宰治」になってしまいました。登録したデータは著作の一覧ですが、「suggest_ja」には著作と著者名を入れたためです。これでは、実際に検索窓に実装したときに同じものが並んでしまいます。こんな時のためのオプション「skip_duplicates」が用意されています。先ほどのリクエストに「“skip_duplicates”: true」を追加します。

GET aozora_index/_search
{
  "explain": true, 
  "suggest": {
    "title-suggest": {
      "prefix": "太宰",
      "completion": {
        "field": "suggest_ja",
        "skip_duplicates": true
      }
    }
  },
  "_source": ["suggest_ja"]
}

するとレスポンスは次のように変化します。

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  },
  "suggest": {
    "title-suggest": [
      {
        "text": "太宰",
        "offset": 0,
        "length": 2,
        "options": [
          {
            "text": "太宰 治",
            "_index": "aozora_index",
            "_id": "000236",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "ア、秋",
                "太宰 治"
              ]
            }
          },
          {
            "text": "太宰治との一日",
            "_index": "aozora_index",
            "_id": "042582",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "太宰治との一日",
                "豊島 与志雄"
              ]
            }
          },
          {
            "text": "太宰治情死考",
            "_index": "aozora_index",
            "_id": "043137",
            "_score": 1,
            "_source": {
              "suggest_ja": [
                "太宰治情死考",
                "坂口 安吾"
              ]
            }
          }
        ]
      }
    ]
  }
}

「options」は3つに減り、重複していないことがわかります。「text」が同じ場合は最初に出てきたものを返すようです（注意：結果から観測しているだけで、実装はまだ見ていません）。（なお、今回は説明を省きますが、入力データでスコアを指定することも可能になっています）。そのほかにもCompletion Suggesterにはいくつか仕組みが用意されているのですが、それはまた今度にでも。

まとめ

ということで、Luceneコミッターの打田さんに感謝です。便利な仕組みが簡単に使えるようになるのはとてもありがたいですね。

まずは簡単にどういうものかとどうやって使うのかを記事にしてみました。中の動きや、注意点、これまでとの違いなどは次の記事にしようと思います。そういえば、公式ドキュメントにはまだ出てきてないな、それを書こうと思ってついでに動かしてみたんだけど、追加するのはまた後日かな。。。

参考資料

Hugoをアップデートした

Fri, 05 Aug 2022 17:59:14 +0900

Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。

なんでアップデート？

うっかり魔がさして、メインのWSL2のUbuntuを20.04から22.04にアップグレードしました。。。新規に22.04を落としてきて移行ではなく。皆さんはまねしないほうがいいですよ！アップデートした後にGitの環境がおかしくなったりと大変でした。 WSL2のUbuntuではHugoでブログのビルド、いろんな確認のためのElasticsearchの起動、個人的なプログラムとかを書く環境として利用しています。

で、Ubuntuを上げたところ無事（？）Hugoもアップデートされたわけです。最初はGitでfetchが出来なくなって修正していましたが、そのほかの動作確認を行なう段階でHugoでブログがビルドできなくなっていることが判明しました。

バージョンアップに伴う修正

hugoコマンドを実行すると、いくつかのERRORとWARNが出力されました。次のようなものです。

hugo v0.92.2+extended linux/amd64 BuildDate=2022-02-23T16:47:50Z VendorInfo=ubuntu:0.92.2-1
ERROR 2022/08/05 13:22:32 Page.URL is deprecated and will be removed in Hugo 0.93.0. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url
WARN 2022/08/05 13:22:32 The "tweet" shortcode will soon require two named parameters: user and id. See "/home/johtani/blog_generator/content/post/2020/2020-12-04-build_corne_choc.md:46:1"
...
ERROR 2022/08/05 13:22:33 Failed to get JSON resource "https://publish.twitter.com/oembed?dnt=fa...
If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config:
ignoreErrors = ["error-remote-getjson"]
ERROR 2022/08/05 18:44:11 Page.UniqueID is deprecated and will be removed in Hugo 0.93.0. Use .File.UniqueID
ERROR 2022/08/05 18:44:11 Page.Dir is deprecated and will be removed in Hugo 0.93.0. Use .File.Dir

Page.URLなどがdeprecatedに

最初と最後2行のERRORがこちらになります。どうやら、Pageオブジェクトの変数に変更があったようです（まだdeprecatedであり、存在はしていそう？）。レイアウト（テンプレート）ファイルで「Previous Post」や「Next Post」といったリンクを作ったり、 Algoliaに登録するためのJSONファイルを生成するところでURL文字列を取得するために参照していました。

ログ出力でどのように変更すればよいのか？という記載があるので便利ですね。ただ、どのファイルにこの記述があるのかはログに出てなかったので少しだけ苦労しました。

実際には「UniqueID」という文字列でディレクトリ内を検索してあたりを付けた感じです。利用させていただいているテーマ（Clean White）がすでにアップデートに対応されていたのでそちらが参考になりました。

いくつか、テーマをもとに修正したテンプレートがlayoutsディレクトリにあったので、それらを修正した形です（参考のリンクはテーマのファイルになります）。

.URLを.Permalinkに変更（参考：single.html）
.UniqueIDを.File.UniqueIDに変更（参考：list.algolia.json）

tweetのshortcodeの引数が増えた

これまでは以下のようにIDだけで良かったのですが、userとidという2つの引数が必須になるという変更が入ったようです。

変更前：

{{ <tweet 1449214872143609860> }}

変更後：

{{ <tweet user="johtani" id="1449214872143609860"> }}

WARNにはファイル名、行番号が出力されていたので、1つずつ修正していきました。結構な量があったので、地味に大変でした、公開しているブログを見ながら、該当するツイートを見つけてはuserを指定していく部分が特に。自分のツイート以外もブログに貼っていたので画一的には対処できなくて。。。

なにかプログラムで機械的に対応ができたかもなぁ。

鍵付きツイートによるエラー

tweetのshortcode対応を行なった後でもビルドがエラーになっており、次のようなエラーが消えないままでした（エラーの一部は省略しています）。（幸いにも）1つのツイートだけ、ブログ記事を書いた後で鍵付きになってしまった方のツイートがあったようで、ツイート用のJSONが取得できなくてエラーになっていました。

ERROR 2022/08/05 13:22:33 Failed to get JSON resource "https://publish.twitter.com/oembed?dnt=fa...
If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config:
ignoreErrors = ["error-remote-getjson"]

こちらもログに対処方法が出ています。 config.tomlにignoreErrors = ["error-remote-getjson"]を追加すれば、エラーが出力されなくなりビルドも成功するようになります。ただ、tweet以外でもエラーが出る可能性がありそうで、その場合に、ブログに書いたつもりが一部が出力されないまま公開されそうな気がします。なので、今回はconfig.tomlに該当の設定を追加するのではなく、ブログ記事から該当のツイートを消す対応をしました。幸いにも、ツイートを消してもブログ記事自体には影響がありませんでした。

.hugo_build.lockファイルが生成される

これは、エラーではないのですがgit addしようとした際に、ファイルが増えていたのでどういったファイルなのかを調べました。 0.89.0から追加されたロックファイルのようです（参考：0.89.0のリリースノート）。こちらは特に保管する必要もなさそうなので.gitignoreに追加して対処しました。

まとめ

ということで、気軽にUbuntuをアップグレードしないほうがいいですね。。。期せずしてHugoのアップグレードができたのは良かったかもなｗ

参考

【WSL2】Ubuntu 20.04.4 LTS を 22.04 LTS へアップグレードした

Querqyの調査（その2：アーキテクチャ）

Wed, 20 Jul 2022 16:04:10 +0900

今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElasticsearchでも使えるという形なので、どんなつくりになっているのかな？と思ったのが発端です。

GitHubのリポジトリ

GitHubにリポジトリが公開されています。 2つのリポジトリに分かれています。

どちらもJavaのライブラリで、ビルドシステムとしてはMavenを利用しています。コアのライブラリのリポジトリにはさらに、以下の2つが存在しています。

lucene向けライブラリ（Solr向けのモジュールもこちらに含まれる）
コアライブラリ

pom.xmlを読んだところ、次のような依存関係になっています（それ以外にも使ってるライブラリはあるけど）。

Esプラグイン -> Lucene向けライブラリ -> コアライブラリ

Esプラグイン

Es向けのエンドポイントの実装、Esのクエリの組み立てを行なっています。 Rewriterの実装については、Lucene向けライブラリ、コアライブラリを利用する形になります。

querqy用のQueryBuilderを実装しており、EsがクエリをパースするタイミングでRewriterなどを呼び出してクエリの書き換えを行う仕組みです。なお、Es向けのクエリの組み立てと書きましたが、ほとんどLuceneのクエリの組み立てになっています（そりゃそうだ）。実際にquerqyのクエリ組み立て処理を行っているのは、Lucene向けライブラリのQueryParsingControllerになります。いくつかのRewriterは、生のEsクエリをルールなどとして登録することができるようになっています。これらのクエリのパースをEs側にやらせる処理の部分もこちらで定義されている感じです。

そのほかに、ドキュメントには記載がないエンドポイントが2つ用意されていました。インデックスに登録してあるRewriterの設定を各ノードでキャッシュする仕組みがあって、そのキャッシュの操作（クリア、リロード）用みたいです。これらは、Rewriterの追加、削除のアクションの内部で呼び出されているので、ユーザー側で呼び出す必要はなさそうです。

Lucene向けライブラリ

Luceneに関連する処理がまとめられています。 Es内部ではLuceneを使って検索処理が行なわれるため、Luceneのクエリを組み立てる必要があります。 querqyとしてLuceneのクエリを組み立てるときに必要なクラスがこのライブラリに含まれています。

また、Word Break Rewriterの実装はコアライブラリではなくこちらのライブラリに実装されています。これは、Luceneのタームディクショナリを活用したRewriterになっているため、Lucene必須となっているからのようです。（まだちゃんと実装を見ていないので、どんな活用の仕方をしているのかまではわかっていませんが。。。）

コアライブラリ

Rewriterの設定のパース処理、クエリのリライト処理の実装がまとめられています。 querqyのクエリが、Rewriterの処理に基づいて、querqyとして定義されたクエリのモデルに一旦変換される作りになっています。 Lucene向けライブラリやEs向けプラグインはこの内部のクエリモデルになったものをもとに、Lucene向けのクエリに書き換えていくというながれになっています。

まとめ

ざっくりですが、どんな構成なのかを見てみました。 Esのプラグインとなっているのですが、プラグインではなく、外部に出すことってできるのかな？と思いつつ、なんとなくソースを読んでみました。パターンとしては、Lucene向けのクエリからEs向けのクエリを組み立てるとかの無駄な努力が必要になる気もするけど。。。 Luceneを使っていない検索エンジンに対しては、コアライブラリをもとに、それぞれの検索エンジンむけのクエリを組み立てる仕組みを作る形になると思います。その際、Rewriterの設定を保持する仕組み、querqyが置き換えたクエリのマッピングができるか？といった点を考える必要がありそうです。デバッグとかするときに、EsのクエリDSLのJSONとして見れるといいなぁと思ってたけど、そんなことできるかなぁ？

Querqyの調査（その１）

Wed, 20 Jul 2022 11:52:43 +0900

Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じです。対応しているのはSolrとElasticsearch（以降、Es）になります。手元にはEsの環境があるのでそちらで試してみました。

なにもの？

EsやSolrのプラグインで、ルールやパラメータを利用して、クエリの書き換えをEsやSolr側で行えるプラグインです。なお、本記事ではEsのプラグインを説明します。今回はドキュメントを読みながらメモを取った感じなので、詳細については公式ドキュメントを見ていただくのが良いかと。手元では動作させてみましたが、今回の記事ではざっとメモを取っただけになります。

インストール

Esのpluginコマンドでインストール可能ですが、Mavenにアップロードされているバージョンは限定的なので、必要に応じて自分でビルドする必要があります。対応しているかは、公式ドキュメントのInstallationのプルダウンが参考になります。

どうやって使うの？

Query DSLにquerqyというクエリが追加されるので、あとはドキュメントをもとにクエリを組み立てるクエリを書いていきます。すると、プラグインが指定されたルールに従い、EsのQueryに書き換え、実際の検索が実行して結果が返ってきます。普通にmatchなどの既存のQueryと同レベルのものになるので、既存のEsのクエリと組み合わせた使い方もできるようです。

サンプルとして紹介されている短めのクエリ（このクエリではルールによるクエリの書き換えはない）。

GET ecommerce/_search
{
   "query": {
       "querqy": {
           "matching_query": {
               "query": "notebook"
           },
           "query_fields": [ "title^3.0", "brand^2.1", "short_description"]
       }
   }
}

また、書き換え（Rewriter）の設定をElasticsearchに対して保存できるエンドポイント_querqy/rewriterが用意されています。

Synonymの書き換えを行なうサンプル（後述するCommon Rules Rewriterの設定）。

PUT  /_querqy/rewriter/common_rules
{
    "class": "querqy.elasticsearch.rewriter.SimpleCommonRulesRewriterFactory",
    "config": {
        "rules" : "notebook =>\nSYNONYM: laptop"
    }
}

どんな書き換えができるの？

用意されているRewriterは2022年7月時点では次のようなものになります（がんばれば、Javaで実装すれば自作もできそう）。

Common Rules Rewriter
Replace Rewriter
Number Unit Rewriter
Word Break Rewriter

また、複数のRewriterをチェインして使うこともできる。記述した順番で適用されます。それぞれのRewriterについて簡単にメモを。

Common Rules Rewriter

シノニム、結果のブースト、フィルター、結果に対して追加情報を付与したりできます。

rulesにルールを記載していきます。以下のようなフォーマットになっています。クエリが入力に合致したら、ルールが適用される形です。プロパティは後述しますが、ルールの適用する順序などをハンドリングするために使用します。

入力 => 
  ルール
  ルール
  @プロパティ
  @プロパティ

入力部分に関する書式

ルールの左辺に該当する部分で、クエリに入力された文字列がマッチするかどうかで、右辺のルールを適用するかがきまります。

入力の一致の条件は次のような感じです。
- 完全一致、前方一致、後方一致の使い分けが可能。ダブルクォート"で制御
- デフォルトでは、大文字小文字の区別なし（後述するオプションで変更可能）
- 単語の末尾にワイルドカード*で1文字以上にマッチ。入力の最後にだけ利用可能

書き換えの命令（ルール）

右辺に利用できる命令で、次のようなものがあります。

SYNONYM

同義語展開するための命令です。Synonym Token Filterとの違いは、複数のルールを同時に適用できます。フィールドに依存しない設定なのでメンテナンスが楽になるとのこと。ただし、双方向の設定はないため、例えば"personal computer"と"pc"の場合、2つの設定を個別に定義する必要があります。また、ステミングなどには未対応なので、“personal computers"も対応する場合はこれも追加する必要があります。類義語ごとに重みを変えることが可能になっています。同列ではなく、同義語のスコアを下げるなどで、リコールを増加させつつ、入力語のスコアを上位にすると行ったことが可能です。

UP/DOWN

入力文字列がマッチした場合に、追加のクエリを正か負のブーストをしつつ追加できます。例えば、「iphone」と検索された場合に、「apple」もクエリとして追加しつつスコアをブーストし、「case」のクエリをスコアを下げるように追加できます。これにより、アクセサリーではなく本体が検索結果の上位に出てくるような仕組みを提供できます。

FILTER

UP/DOWNではクエリとして追加されていたが、こちらはフィルターとして追加されます（＝スコアで調整ではなく、結果から除外される）。

DELETE

クエリからキーワードを削除できます。単語自体をそのまま削除することも、入力された単語に合わせて他の単語を削除することもできます。

DECORATE

2022年7月時点でEsでは利用不可で、Solrのみで利用可能です（なので読み飛ばしました）。

プロパティ

各ルールの設定にタグをつけられるような機能です。このプロパティを利用して、ルールのソートやフィルタリングなどが可能になります。複数のルールにクエリがマッチした場合に、優先度が最高のものだけを適用したり、プロパティに特定の値を持っているものだけを採用したりできます。なお、プロパティは命令のあとに記述する必要があります（パーサーの関係かな？）。

Replace Rewriter

クエリタームの置き換え用のRewriterです。クエリの正規化処理として、他のRewriterの前処理に利用したりできます。サンプルではタイポの修正などに利用したり、不要な語の除去などがあげてありました。

Word Break Rewriter

クエリトークンを分解・結合します。たとえばドイツ語は、複合語と呼ばれる個別の意味の単語を結合した1つの単語を持っているため、個別の意味に分解して検索すると便利なことがあります。そういった単語を辞書を基にして分割できるようにする機能です。辞書とは実際のインデックスのタームディクショナリのことと思われます（要調査。どのインデックスのフィールドを指し示すのかなど、設定とドキュメントではよくわからない）。なお、利用可能な形態素解析を基にした実装はドイツ語のみとなっており、また、分解の時には形態素解析を考慮しますが結合時には考慮しません。

Number-Unit Rewriter

クエリの数値と単位を判別し、対象となるフィールドにマッチさせます。範囲での一致や完全一致やブーストが可能です。単位をもとにして、特定のフィールドに対する数値のクエリに書き換えることができます。

Shingle Rewriter

Solrのみで利用可能なので読み飛ばしました。

ルールはどこに保存されるの？

.querqyというインデックスが内部で作成され、そこに保存されます（公式ドキュメントより）。（ちなみに、Mappingはこんな感じみたいです）。現状、プラグインでは設定したRewriterの取得ができないようなので、自分で登録した設定がどんなものかは、このインデックスを検索する必要がありそうです。

気になった点・改善点？

気になった点があったので。

Rewriterのエンドポイントは、登録・更新・削除のみ対応しており、登録したものの確認は直接インデックスを見に行くしかなさそうです（Issueは作られてた）。
[要検証]書き換えられたクエリがどんなものか？は残念ながら確認できなそうで、_validate/queryで最終的なLuceneレベルのクエリで確認するしかなさそう？
スキーマ側で定義したものと、Querqyで定義したものの兼ね合いがどういう形になるのか？などを気にする必要があるのが注意点かも。組み合わせたときの副作用などがどんなことになりそうか？が予測がつきにくそう。
Rewriterの定義自体のテストはどうしたものか？

まとめ

とりあえず、ざっとドキュメントを見ながらメモを取った感じです。設定などの記述が独自のものなので、そこに慣れていく必要がありそうです（特にルールの改行の部分とか）。次は実際にどんな感じで使えそうか、既存の仕組みとの違いは？みたいなところをもう少し見ていきたいとおもいます。

参考文献

今年もオンラインでBerlin Buzzwordsに参加した

Wed, 15 Jun 2022 18:00:15 +0900

今年もBerlin Buzzwordsにオンライン出張してました。今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。ブースもあったみたいです。ちなみに、現地で参加する人はマスク必須のようでした（Health & Safetyというページが用意されていました）。昨年オンラインだったMICESは現地のみでの開催みたいで見ることはできなかったです（録画公開されないかなぁ）。

さて、いくつか見たセッションで面白かったものがあったので簡単にメモを。すでにセッションのビデオがYouTubeで公開されているので、興味のある方は見てみてください。

面白かったセッション

The future of Lucene’s MMapDirectory: Why use it and what’s coming with Java 19 and later?

毎年恒例になってる気も？前半は昨年も話をした内容で、後半はJava 19がリリースされたら、Previewという形でフラグを立てて使えるようになるようです。使えるようにするから、テストしてみて！という感じで終わっていますｗ

Scaling an online search engine to thousands of physical stores

セッションページ：Scaling an online search engine to thousands of physical stores ： Berlin Buzzwords 2022 ： pretalx
動画：Aline Paponaud – Scaling an online search engine to thousands of physical stores - YouTube

数千の実店舗の商品をオンラインで検索できるようにしつつ、オンラインのマーケットプレイスのような検索も一緒にできるようにしたというお話でした。インデックスの構成をどう工夫したのか？とかどういうクラスター構成にして、どんなことをモニタリングしてるよ？というお話です。実際の店舗がどんなものかなどは出てこなかったので、少しイメージは沸きにくかったのですが、どんなことを考えながらインデックスの構成とか考慮したよという話はおもしろかったです。実際に検索したときに、実店舗のデータがどんな感じで結果として表示されたりするのか？といった点はわからなかったので、そのあたりの話をもうちょっと聞いてみたかったなぁ。

Offline Ranking Validation - Predicting A/B Test Results

セッションページ：Offline Ranking Validation - Predicting A/B Test Results ： Berlin Buzzwords 2022 ： pretalx
動画：Andrea Schütt & Yunus Lutz – Offline Ranking Validation - Predicting A/B Test Results - YouTube

otto.deというECサイトでのランキングをどうやって改善していくか？という話。現在はマニュアルなチューニングをコンテキストごとにやっているけど、リクエスト量とかデータとかが増えてきてて、このままマニュアルで改善していくのも大変なので、モデルベースのランキングを開発できないか？というのをはじめていますよと。そのために、これまでのデータから、A/Bテストの結果を予測できるモデルが作れないか？というのをやっていますという話。いくつかわからない単語も出てきたので、誰か詳しい人教えて！

AI-powered Semantic Search; A story of broken promises?

セッションページ：AI-powered Semantic Search; A story of broken promises? ： Berlin Buzzwords 2022 ： pretalx
動画：Jo Kristian Bergum – AI-powered Semantic Search; A story of broken promises? - YouTube

Vespaの開発にかかわってる方の、Semantic Searchに関する話。 Semantic Searchが流行り始めていて、どうやればできるのか？という話が出てきています。けど、どういうものでどういう点に気を付けたほうがいい？という話でした。 LtRってこんなもの、そのあとに出てきたLLM（Large Language Model）でどうやって検索の改善に使えるの？というのが分かりやすく説明されていました。それらの説明の後、BEIRという論文を紹介しつつ、LLMを使うときの注意点の話がありました。

BERTとかをちょっと勉強してたのもあり、なんとなくそうだよなぁと思っていた結論と同じ結論が出てきたので面白いと感じました。 BEIRの論文は時間を見つけて読んでみないとな。

Hybrid search > sum of its parts?

セッションページ： Hybrid search > sum of its parts? ： Berlin Buzzwords 2022 ： pretalx
動画：Lester Solbakken – Hybrid search： Greater than the sum of its parts? - YouTube

こちらもVespaの人の話。先ほどのSemantic Searchの話では、Semantic Searchがどんなものか？という話でした。が、それだけで検索ができるわけでもないので、キーワードサーチとSemantic Searchの両方をうまく活用するには？というのがこのセッションでした。最終的にはVespaを使うとうまくハイブリッドできるよという話ですが、考え方は参考になるかなと。 Vespaも触ってみたいなぁ。

The life of a search engine administrator

セッションページ：The life of a search engine administrator ： Berlin Buzzwords 2022 ： pretalx
動画：Lucian Precup & Vincent Bréhin – The life of a search engine administrator - YouTube

検索システムの管理者ってどんなことやるの？それにはどんなことができるツールがあるといいの？という話です。まぁ、ツールについてはこの会社の人たちのツールの宣伝なのですが、検索システムを作って育てていくのにどんなことを考えたりするのか？という参考になるかなぁと。

Should we stop using distance in our location-based data recommendation models?

TravelTimeという会社を立ち上げた人の話。位置に関する情報って重要だし、検索するときに利用しますよね？例えば、ホテル決めたりとか、仕事探したりするときに。ということで、位置情報を検索エンジンで利用する方法（Bounding Box、ポリゴン、距離）をまず紹介して、どんなユースケースで使えるかという話があります。また、それとは別に検索速度（いかに検索を速く返すか）も重要だという話があります（ウォルマートはページロード時間を1秒早くしてコンバージョンが2%あがったとか）。で、実際に検索結果に距離とかでるけど、実際に知りたいのはどのくらいの時間で行けるのか？という話だったりしませんか？と。公共交通機関を使ったりする場合に、実際に45分で移動できる距離というのは半径5マイルとかできまるものではないのに、単純に位置情報を利用した距離だけでソートしていいの？という問いかけから、その辺を考慮した検索ができるAPIを開発しているよ、検索速度もはやいよというお話でした。残念ながら具体的にどうやって作っているのか？というのはなかったですが、観点がおもしろかったです。

Word2Vec model to generate synonyms on the fly in Apache Lucene

セッションページ：Word2Vec model to generate synonyms on the fly in Apache Lucene ： Berlin Buzzwords 2022 ： pretalx
動画：Daniele Antuzi & Ilaria Petreti – Word2Vec model to generate synonyms on the fly in Apache Lucene - YouTube

Word2Vecのモデルを使った、Apache LuceneのSynonym Filterを開発中だよという話 DeepLearning4Jを使ってみたが、遅くて使えなかったんだけど、最近Luceneに入ったkNNを使うことでそれなりの速度で使えそうなものができるかもよ？って感じでした。モデル学習用のツールも作ってて、イタリア語のWikipediaで学習したものでちょっと動かしたらそれっぽい感じになってるという話でした。まだ途中でいくつかやりたいことがあるという話で、実用はまだ先のようでした。例えば、1単語のSynonymにしか対応してないとか、モデルをインメモリでしか動かせないとか。

QAでも出たのですが、Word2Vecだと対義語も類似していると判定されてしまうと思うので、その辺がどうなっているのかなぁ？という疑問があります。ルールベースの類義語ではないので、調整するのはどうやるのかなぁ、学習用のコーパスをいい感じにするとかなのかな？とか、気になるところです。

NrtSearch: Yelp’s fast, scalable, and cost-effective open source search engine

YelpがLuceneベースで開発をしているNrtSearchというOSSの話です。 Elasticsearchを使っていたんだけど、どういった点が問題点になってどういうモチベーションでNrtSearchを開発したのか？を説明しています。アーキテクチャがどんなもので、実際に動かしてみてどんな利点があって、どんな点が問題として出てきているか、将来どんなことをやろうとしているかがわかります。 QAでもいろんな質問が出ていて面白いです。

まとめ

ということで、簡単でしたがセッションの感想でした。 Neural/Semantic Searchというのがセッションのタイトルなどに入っているのが多くなってるなぁという感想です（ちょっとやってみたい気はしてるんだよなぁ）。すでにYouTubeに動画が公開されているので興味があるセッションを見つけてみてください。 Berlin Buzzwordsの次の日に開催されたMICESも観てみたかったですが、オンラインでも参加できる形式で海外のカンファレンスが開催されるのはとても助かりますね（ヨーロッパだと時差もそれほど大変じゃないし）。けど、落ち着いたらまたオフラインで参加してみたいなぁ。

Elasticsearchの新しいJavaクライアント

Mon, 13 Jun 2022 20:24:06 +0900

7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。使ってみたので、ちょっとだけ紹介でもしてみようかな。

このクライアントが出るまでは、ElasticsearchのJavaクライアント（REST版）はElasticsearch本体の一部として実装・管理されていました（Elasticsearchのリポジトリにあるclientディレクトリ）。

HTTP経由でElasticsearchにアクセスするクライアントだったのですが、Elasticsearch本体のリポジトリで管理されていることもあり、Elasticsearch本体で利用されているクラスを使用していました。このため、クライアントライブラリなのですが、Elasticsearch本体のJarが必要になりサイズが大きくなっていました。また、JavaのObjectへの詰め替えなどの機能も備えておらず、すこし古臭い感じでもあります。この辺りを刷新する目的もあり新しいクライアントが公開されたようです。 3月くらいに触った時はまだ、ドキュメントが揃ってなかったのですが利用方法などが増えているので移行も楽になってきているようです。根本的に作り直されたため、これまでのREST Clientとは使い方が違います。ですので、jarだけの差し替えでこれまで動いていたプログラムを移行ができるわけではないので注意が必要です。

どの辺が便利？

順次移行が可能

これまでのRESTクライアントとはパッケージ名もjarも別モノになっています。ですので、少しずつ新しいJava Clientに切り替えていくことが可能になっています。根本的に使い方が変わっているので、大きなシステムのクライアントを全部切り替えるのは結構大変かと思います。ですので、Indexをしている部分だけとか、検索部分だけなどといった部分的な置き換えをしつつ新しいクライアントに慣れていくことができます。

ラムダっぽく書ける

検索のクエリのサンプルを見るとわかりますが、こんな感じでクエリが書けます(公式ドキュメントより抜粋)。

SearchResponse<Product> response = esClient.search(s -> s
    .index("products") 
    .query(q -> q      
        .match(t -> t   
            .field("name")  
            .query(searchText)
        )
    ),
    Product.class      
);

また、最後で渡しているProduct.classは、検索結果をどのクラスのインスタンスにして返すかの指定です。 Elasticsearchのレスポンス（JSON）から値をコピーして返してくれるようになっています。ですので、値を入れ替える処理を書く必要がなくなっています。

JSON文字列をそのまま使える

触り始めてからリリース（7.17.2より後なら使える）された、JSON文字列からリクエストを作る機能もあります。

これまでのREST Clientだと、Elasticsearchへのリクエストを必ずJavaのメソッドで構築する必要がありました。今回のこの機能を利用すると、JSON文字列（やファイル）からリクエストオブジェクトを作るためのメソッド.withJson()が提供されています。例えば、スキーマや設定変更用のリクエストのJSONなどは、Kibanaやcurlから試験的に投げたリクエスト（JSON）と同じものを使いたいことが多いです。また、ElasticsearchのAPIは数が多く、ドキュメントを見ながら利用方法を調べてJSONでまず試行錯誤することが多いです。このwithJsonメソッドを利用することで、動作確認などをしたJSONがそのままソースにも利用できるので、リクエスト変更時の確認なども容易になると思います。

使ってみて困ったのは？

便利な面も多いのですが、使っていて少し困ったこともあったのでそれもメモを残しておきます。

どんなリクエストを投げているかが不明

先ほども書きましたが、Elasticsearchのリクエストを試行錯誤するときは公式ドキュメントを見ながら、Kibanaなどを利用して試すことが多いです。ですので、自分がやりたいことのJSONは手元にあることが多いです。ただ、プログラムでクエリを組み立てる必要も出てきます。この時、実際にRESTリクエストとしてどんなJSONを投げているのかを知りたいことがあります（実際、検索クエリ作っててメソッドの使い方がうまくいかなくて四苦八苦してました）。 4月時点では簡単にリクエストで投げているJSONを文字列としてログに出すメソッドなどは用意されていないようでした。デバッグ用に次のようなメソッドを書いてみました。 Elasticsearchへ投げるRequestのクラス（例：CreateTemplateRequestとか）を引数に渡すことで、JSON文字列に変換できるようになっています（StringWriterに書き出されてる）。ここのLoggerはサンプルです。writer.toString()で取り出せる文字列がJSON文字列になっているので、ログに出してみるなり、ファイルに落とすなりしてデバッグのお供にしてください。


import java.io.StringWriter;
import co.elastic.clients.elasticsearch._types.RequestBase;
import co.elastic.clients.json.SimpleJsonpMapper;
import jakarta.json.stream.JsonGenerator;


...
    private void printRequestBodyJsonForDebug(RequestBase request) {

        //for debug
        Logger.log("** Debug print start **");
        StringWriter writer = new StringWriter();
        SimpleJsonpMapper mapper = new SimpleJsonpMapper();
        JsonGenerator generator = mapper.jsonProvider().createGenerator(writer);
        mapper.serialize(request, generator);
        generator.close();
        Logger.log(writer.toString());
        Logger.log("** Debug print finish **");
    }

プラグインなどで提供されるクエリが書けない

LtRプラグインなどは、Elasticsearchの検索クエリを拡張しています。残念ながら、現時点（2022/06/13）ではカスタムクエリを新しいJavaクライアントで利用しようとした場合、エラーが発生してしまいます（知らないJSONだと判断されてしまいます）。

GitHubのIssueとして「［roadmap］ Add support for plugin-defined custom components · Issue #252 · elastic/elasticsearch-java」があります。これに対応されたら、拡張されたクエリも利用できるようになるでしょう。プラグインなどで拡張されているものを使いたい場合は、残念ながら既存のRESTクライアントを当面は使うことになりそうです。

まとめ

新しいElasticsearchのJavaクライアントを簡単ですが触ってみて、気になった点を記事にしました。 JavaのObjectに詰め替えてくれる機能など便利になっているので使ってみてください。ドキュメントもちょっとずつ増えているようで、使い方も分かりやすくなっていました（触った時はレスポンスの扱い方などがJavaDocしか用意されてなかったんです）。説明が欲しいなぁと思うことがあれば、GitHubにIssueを上げてみるといいかもです。

参考

インデックスエイリアス - Azure Cognitive Searchの新機能

Wed, 18 May 2022 15:54:17 +0900

Azure Cognitive Searchで2月に新しい機能が公開されました。「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階ですが、ドキュメントなどが公開されていたのでどんな機能かを調べてみました。なお、本ブログの内容は2022/05/18時点での内容となります、ご注意ください。

公式ドキュメント

まずは公式ドキュメントです。1つ目の「インデックスの別名を作成する」の冒頭で別名（エイリアス）がどんなものかを説明しています。

REST APIのドキュメント（2022/05/18現在、日本語のページだと左のメニューが壊れているため、どんなAPIがあるかがわかりにくいため、Alias Operationsのページは英語のリンクになっています）

インデックスエイリアスってどんなもの？

文字通り、インデックスにエイリアス（別名）をつけることができるようになります。 Azure Cognitive Searchでは残念ながらインデックスを作成するタイミング以外ではインデックスの名前を変更できません。このため、インデックスのスキーマ（Analyzerの設定変更など）を変更したい場合、新しいインデックスを作成します。新しいインデックスの名前はこれまでのものとは別の名前になってしまうため、アプリケーションで指定しているインデックス名も書き換える必要が出てきます。利用しているアプリが複数ある場合は、すべて変更が必要です。

今回出てきたエイリアスを利用することで、アプリケーションではエイリアスを指定することで、アプリケーション側の変更なくインデックスを入れ替えることができるようになります。

エイリアスの操作方法

公式ドキュメントにAPIの一覧や利用方法の記載があるので詳細はそちらをご覧ください。本ブログでは、いくつか利用するときに気になった点を書き残しておきます。

作成

aliasesというエンドポイントにエイリアスの名前とインデックス名をPOSTすることで作成できます。以下のサンプルは公式ドキュメントの例です。

POST /aliases?api-version=2021-04-30-preview
{
    "name": "my-alias",
    "indexes": ["hotel-samples-index"]
}

ちなみに、インデックスの指定がindexesで配列になっていますが、公式ドキュメントに以下の記述があり、複数の指定はできないです（エラーが返ってきます）。

indexes 配列に指定できるインデックスの名前は 1 つだけです。

また、1つのインデックスに対して複数のエイリアスをつけることは問題ありません。

確認

エイリアスのリストも取得できます。

GET /aliases?api-version=2021-04-30-preview

現在どんなエイリアスが、どのインデックスに対して付与されているかがリストで取得できます。きちんと作成されたかどうかなどの確認にも使えるかと思います（もちろんエイリアス名を指定したGETも可能です）

検索での利用

検索のREST APIでインデックス名を指定していた部分をエイリアス名に置き換えるだけです。

POST /indexes/my-alias/docs/search?api-version=2021-04-30-preview
{
    "search": "pool spa +airport",
    "searchMode": any,
    "queryType": "simple",
    "select": "HotelId, HotelName, Category, Description",
    "count": true
}

更新

エイリアスの更新（インデックスの入れ替え）は作成と同じリクエストです。更新が成功すれば204のステータスコードが返ってきます（エイリアス初回作成時は201）なお、ドキュメントには以下のような記述があります。入れ替え時の注意点になるかと（入れ替えのタイミングをきちんと制御したい場合は、少しだけアプリケーションを停止するなどが必要かと思います）。

別名に対する更新がシステムに反映されるまでに最大 10 秒かかります。以前その別名が対応付けられていたインデックスを削除するのは、10 秒以上待ってからにしてください。

削除

もちろん削除もできます。

DELETE /aliases/my-alias

エイリアスを利用する場合の注意点

便利なエイリアスですが、エイリアスが使用できない場合もあるので注意が必要です。

データ登録のAPIと検索のAPIでのみエイリアス名を利用可能
- インデックスの設定変更やAnalyze Text APIではこれまで通りインデックス名を指定します。
- また、エイリアス名はインデクサー機能でtargetIndexNameにも指定できません。
エイリアス名がついているインデックスは削除不可
- エイリアスがついているインデックスを削除しようとした場合はエラーが出るようになっています。
- まずはエイリアスを削除してからインデックスを削除するという手順になります。

まとめ

簡単ですが、インデックスのエイリアスに関しての紹介でした。まだパブリックプレビューなので正式リリース時点では利用方法が変わっている可能性もあります。こちらは注意してください。

正式公開されればですが、今後Azure Cognitive Searchを使ったアプリを開発する場合はインデックスエイリアスを利用することを基本にするのがいいかもなと思います（ちなみに、Elasticsearchにもインデックスエイリアスの機能がありますが、異なる点が多いので同じものとは思わないほうがよさそうです）。

Extreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ

Wed, 12 Jan 2022 18:41:02 +0900

年末までに知り合いと次の論文を読んだので軽くまとめておきます。

Extreme Multi-label Learning for Semantic Matching in Product Search

なんで読んだの？

前回読んだ理由と一緒ですが、Semantic Searchに絡んだ検索の論文であり、Amazonの製品検索での話も関係していたので読みました。

どんな論文？

Amazonの製品検索でセマンティックマッチングを利用する方法、レイテンシを低くしつつ再現率を改善できるような仕組みを検討して評価した論文です。実際には商品検索のマッチングを大規模なマルチラベル問題（Extreme Multi-label Classification：以下ではXMC問題とする）として定義して、その問題を効率よく解く方法について検討評価しています。

検索には大きく2つのフェーズがあります。マッチング（クエリにヒットした文書の集合を求める）とランキング（マッチングのデータを関連性の高い順序で並べる）です。前回のMSの論文では、マッチング後のランキングのフェーズで言語モデルを利用した並び替えを行う話でした。今回の論文ではマッチングに関してセマンティックサーチを有効活用できないか？という論文になります。転置インデックスベースの（語彙による）検索では、スペルミスや類義語などを検索することが難しいです。語彙以外のデータ（クリックや購入といったユーザーの行動や製品の意味的表現など）を学習できる埋め込みベースのニューラルモデルを活用して、マッチングを補完する方法を検討しています。下図のようにあくまで転置インデックスベースの検索の補完として利用するみたいです（論文に掲載されていたアーキテクチャ）。

XMC問題とは？

セマンティックサーチを行なう場合、埋め込みベースのニューラルモデル（例えばBERTとか）を利用することが多いですが、クエリトークンを埋め込み空間にベクトル化する部分が推論のボトルネック（レイテンシが高くなる）になることが多いです。これは、ニューラルネットワークの複雑さに依存します。低レイテンシになるように、複雑ではないエンコーダーを用いることもありますが今度は性能（精度）が良くなくなります。

そこで、この論文ではセマンティックマッチングをXMC問題として定義し、これを効率よく解くための手法を提案しています。ここで、XMCの問題とは、入力（今回はクエリ）に対して、最も関連性の高い複数のラベル（今回は製品）を出力することとなります。 Amazonでの製品なのでほんとに大規模（ラベル＝製品＝1億件）です。

従来のXMC問題を解くための手法として、疎な線形モデルの手法、パーティションベースの手法、グラフベースの手法などが列挙されています。疎な線形モデルの手法では、ナイーブなOVR(one-versus-rest)だと出力となるラベルの数に対して線形に推論時間も大きくなるため、今回の用途には適しません。この論文ではパーティションベースの手法として、推論時間を短くできるツリーベースで疎な線形モデルの手法を評価しています。

どういう仕組み？

ツリーベースのモデルは次のような感じです。 PECOSのXR-Linearモデルを利用しています。モデルに関する詳細についてはこちらの論文に詳しく載っているようです（まだ読んでいないです、、、）。

一番上に入力として与えられるxがクエリ（ベクトル）で一番下の四角が製品にあたるラベル（Y={1,...,l,...L}）です。これらが与えられたときに最も関連性の高い上位k件のラベル（製品）を出力するモデルを生成します。モデルのパラメータは、学習データとして(x, y)(ここで、y∈{0, 1}^𝐿、すなわちクエリに製品がマッチするかしないかの二値)を使って調整します。

これは、ツリーのそれぞれの階層のノードで、その下の層に関連するデータがあるかどうか？という分類を学習すればよいことになります。学習データとしては、入力と最下層のラベルにマッチするかどうかというデータです。これをもとに、ツリーの最下層のデータをもとにひとつ上の層の分類器の学習をすればよいことになります。

推論は出来上がったツリーベースのモデルに対して、ビームサーチで行ないます。この時、それぞれの層のノードの分類器では推論の効率化のために枝刈りの閾値を設定しています。本論文で閾値の違いによる精度とレイテンシの比較も行われています。また、ビームサーチのビームサイズを変化させた場合の性能についても実験しています。

どうやって検証した？

次のようなデータを用いてAWS上にモデル構築、推論のシステムを用意し実験しています。

10億件以上のポジティブなクエリ-商品ペアのデータセット
- クエリ：2億4千万、商品：1億
ポジティブなペアとは、クリック数や購入数の集計値が閾値以上。ただし、データセットとしては集計値は利用していない。
トレーニングセット：12か月分の検索ログ
評価用テストセット：1か月分の検索ログ（12％の製品はトレーニングセットには出てこない）

というデーセットをもとに上記のモデルを学習しています。特徴量はクエリテキストと製品のタイトルをもとにTF-IDFをいくつかのパターンで導出したものが使われています。詳しくは論文の結果に関する表などを見ていただくとして。。。

結果として、1億件の商品カタログで60.9%のRecall@100を1.25ミリ秒/リクエストという低レイテンシで達成したとなっています。

気になる点は？

知り合いと3人で読んでいて次のような気になる点が出てきました。

ツリーの構築をするときに、製品のラベルの並び順（製品のクラスタリング？に他製品が似た場所に来る感じ）が推論の効率の良し悪しに影響するんじゃないの？＝Amazonではないところではうまくいかない？
- PECOSの論文読まないといけない？
製品が増えたときにモデルの組み換えとかどうするの？
- コールドスタート問題という形で今後の課題として書かれていたので、今後に期待
転置インデックスでのマッチングの補完として利用しているということだったけど、ランキングはどうしてるんだろう？
- 別のランキング用の指標があるのかな？上位k件とした場合にどうやって、決めているのか？
モデル更新のタイミングはどのくらいのスパンなんだろう？

まとめ＆感想

セマンティック検索の処理を分類問題に置き換えてその手法を用いて行い、実際のシステムに適用できそうな速度と精度を出しているのが面白かったです。セマンティック検索にもいろんな手法があるのだなと（そして、いろいろ勉強しないといけないんだなと。。。）。

気になる点にも書きましたが、ツリーの作り方になにかコツがあるのか？他の検索結果と組み合わせるときに、どのような基準で上位を選択しているのか？など疑問点も残っています。個人的には特にどのように既存のシステムにくっつけていくのかというところが気になっています。論文の続編でその辺の話が出てくるのかなぁ？

ツリーの作り方に関するPECOSの論文を誰か解説してくれると嬉しいかもなぁと思いつつ、とりあえずブログに書き残してみました。参考になるかなぁ。。。

参考文献

今年の振り返りと来年の抱負（2021）

Fri, 31 Dec 2021 22:29:19 +0900

今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。

振り返り（2020年に書いた抱負から）

まずは去年の抱負を元に書きます。今年もコロナウィルスの影響が年末まで続き、ほとんどで書けなかったです。

フリーランス継続?

ありがたいことに個人事業主として無事1年を終えられました。夏頃は5社ほどお手伝いをさせていただき、年末時点では3社をお手伝いさせていただいています。

昨年の振り返りで書いた2社はありがたいことに継続していただいています。

今年も完全リモートで仕事が終わりました。オミクロン株が来ているし、来年春くらいにはミーティングに出かけられるかなぁ。相変わらず検索のお手伝いをしています。手伝いをしつつ勉強させていただいている感じです。ありがたし。

プログラミング

ちょっとペースダウンしています。。。

extract-kana-java

新しく書いたのはこれくらいかな。 SudachiやNeologdのkuromojiでフリガナを出力して違いを見るというコマンドツールです。ちょっと比較してみたくなったので書いて公開しました。

あとは、Sudachiをいろいろと触り始めています。来年はそのへんをもうちょっと何かできるかなぁ。コーディングしないとよくないなぁと思っているので、強制的になんかやらないとだ。

検索の勉強

仕事でやってます。ブッチャー本は昨年買って手を付けてませんが。。。来年は少しずつやる予定です。あとは、Azure Cognitive SearchのSemantic Searchを触った関係でSemantic Searchに関する論文を探してちょっとずつ読んでいます。知り合いと読んでいたAmazonの論文をブログにまとめるのは来年早々に。。。

検索のポッドキャスト?

これはできませんでした。重い腰が上がらない。公開しないまでも雑談したいなぁ。

振り返り(今年あったできごと)

ここからは今年の出来事を。

自宅環境
キーボード以外もDIY
検索Slack爆誕
車買い替えた
WindowsノートPC買った

今年もずっと自宅で仕事でした。昨年だいぶそろえていたのでそれほど変更はないですが。

2月バージョン

切り替えてからずっとWindowsです。Macもブラウズ用に使ってはいますが。ただ、Windowsといっても、プログラムなどに関する環境はほぼWSL2になっています。コマンドプロンプトは触ってないなぁ。今年最後に更新された自宅環境は椅子になります。詳しくは昨日のブログをご覧ください。

キーボードもDIYしましたが、今年はほかにも少しDIYしました。

今年のDIYキーボードとコントローラーラック

このブログにも書きましたが、来年はキーマップやファーム関連を触っていきたいなと。あとロータリーエンコーダー。。。 BLE化は快適で、3台のPCの切り替えがとっても便利です。

takuya_aさんの鶴の一声で検索のSlackが爆誕しました。検索に関連する情報交換ができる場として楽しませてもらってます。年末には検索100本ノックの話が立ち上がってきています。来年も面白い話が聞けそうでワクワクしています。

あとは、車を買い替えました。初のハイブリッドです。まだまだ慣れないですが、燃費とかがとても楽しみです。

結局まだ出かけていませんが、出かけられるようにFMV Zeroを購入しました。このブログもリビングでFMV Zeroで書いています（まだちゃんとセットアップしていないので、実際にはリモートデスクトップでデスクトップにつないでそこのVSCodeで書いちゃってますが。。。）。ブログ書いたりコード書ける程度の環境は作らないとな。

来年の抱負

ということで、来年の抱負です。

フリーランス継続
プログラミング
ブッチャー本ちゃんと読む
読んだ本のブログを書く

今年もありがたいことに仕事を継続していただけて、乗り越えられました。来年も価値を提供できるように頑張っていきます。

プログラミングは失速気味のでなにかテーマを見つけないとなあ。

ブッチャー本は読み始めます。必ずｗ

ブログのペースが落ちていたり、本を読むペースが落ちているので、本を読んで自分のためにもブログを書こうと思います。書いてないって思ったら叱咤してください。。。

今年も出かけられませんでしたが、仕事も安定してあり、無事乗り切れました。人と話をする機会は減っているので雑談したいな、オンラインなどで。相手をしてやってもいいぞという方はぜひ連絡ください。

さて、来年（もう年あけちゃったけど）は出かけられるかなぁ。何はともあれ、今年もよろしくお願いします！

2021年かって良かったもの

Wed, 29 Dec 2021 22:28:24 +0900

2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。今年買ったといいながら、昨年このネタを書くといいつつ書いてないので、昨年の分も入っているかも？ Amazonのアフィリンクを貼っていますが、急いでないものはAliExpressで購入したりもしています。

象印のポット

Amazon | 象印電気ケトル 1.0L コーヒードリップ用機能付きホワイト CK-AX10-WA | 象印マホービン(ZOJIRUSHI)

いわゆる電気ケトルというやつです。これが来るまでは鍋で湯を沸かしていました。水を入れてボタンを押し、湯を沸かしている間に他のことができるのはやはり便利です。また、コーヒーを入れるためのコーヒードリップモードがあるので、ドリップするためにわざわざ湯を他のものに入れたり、専用のヤカンを使わなくても簡単にドリップができるのがさらに便利で重宝しています。

ウォータードリップコーヒーサーバー

Amazon | iwaki(イワキ) コーヒーサーバー SNOWTOP ウォータードリップ

ここ数年、冬以外は水出しコーヒーを飲んでいます。麦茶のポットのような水出しコーヒー用ポットを使っていたのですが、滴下式のほうがえぐみが少ないというのを見かけてウォータードリップのサーバーに変えてみました。このひとつ前に水のタンクの部分がプラスチックのものを利用していたのですが、ドリップする部分を壊してしまったので、部品を購入することができるこちらに切り替えました。朝、仕事をする前に豆を挽いて仕込んでおくと、昼にはコーヒーが落ちています。夏は入れ終わったポットごと冷蔵庫に入れておくと氷を入れなくてもアイスコーヒーが飲めるので気に入っています。

eufyの掃除機

Amazon | Anker Eufy HomeVac H11（ハンディクリーナー） USB充電

仕事に使っている机でプラモデルを作ったり、DIYキーボードの工作をしたりと細かなごみが出る作業を行ないます。ちょっとごみを吸いたいだけなのに、掃除機を毎回取りに行くのも面倒なので充電式のクリーナーを買ってみました。仕組みも簡単だし、USBで充電できるのでおすすめです。アタッチメントを利用してキーボードの掃除なんかもしています。

電動精密ドライバー

Amazon | Wowstick 1F+ 69in1 電動精密ドライバービット56種セットケース USB充電式 LEDライト付き [並行輸入品]

キースイッチを付け替えたり、工作したりでねじの開け閉めを頻繁に行います。思ったよりも頻度が高くなってきたので、電動の精密ドライバーを試しに使ってみたらすごく楽ができました。電池の入れ替えなどでもねじの開け閉めは行なうので、すごく役に立っています。ビットが56種類もついていますが、プラスとマイナス以外はまだ使ってないかも。。。

磁石のUSBケーブル

Amazon | SUNTAIHO マグネット充電ケーブル

DIYキーボード、エネループの充電器、上記のドライバーや掃除機など、USBで充電したり、接続するものが結構あります。毎回ケーブルを差し替えるのも大変なのですが、@ymotongpooに教えてもらった磁石のUSBケーブルがお気に入りです。先端部分（USB-C、micro）とケーブル部分が別々になっており、また、ケーブルと先端は磁石でくっつく構造なので、充電したい機器に先端部分を刺しておきます。充電や接続したいときにケーブルを近づけると磁石でくっついてくれるのでケーブルの抜き差しが必要なくなります。先端部分だけを個別に購入できたので、色々な機器にあらかじめつけてあります。

Maker hart Just Mixer 5

Amazon | Maker hart Just Mixer 5 ステレオ5入力音声ミキサー/Bluetoothオーディオ入力対応

3台のPC＋音楽サーバーとしてラズパイを主に利用しており、通知音などを1つのスピーカーから聞きたいので、ミキサーを導入しました。 5つの入力個別に音量調節できるので打ち合わせの時だけ他の音源を小さくしたりなど重宝しています。ただ、入力が増えるとノイズが乗っている気もしますが。。。

リストレスト（アームレスト）

Amazon | エレコムリストレストアームレスト肘起き扇形左右で使える2個セットブラック MOH-EL01BK

扇形のものを分割キーボードの手間においてリストレストとして使っています。使用例の写真を見ると肘を置いていますが、手のひらをおくのにちょうどいいです。これまでいくつかパームレストを試してみましたが、凹凸もなく適度な硬さで気に入っています。

コンテッサセコンダ

Amazon | オカムラオフィスチェアコンテッサセコンダ

10月に注文してクリスマスに届きました。部品が不足しているようで年内に届かないかもといわれていたのですが。 2003年くらいからアーロンチェアを使っていたのですが、さすがに買い替えるかということで奮発しました。アーロンチェアは座面がメッシュなのですが、ももが疲れるのもあり、クッション座面のものにしてみました。冬寒くないのがいいですねｗまだ届いたばかりなので調整しないと。

Kindle paperwhite

Amazon | Kindle Paperwhite - 大きくなった6.8インチディスプレイ防水機能搭載 wifi 8GB 電子書籍リーダー

車の点検などでちょっとした待ち時間があるようなときに新書や小説が読めるようにセールで安くなったタイミングで購入しました。健康診断で読書がはかどりました。もっと本を読まないとなぁ。

ということで、ここ数年で買って便利なものをまとめてみました。他にもある気がするけど、とりあえずこの辺で。

Azure Cognitive SearchのIndex Schema JSONをCSVで見たくなる

Wed, 22 Dec 2021 11:54:31 +0900

Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。

ただ、実際のインデックス定義はJSON形式でやり取りする形になっています（JSONの例：Create Index | Microsoft Docs）。上記のスクリーンショットのようにフィールド数が少ない場合はそれほど気にならないのですが、フィールド数が大きくなると一覧で見たくなることがあります。また、ポータルを自分で確認できない場合にJSONファイルを受け取って確認することもあります。こういう時は、Excel（CSV）って便利ですよね？

ということで、サクッと確認するときには、次のようなjqコマンドをWSL2上で利用して、CSVに変換して確認しています。

echo "Name", "Type", "Searchable", "Facetable", "Filterable", "Retrievable", "Sortable", "Analyzer", "IndexAnalyzer", "SearchAnalyzer" > index_schema.csv
cat index_schema.json | jq -r '.fields[]|[.name, .type, .searchable, .facetable, .filterable, .retrievable, .sortable, .analyzer, .indexAnalyzer, .searchAnalyzer]|@csv' >> index_schema.csv

例えばこんな感じになります（上記のポータルのスクショとは別のスキーマですが。。。）。

どんなフィールドオプションが利用されているか？などをExcelで開いてフィルターなどを活用してチェックするのには便利かなと。 jqコマンドをもっとうまく使うと、ヘッダ行ももっとスマートに出せるかもしれないんですが。。。

ちなみに、上記のコマンドでは残念ながらEdm.ComplexType（参考：複合データ型をモデル化する方法 - Azure Cognitive Search | Microsoft Docs）には対応していません。必要になった時に考えるかな。。。

今年のDIYキーボードとコントローラーラック

Wed, 08 Dec 2021 00:00:00 +0900

今年もアドベントカレンダーの季節になってしまいました。今年で2回目となる、pyspa Advent Calendar 2021の投稿です。昨年に引き続きDIYがらみの投稿です。

コントローラーラック

3つのコントローラーがあるのですが、結構場所を取ります。また、それぞれ充電しないといけません。

充電しつつ、邪魔にならない置き方はできないものか？と思っていたところ次のようなコントローラーラックを見つけました。

Amazon | 山崎実業(Yamazaki) ゲームコントローラー収納ラック

これそのものは場所を取るので購入は見送りましたが、エレクターの棚にワイヤーネットをつけると似たようなものができるのでは？ということで、DIYしてみることにしました。

材料

材料は以下の通りです。書いていない材料としてあとは、結束バンドがあります。

Amazon | マグネット充電ケーブル SUNTAIHO USBケーブル LEDインジケーター付き

Amazon | Anker PowerPort Atom III Slim （PD 充電器 65W 4ポート USB-C）

設置

まずは、2連のワイヤーフックでワイヤーネットをエレクターの棚にぶら下げました。

そのままでは固定されないので、下のエレクターの棚とワイヤーネットを結束バンドで固定。これで、コントローラーを置いたり取ったりしてもぐらぐらしません。

固定したワイヤーネットの表（コントローラーを配置する側）に、ネットフック50mmをコントローラーの数だけ配置しました（上の写真でフックとコントローラーの関係がわかります）。

前から見るとこのような形です。裏側に、2連フックを使って、Ankerの充電器を固定し、USBのケーブルをコントローラーの上に来るように配置します（写真ではPS4とPS5のコントローラーの上の部分にぶら下がる形です）。

コントローラーには磁石の端子をコントローラーに差し込んでおきます。

磁石のUSBケーブルを利用していることで、コントローラーを取り出すときは少し力を入れて引っ張るだけ、収めるときは、ケーブルに近づけて充電できる状態にした後にフックに載せるだけとなりました。ケーブルの抜き差しをしなくてもよいのでとても便利。全体像は次の写真のようになっています。一番上のコントローラーはエネループを利用しているのでケーブルは不要になっています。

磁石のUSBケーブルをpyspaでとんぷーに教えてもらって思いついたアイデアです。磁石の端子は色々と使い勝手が良いので、DIYキーボードやテンキー、MX Ergo、Kindleなど色々なところに使っています。

今年のDIYキーボード

キーボードを作ったのは2つですが、改造を色々やってました。ブログに記載したものはリンクだけにしておきます。

ケーブル自作

自作ケーブルキット – 遊舎工房

ケーブルも自作できるみたいなので作ってみました。現在はテンキーの配置の問題もあって、メインでは利用はしていませんが工作としては面白かったです。熱収縮チューブを処理するための道具を持っていなかったので、チューブの固定が甘いのが失敗でした。ドライヤーくらいの熱では足りないので作ろうと思っている方は要注意かと。

Corne Light v2のBLE+LPME-IO対応

詳細はブログ記事を。Corneはこれ以外に、キースイッチの付け替えも行ないました。ルブしたGateronクリアをハンダでつけなおしました。

Corne Light v2のBLE+LPME-IO対応 #DIYキーボード

Sofle keyboard v2のBLE+LPME-IO対応

詳細はブログ記事を。このブログはSofleで書いています。現在メインに利用しているキーボードです。

Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード

10月には電池モジュールを次のものに付け替えました。家で主に使用するのもあり、充電池のほうが使い勝手がよさそうだという判断です。スイッチのON/OFFもしやすくなって満足しています。

単4電池昇圧モジュール - のぎけす屋 - BOOTH

Sofleの電池モジュールをボタン電池から単4電池用に差し替えた。 pic.twitter.com/TUizwr2qmw
— Jun Ohtani (@johtani) October 16, 2021

Lunakey Miniの組み立てとBLE+LPME-IO対応

詳細はブログ記事を。Sofleと時々入れ替えて使っています。小指のあたりのずれの大きさ、親指のキーの多さが使い勝手のよいキーボードです。コンパクトなのもあり、こちらは持ち運びにも利用できるかなと考えています。

Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード

Soyuzの組み立て（Numpadキット）

Soyuz （黒基板） – 遊舎工房

自宅の作業環境(2021/02)の写真にもありますが、分割したキーボードとは別にテンキーを利用しています。 WindowsのログインでPinコードを入力したり、色々な場面で数字の入力をすることがあるためです。 Soyuzを組み立てる前は素 - Shiro – 遊舎工房を利用していたのですが、これでは「⁺」や「Enter」など、電卓のような利用方法の場合にはキーが足りません。かゆいところに手が届かないので、きちんとしたNumpadをということでSoyuzを組み立てました。

Shiroよりもだいぶ存在感があります。

GK21S（Numpad）

USB Type C充電器付きの滑らかな交換用キーボードキット (Gk21s/k21),スイッチ,デュアルモードPCB|Keyboards| - AliExpress

最後は独身の日のセールで見つけたNumpadキットです。キットといってもこちらは、基盤からケースまで組み立てが終わっているキットで、キースイッチを差し込んで、キーキャップを付けるだけというものになります。現在はこれをメインに利用しています。通常のNumpadの上に1列キーが多く、Backspaceなどを割り当てられるのが便利です。ドライバーソフトも用意されており、キーマップのカスタマイズも可能です（まだそこまでやってないけど）。

お気に入りキースイッチ

最後はキースイッチの紹介です。現時点ではこの2種類を組み合わせるのが私の好みに合っているようです（今のところ）。 Box Silentのピンクをアルファベットのキーに、Input Club HakoのVioletをCtrlやShift、Enterなどのキーに割り当てて使っています（下の写真の左側で、キーキャップをつけている部分がHako Violetになっています）。

まとめ

ということで、pyspa Advent Calendar 2021の8日目の記事でした。それほど作ったりしてないなと思っていたのですが、記事にしてみると今年も色々とDIYしてたみたいです。キースイッチやキーキャップも自分の好みが固まってきたので、来年はファームウェアやキーマップ周りをいじっていきたいと思っています。

Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ

Wed, 10 Nov 2021 14:33:16 +0900

Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。

読んだ理由

Azure Cognitive SearchでSemantic Searchが利用可能になったこともあり、「Semantic Search」に関するMSのリサーチチームが発表している論文をたまたま見つけたためです。 Elasticsearchとニューラルモデルを利用したランカーでのリランクする仕組みがSemantic Searchと似ていたので読んでみました。

ざっくりメモ

どんなもの？

クリックログなどで関連度を改善できないような場合に、ドメイン固有の言語モデルを利用して検索結果の改善をする方法が提案されているので、バイオメディカル検索で実際に評価してみたという論文です。特定分野の大量の文書から検索をするときに、ドメイン固有の事前学習した言語モデルを用意して、さらにファインチューニングする方法を評価しています。言語モデルの生成に利用されたのはBERTになります。

技術や手法のキモはどこ？

医療分野のデータを利用して評価していますが、ほかのドメインにも一般化できる可能性があることや、実際のシステムを提示している部分が肝になりそうです。

論文から引用した言語モデルを用いてランキングを行う仕組みを構築する部分の構成です。

左半分が、ドメイン固有の事前学習についてです。Wikipediaなどを利用したBERTのモデルが公開されたりしていますが、大量のドメイン固有データが用意できるのであれば、ドメイン固有のデータで事前学習することが有効であるという主張です（参考文献。これもMS Researchでした。同じチームなのかな？）。この論文ではBERTの学習データとして、ドメイン固有のテキストを用いています。実際にはPubMedBERTを利用しています。

右半分がドメイン固有のデータで生成された言語モデルを利用して、ドメイン固有のニューラルランカー（検索結果のランキングを行なう仕組み）をファインチューニングする処理です。 MS MARCOと呼ばれるMSが公開している機械学習向けのデータセットのうち、ドメイン固有のサブセットを取り出して利用しているようです。

この論文では、L1検索（第1段階の検索）にBM25を利用して、L2検索にここで作成したニューラルランカーを利用し、検索結果を返す仕組みとなっています。これは、Azure Cognitive SearchのSemantic Searchのシステムに似ています。

この論文では、BM25で検索した結果の上位60件の結果がL2のランカーの入力となっています。

以下の2つが主な論文の成果となっています。

ドメイン固有の事前学習を利用することで、高度な学習コンポーネントなどの追加することなく高い精度が出た。
既存のBM25の検索エンジンと組み合わせてニューラルランカーを使うことで、計算コストを下げつつより良い上位の検索結果を返す仕組みを構築した。

どうやって有効だと検証した？

TREC-COVIDデータセットを用いて評価して、TREC-COVIDに参加しているシステムと論文で提案している構成のシステムとの比較をしています。また、ドメイン固有の事前学習が、一般ドメインなどの事前学習と比較して影響があるかどうかの評価もしています。

実際にAzure上で構築した仕組みをMicrosoft Biomedical Searchとして公開しているようです。上記のシステム構成のように、Elasticsearchで検索して、ニューラルランカーはKubernetes上に展開されたGPUで計算をしています。論文には使用しているマシンの構成や台数なども記載があります。

実際に構築したシステムをユーザーに利用して体験したもらった結果としては、複雑な意図を持った長いクエリに対してはPubMedなどの他の検索ツールとしても良い結果が返ってきたことが確認されたとなっています。ただし、一般的な短いクエリの場合は十分な結果にならない場合があったとのことです。

議論はある？

実際にほかのドメイン（金融、法律、小売りなど）で適用してもうまくいくかは今後の研究に期待だと思います。また、ファインチューニングするときに利用できるデータが今回の論文にあるようにMS MARCOのサブセットとして抽出できればよさそうです。

他に読むべき論文は？

TREC-COVIDに参加しているほかのシステムがどのような学習や仕組みが必要なのかを見ることで、どのくらいの手間・コストが軽減しているのかがわかるはずです。

感想

ということで、読んでみました。細かなほかの手法については調べていませんが、システム構成としてはAzure Cognitive SearchのSemantic Searchの仕組みと同じだと思われます。違いは、ドメイン固有の事前学習のモデルではないことでしょうか。ある程度のドメイン固有のモデルを利用できる仕組みができると、さらにSemantic Searchがうまく使えるようになるのかもしれません（前回書いたブログではWikipediaのデータを利用してみましたが、思ったほど良い感じはしなかったです。。。ファインチューニングの仕組みもないしなぁ）。また、短いクエリでは芳しくない結果もあったというのは、おそらくニューラルランカーで評価するための情報が少なくなってしまうのだと思います。Semantic Searchに向いているクエリの作り方とかが出てくるのかな？

今年もMICESにオンライン出張してた

Tue, 13 Jul 2021 16:08:23 +0900

今年もMICESにも参加してました。昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。

MICESは2017年から始まったe-commerceの検索にフォーカスしたカンファレンスです。 ECに関連する話に特化されていますが、話題は多岐にわたっています。色々やることありますねぇ、ECも。

参加したセッション

参加したセッションの個人メモを今回も残しておきます。セッション個別のリンクは用意されていないみたいですが、公式サイトにタイムテーブルがあり、セッションのタイトル、概要に加えて、スライドのPDFもリンクがあります。動画が公開されているものもあります。

Dreaming Search

ビデオが公開されています。スライドがざっくりしたものなので最初に聞いた時にはしっくりこなかったので、聞き直してのメモです。 GDPRのような話で、個人の情報を自分たちで管理しようと流れがあります。それぞれのECサイトなどでのユーザーのイベント（何を検索して、何をクリックした）情報はそれぞれのサイトで閉じた情報になっています。このため、自分の興味のある情報が断片化された情報でそれぞれのサイトで管理されてしまい、パーソナライゼーションされるもの（ランキングだったりレコメンドだったり）がいまいちな場合があります。この個人の情報（ユーザーのイベント）をユーザー自身がハンドリングして、どの情報までをどこまで公開できるようにするというように管理できる仕組みができないか？という話のようでした。実際にそのための仕組み（もっと大きな話の仕様）を検討しているプロジェクトがあり、それに関連して検索という観点で夢を語っているセッションです。

ざっくり私が理解したのをまとめましたが、empathy.coという会社としてはいくつかPoCなども実施されているようでした。個人の情報の扱い方に関する話は新鮮で面白かったです。仕組みが出来上がり、各サイトが対応するとより個人が欲しい情報が集まりやすくなるのかなぁ？

Berlin BuzzwordsでいくつかLTをやられていた方によるファセットとその応用（彼らはRefinementsと名前をつけたみたい）についての話でした（ビデオとスライドが公開済み。）。検索エンジンとファセットの関係の歴史から始まって、Kibanaでの使い方、モバイルや音声検索・チャットボットでのファセットは難しいよね？という話につながります。ということで、Refinementsとして、ファセットを提示してユーザーに選んでもらうだけでなく状況に応じて、提案するための情報としてファセットを使うといいのでは？という話でした。例えば、チャットボットや音声検索での結果の場合、検索結果数が多くなるとユーザーが望んだものが返せるとは限らないです。その時に、ファセットの情報をもとに絞り込み条件を聞き返すネタに使うのはどうか？というような話でした。オートサジェスト（検索があいまいな時に、追加のキーワードを提案するもの）のような形でブランド名だったり、カテゴリーなどを表示する仕組みです。実際の実装の話は、彼らが過去にBerlin Buzzwordsなどで話をしているのでそちらが参考になるとのことでした（参考：berlin buzzwords 2019 / Heystack 2019）

Reinforcement learning in search

検索における強化学習の話みたいです。ビデオとスライドが公開されています。ビジネス的に検索のランキングが重要だが、そのランキングをどうやって良くしていくのか？という話です。ランキングでデフォルトのBM25から始まり、LtRを導入し、A/Bテストなどをしつつ、モデルの変化がどのようにビジネスに影響するかをはかるのが難しくなります。 LtRに対するオンライン機械学習のアプローチについて実際に直面した課題の話などがされている（はず？）です（どうも、実際にCTRなどを用いたところまでは行ってなさそう）。

多腕バンディットなどの強化学習の話が続いたあたりでギブアップしてしまいました。。。

Better Search through Query Understanding - Panel

Query Understandingに関するパネルとして3社の人がそれぞれどういった取り組みをしてるか？という話をしたあと質問などに答えていく形式でした。残念ながらビデオはまだ公開されていませんが、スライドが公開されています。QA部分も結構な時間だったのでビデオの公開がされるといいなぁ。

Understanding queries by analysing user interaction / Andrea Schütt (OTTO)

OTTOというECサイトでのQuery Understandingの紹介と、LtR導入にまつわる話。データサイエンスとして最初はQuery Understandingやってたけど、スケールしないのでLtR導入して色々と試行錯誤しているところのようだった。

Query Understanding AI search

eBayの方の発表。Query Understanding = ユーザーの興味をクエリから類推するという定義から、クエリを分類する、同定するためにどうしているか？という話でっした。単語の表面的な文字としての近さだけでは、語順が変わると意味が変わるものや、ステミングのせいで同じになってしまうものといった例を紹介しつつ、クエリをベクトルにして表現（コンバージョン、クリックなどの情報を元にプロダクトのベクトルにしてみたり）し似ているかどうか？を判断している話です。

Case study : Autocomplete Search Suggestions

Digitec Galaxusというサイトでのオートコンプリートをもっと使いやすくするためにどんなデータを集めて、どうやって表示しているか？という話でした。とりあえず入力されたものにヒットしたものを出すような実装だった場合に、サジェストされる量が多く、ノイズも多いので使いにくかったものをどうやって改善して行ったかという処理の流れなどの説明もありました。

The need for an open web search in Europe - The approach of the Open Search Foundation and its implications for E-Commerce-Companies

Speaker: Alexander Decker / OPEN SEARCH FOUNDATION

もっとオープンな検索システムを作っていこうという団体の話でした。 AWSが最近1.0をリリースしたやつとは別物です。 Googleでみんな検索しているけど、ブラックボックスなのでバイアスがかかっている。もっとバイアスフリーなインデックスを提供できると、使いやすくなるよね？みんなでそういうインデックスを作っていかないか？という話でした。 ECとの直接の関係はセッションからは読み取れませんでした。どうやって、集めるデータの基準（入れるべき、入れるべきではないなど）を作るんだろう？という疑問が残っています。公共的なものやオープンデータについてはあるとよさそうかもなぁ。

101 hints to improving the customer satisfaction on search engines in the retail industry

Speaker: Marion Hemery (Carrefour France) & Lucian Precup (a// & Adelean)

カルフールのECサイトでの検索に関する顧客満足度の改善についての話です。どんなものをどうやって図るのか、フィードバックを取るための仕組みは？そこからわかったものをどうやってシステムに優先度をつけながら取り込んでいくのか？というのをどんなものを使っているかという説明を交えながらのセッションです。スライドが結構細かく書かれているのでスライドを見るだけでもわかりやすいかな。

“An ounce of prevention is worth a pound of cure”: establishing a gold standard-based evaluation in customer projects

Speaker: Bertram Sändig & Cornelia Werk / NEOFONIE

検索の性能指標（速度ではないほうの性能）をきちんと評価する仕組みが重要だよというセッションです。検索の仕組みを変更（例ではステミングを導入するはなしをしてました）した場合に、現行システムにどういう影響が出るのか？それをどうやって図るのか、どうやってテストしていくのか？という話です。ステミングを導入したら、検索にヒットしやすくなったものも出てきたけどその弊害として今までよかった検索の結果にノイズが増え多という話をもとに、検索結果としてこうあってほしいというゴールデンスタンダードをきちんと作って育てていくべきですよという話でした。完ぺきなものなどないので少しずつやっていきましょうと。

ということで、見ていないもの（LTや最後のワークショップ）もありますが、見たものに関してメモを残してみました。

今年もBerlin Buzzwordsにオンライン出張してた

Fri, 09 Jul 2021 16:24:53 +0900

今年もBerlin Buzzwordsにオンライン出張してました。今年の開催は6月14日から17日まででした。どんなカンファレンスなのかは昨年のブログ記事をごらんください。

今年はHAYSTACKは共同開催で、MICESは別開催でした。 MICESにも参加していたので、また後日にブログ記事を公開する予定です。

参加したセッション

参加したセッションの個人用のメモを取ってあるので、簡単にまとめておきます。セッションページに動画やスライドも追加されつつあります。興味のある方はそちらをご覧いただければと。（今のところYouTubeに上がっているビデオは69本あります。再生リストはこちら）気になっていたセッションもあるので、ビデオを見てまたメモを公開すると思いますが、まずは第1弾を。ちなみに、検索をメインに見ています。Berlin Buzzwords自体はオブザバビリティやOSSコミュニティ、データのストリーミングの話などの話題もあるので、この辺りも興味があれば探してみても面白いかもです。

How to measure Diversity of Search Results

セッションページ： How to measure Diversity of Search Results | Berlin Buzzwords 2021

従来の検索では、クエリに対して精度の高い検索結果を1件または数件返すのはどうするか？というものだったが、最近、あるユースケース（ほかの物の発見を促したいケース）では検索結果の多様性を高めつつ、精度もある程度確保したいという場合があります。

ざっくりした検索クエリ（例えば自転車）の場合に、自転車だけが1ページ目にある場合よりも自転車とは別に自転車グッズも表示された場合のほうがクリック率やGMV（Gross Merchandice Value?）が上がったという話が紹介されていました。この時どのくらい混ぜればいいのか？というのを、シャノンのエントロピーを使って、検索結果の多様性を保つための具体的なヒントについて話をされています。実際にこういう計算をしてやれますねという紹介がされています。

From text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications

セッションページ: From text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications | Berlin Buzzwords 2021

Vespa.ai（OSS）の紹介でANNの話でした。通常、ANNを用いた検索の場合に他の検索条件（地理情報、日付など）をANNの結果に対して適用すると、望んでいる数がとれないです。その場合に、Vespaは内部でいい感じの動きをしますよという紹介でした。

“Are You Sure?"： blending product comparisons and recommendations with A.I.

セッションページ: “Are You Sure?"： blending product comparisons and recommendations with A.I. | Berlin Buzzwords 2021

Amazonの製品ページにある、類似商品との比較一覧のような一覧をどうやって実現するか？という話でした。比較一覧に掲載する商品を選出するパイプラインをこうやれますよね?という話でした。ログ（クリックやカートに入れたかどうかなど）を元にkNNで似ているデータを洗い出し、どの商品、どの項目を比較一覧として選ぶかという流れでした（セッションではもっと詳しい話がされています）。オフライン実験の話までがセッションでされています。

The future of Lucene’s MMapDirectory： Why use it and what’s coming with Java 16 and later?

セッションページ: The future of Lucene’s MMapDirectory： Why use it and what’s coming with Java 16 and later? | Berlin Buzzwords 2021

Apache Lucene PMCのUweさんによるLuceneのMMapDirectoryの話です。ファイルシステムとJavaに関する歴史と、なぜMMapなのか、現在のMMapの実装の問題点とJDK 16でどうなっているか（どんな感触か）、さらにその先（JDK17）は？という話です。 Luceneでの利用方法からJDKへのフィードバックが行われている話や、そのフィードバックをもとに今後どのようにしていくのか?という話がされています。

Search and Sushi; Freshness Counts

セッションページ: Search and Sushi; Freshness Counts | Berlin Buzzwords 2021

こちらもVespa.aiの紹介です（今年はスポンサーしてるから多いのかも？）。Yahoo!とVerizon Mediaで利用している話をしたあと、Vespaでのリアルタイムインデキシングに関するアーキテクチャの紹介でした。内部で転置インデックスやそれ以外のデータをどのように保持しているのか？どういったことができるのか？というのをアーキテクチャ、ストレージの観点から紹介しています。

Encores? - Going beyond matching and ranking of search results

セッションページ(動画がまだない): Encores? - Going beyond matching and ranking of search results | Berlin Buzzwords 2021

検索のマッチングやランキング以外のいくつかの機能についての紹介をワークショップ形式で行うセッションです。ファセット、クエリオートコンプリート、スペル訂正、クエリリラクゼーションについて、データとSolrのクエリを基準に説明をしてくれます。

The Invasion of Transformers - Boosting Search with Latest NLP

セッションページ: The Invasion of Transformers - Boosting Search with Latest NLP | Berlin Buzzwords 2021

deepsetという会社のCTOの方で、自社で作っているOSSのhaystackという製品の紹介です。最近のGoogleの検索結果にはいろんなもの（問いかけに関する答えそのもの、またそのプレビューやサマリー）が出てきているという話から、Transformersを使って検索ができないかということで自社のOSSの仕組みを紹介しています。

参考
- Google： BERT now used on almost every English query
- deepset-ai/haystack： End-to-end Python framework for building natural language search interfaces to data. Leverages Transformers and the State-of-the-Art of NLP. Supports DPR, Elasticsearch, Hugging Face’s Hub, and much more!

Learning to Judge

セッションページ: Learning to Judge | Berlin Buzzwords 2021

otto.deというECサイトでLtRを導入し、そのLtRにどんな特徴を利用しどうやって実験したかというセッションでした。Apache Solrで検索ができていて、これまでは検索の管理を人手で行っていたがスケールしない（扱う商品などは増えているのに）のでLtRを導入し始めたという感じでした。LtRの導入の過程でどういう仮定を置いて、どうモデルを決め、それをどうやってテストしてどう分析したか?という流れでした。

Text categorization with Apache Lucene

セッションページ: Text categorization with Apache Lucene | Berlin Buzzwords 2021

LTなので短めです。BBCのデータセットをインデックスに登録し、そのデータをもとにLucene（デモではKibana＋Esを利用していた）でテキスト分類を行なう方法について紹介しています。BBCのデータセットは記事（テキスト）とカテゴリ（タグ）というデータです。このデータが登録されているインデックスに対して、More Like Thisクエリに分類したい文章を与え、ヒットしたデータをもとにAggregationでカテゴリを取得し、上位のカテゴリが分類された結果になるというデモでした。テキストフィールドにはEdge N-Gramを利用していること、Aggregationのソートの条件はMore Like Thisクエリでのスコアの平均を利用していることというのがこの方法がうまくいくことのようでした（なるほど！）。ただ、日本語でもこれが使えるかな？というのはやってみないとわからないかなぁと（やってないです）。

とりあえず、メモしておいたのはこの辺でした。他にもセッション一覧を眺めながら面白そうな話をピックアップしてメモを取っていこうかなぁ？気になるセッション、メモがおかしいなどあればコメントいただければと。

Azure Cognitive Searchの新機能、Semantic Searchを試してみた

Thu, 01 Jul 2021 18:09:43 +0900

Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。実際にはPublic Previewという状態ではありますが、どんな機能か気になったので調べてみました。なお、本ブログは2021年6月時点での内容となります。

公式ドキュメント

公式ドキュメントでいろいろと説明されています。まずは公式ドキュメントを見ていただくのが良いかなと。最初のドキュメントには10分ちょっとの紹介ビデオもあります。ピックアップしたのは概要、クエリ、レスポンスの構造、紹介ブログになります。ブログ以外は日本語（たぶん機械翻訳？）になっています(新機能の紹介の日本語ページにはまだ記載がありません)。

簡単にですがデータを入れて試してみたので、どんな仕組みなのかどういう挙動なのかを紹介します。

Semantic Searchとは？

言語理解、セマンティック関連性などを提供する機能です。BingとMSリサーチにより開発されて、Azure Cognitive Searchに導入されました。クエリの書き方を少し変更する必要がありますが、再インデックスや設定変更などは必要ないという仕組みになっています。

検索クエリからコンテキストを読み取って、検索し、リランクするアルゴリズム(Semantic Ranker)
関連する一節を強調表示（Semantic Caption）
クエリに対するセマンティック回答(Semantic Answer)
スペルチェック機能

言語によって利用できる機能が異なります。

Semantic Searchの利点は先ほどの紹介にも書きましたが、インデキシング時に特殊処理をする必要がないことかなと。すでに登録してあるデータ（制限がありますが）でもすぐに試すことができます。

仕組み

https://docs.microsoft.com/ja-jp/azure/search/media/semantic-search-overview/semantic-query-architecture.png

スペル修正機能
クエリパース
スコアリング
上位50件に対してSemantic Rankerにより再評価（検索ヒットが50件以上の場合でも上位50件のみがリランクの対象）
- 言語表現モデルを利用
- 結果の要約として最適な部分をキャプションとして抽出。
- クエリが質問形式の場合は一番よさそうな場所を回答として選択

1および4番目の処理が今回新しく使えるSemantic Searchの機能になります。スペルチェックは日本語がまだ対象外なので、4番目の機能について紹介します。

利用できる環境と制限

冒頭でも書きましたが、Public Previewの段階です。実際に利用するにはリクエストページから申し込みが必要になっています。

利用リクエスト時に利用するAzure Cognitive Searchのサービス名が必要になるので、あらかじめ起動しておかなければいけません。また、利用できるリージョンが限定されているのでサービス起動時のリージョンには気を付けてください。

利用できるリージョン
- 米国中北部、米国西部、米国西部 2、米国東部 2、北ヨーロッパ、西ヨーロッパ
利用できるTier
- セマンティック検索はStandardレベル
- スペルチェックはレベル制限なし
価格（セマンティック検索のみ）
- 7月初旬までは25万クエリで500ドル
Analyzerの制限
- Azure Cognitive Searchが提供する言語アナライザーが対象（Custom Analyzerでは利用不可）

サービス起動後にプレビュープログラムを申請すると、利用できるようになるとメールが届きます。そこから利用ができるようになります。

今回は日本語のWikipediaのデータをいれてどんな機能なのかを確認してみました。

Wikipediaのデータを入れて試してみた

日本語のWikipedia（あとで英語も入れました）を一部（10万件程度）登録してSemantic Search（主にRanker）の動きを確認してみました。

データの登録には自作ツールを利用。

JSONデータ生成ツール：https://github.com/johtani/wiki-extractor-rs
JSONデータ登録ツール：https://github.com/johtani/wiki-json-loader

日本語Wikipediaの2020年6月のデータ、英語Wikipediaの2021年6月のデータを利用。上記ツールで生成したもののうち約10万件をAzure Cognitive Searchに登録して動作確認をしました（英語のデータでJSONデータ生成ツールでバグがあるのですが修正していません。。。）。また、クエリの実行にはVisual Studio CodeのREST Client拡張(どんなものかは以前のブログをご覧ください)を使いました。簡単にREST APIを呼び出せるのはすばらしい。

日本語のWikipedia

日本語のWikipediaのデータを「96,344件」登録し実験しました。スキーマは次のような形です（説明に必要なものだけ抽出してあります）。自然分が入っているtitle、contents、headingsの3つのフィールドを今回はSemantic Searchの対象にしてみるので、AnalyzerをLuceneベースの日本語Analyzerであるja.luceneを設定しました。

フィールド名 : タイプ / Analyzer
id : Edm.String / keyword
categories : Collection(Edm.String) / keyword
title : Edm.String / ja.lucene
contents : Edm.String / ja.lucene
headings : Edm.String / ja.lucene

Analyzerに言語Analyzerを設定するくらいで、他の設定は特に必要ありません。

クエリとデータの確認

デモの動画や説明のサンプルを見たところ英語で「Where was Alan Turing born?」や「What’s the capital of France?」のような自然文のクエリが出てきたので、次のようなクエリで試してみました。

フランスの首都はどこですか？

実際にパリのページがインデックスに存在していることは以下のクエリで確認しました。

パリ：3047件

POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "count": true,
    "search": "パリ",
    "top": 10,
    "searchFields": "title, categories, contents",
    "select": "title, id, contents"
}

※ここで{{host}}などはREST Client拡張で変数として定義したものです。

host : Azure Cognitive Searchのサービス名
index-name : インデックス名
api-key : 接続のためのAPIキー

URLパラメータのapi-version=2020-06-30-PreviewがPreview機能を呼び出すための指定になっています。

3047件の1件目が「パリ」のページで以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります。

"パリ（、巴里）は、フランス北部、イル＝ド＝フランス地域圏にある都市。フランスの首都であり、イル＝ド＝フランス地域圏の首府である。\nフランス最大の都市であり、同国の政治、経済、文化などの中心である。ロンドンと共に欧州を代表する世界都市。行政上では、1コミューン単独で県を構成する特別市であり、ルーヴル美術館を含む1区を中心に、時計回りに20の行政区が並ぶ（エスカルゴと形容される）。",

このインデックスに対して「フランスの首都はどこですか？」というクエリを、セマンティック検索のクエリと通常のクエリの2パターンで検索をしてみました。

これまでのクエリ（セマンティックではない検索）

まずは通常のクエリです。 searchがクエリ文字列、searchFieldsが検索対象フィールドになります。

POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "top": 100,
    "count": true,
    "search": "フランスの首都はどこですか？",
    "searchFields": "title, contents",
    "select": "title,  id"

}

クエリを実行するとヒット件数が'13996’件で、トップ5件のデータは次のようになりました。

  "@odata.count": 13996,
  "value": [
    {
      "@search.score": 17.059355,
      "id": "462",
      "title": "首都"
    },
    {
      "@search.score": 16.086372,
      "id": "21053",
      "title": "首都圏"
    },
    {
      "@search.score": 15.059893,
      "id": "71414",
      "title": "どこでもドア"
    },
    {
      "@search.score": 14.086605,
      "id": "51972",
      "title": "首都機能移転"
    },
    {
      "@search.score": 12.996841,
      "id": "3877",
      "title": "首都の一覧"
    },

見るとわかりますが、「首都」「どこ」といった単語を含むデータが上位に入っています。「フランス」を含むデータは8件目と10件目に「フランス植民地帝国」、「ラ・フランス」といったデータが出てきます。

    {
      "@search.score": 12.705561,
      "id": "129279",
      "title": "フランス植民地帝国"
    },
    ...
    {
      "@search.score": 12.036648,
      "id": "3173",
      "title": "ラ・フランス"
    },

残念ながら望んでいる結果にはほど遠いかと。

どんな検索になっているのでしょうか？まずは、クエリの解釈から。デフォルトで、Azure Cognitive Searchはデフォルトでは、入力された文字列をtype=simple、mode=anyで検索します（クエリパラメータ参照）。対象となるフィールドはsearchFieldsで今回は指定してあるので、これらのフィールドに対して、入力された文字列を渡してAnalyzerで単語分割し（今回はsimpleクエリ用の特殊文字が入っていないため文字列として扱われる）、出てきた単語で（mode=anyだから）OR検索します。 ja.luceneのAnalyzerが出力する単語列がどんなものかは以下のリクエストを実行するとわかります。

POST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
   "analyzer":"ja.lucene",
   "text": "フランスの首都はどこですか？"

}

結果は以下の通りです。

  "tokens": [
    {
      "token": "フランス",
      "startOffset": 0,
      "endOffset": 4,
      "position": 0
    },
    {
      "token": "首都",
      "startOffset": 5,
      "endOffset": 7,
      "position": 2
    },
    {
      "token": "どこ",
      "startOffset": 8,
      "endOffset": 10,
      "position": 4
    }
  ]

これで、どのような単語が出てきているかがわかりました。それぞれのフィールドでどのようなスコアになっているかまではわからないですが、検索結果には上記3つの単語のいずれかがsearchFieldsにヒットすれば出てきます。おそらく、ヒットした単語数が多い、短い文字列のフィールドがより高いスコアになるというような動きになっていると思われます（BM25になってるはず）。

セマンティック検索

では、セマンティック検索のクエリに変更してみましょう。

POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "top": 100,
    "count": true,
    "search": "フランスの首都はどこですか？",
    "searchFields": "title, contents",
    "select": "title,  id",
    "queryType": "semantic",
    "queryLanguage": "ja-jp"
}

queryType、queryLanguageがセマンティック検索のクエリを実行するためのパラメータになります（公式ガイド参照）。今回は日本語のデータであるため、日本語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。この2つを追加するだけです。簡単ですね。

結果は次のようになります（上位5件抜粋）。

  "@odata.count": 13996,
  "value": [
    {
      "@search.score": 12.036648,
      "@search.rerankerScore": 2.3456064984202385,
      "@search.captions": [
        {
          "text": "ラ・フランス",
          "highlights": "<em>ラ・フランス</em>"
        }
      ],
      "id": "3173",
      "title": "ラ・フランス"
    },
    {
      "@search.score": 11.144733,
      "@search.rerankerScore": 2.3173404783010483,
      "@search.captions": [
        {
          "text": "ラン (フランス)",
          "highlights": "<em>ラン</em> (<em>フランス)</em>"
        }
      ],
      "id": "108094",
      "title": "ラン (フランス)"
    },
    {
      "@search.score": 11.144793,
      "@search.rerankerScore": 2.1937477812170982,
      "@search.captions": [
        {
          "text": "ブレスト (フランス)",
          "highlights": "<em>ブレスト</em> (<em>フランス)</em>"
        }
      ],
      "id": "116154",
      "title": "ブレスト (フランス)"
    },
    {
      "@search.score": 10.199907,
      "@search.rerankerScore": 2.1590753793716431,
      "@search.captions": [
        {
          "text": "フランス・ハルス",
          "highlights": "<em>フランス・ハルス</em>"
        }
      ],
      "id": "81566",
      "title": "フランス・ハルス"
    },
    {
      "@search.score": 11.273148,
      "@search.rerankerScore": 2.1434053033590317,
      "@search.captions": [
        {
          "text": "バカロレア (フランス)",
          "highlights": "<em>バカロレア</em> (<em>フランス</em>)"
        }
      ],
      "id": "54514",
      "title": "バカロレア (フランス)"
    },

検索結果数を見ると、通常のクエリと同じ値です。これは、公式ドキュメントのセマンティック検索に説明があるように、セマンティック検索が通常のクエリで実行した後の検索結果に対して、上位50件のデータだけに対してsemantic rankerによってスコアを再計算するという仕様のためです（ドキュメントからの推測）。

実際に検索結果の50件目、51件目は次のようになっていました。50件目までのデータには@search.rerankerScoreというスコア（と@search.captions）が追加されています。 51件目のデータについては、前の通常のクエリの51件目のデータと同じデータでした。

    {
      "@search.score": 10.909212,
      "@search.rerankerScore": 0.07321979058906436,
      "@search.captions": [
        {
          "text": "首都高速埼玉大宮線",
          "highlights": null
        }
      ],
      "id": "67667",
      "title": "首都高速埼玉大宮線"
    },
    {
      "@search.score": 10.049902,
      "id": "68569",
      "title": "スタッド・ド・フランス"
    },

上位5件のデータに戻ります。これらは、通常のクエリとは異なる結果となりました。見ると@search.captionsというところにハイライトされた項目が表示されています。検索クエリをもとにそれっぽい部分がキャプションという形で返ってくる仕組みです。

結果を見るとわかりますが、残念ながら「パリ」のページは返ってきませんでした。もともと通常のクエリを実行したときの「326」番目の結果として返ってきているため、セマンティック検索の対象とはならなかったためです。ただ、「首都」「どこ」といった単語よりも「フランス」に関するドキュメントが通常の検索よりも上位に来ています。クエリに存在する単語で「フランス」がより重要であると判断されているようです。

Semantic Rankerに処理させてみる

ちなみに、今回登録したデータにはWikipediaのカテゴリも登録してあります。「ヨーロッパの首都」というカテゴリで絞り込んでから検索してみるとどうなるかもやってみました。 filterのパラメータが絞り込み条件です。

POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "top": 100,
    "count": true,
    "search": "フランスの首都はどこですか？",
    "searchFields": "title, contents",
    "select": "title,  id",
    "queryType": "semantic",
    "queryLanguage": "ja-jp",
    "filter": "search.ismatch('ヨーロッパの首都', 'categories')"
}

結果は次の通りです。カテゴリで絞り込みをしているので検索結果数は39件となります。このため、すべてのデータがSemantic Rankerの対象です。ですが、「パリ」のページは11件目に出てきました。

  "@odata.count": 39,
  "value": [
    {
      "@search.score": 3.8405614,
      "@search.rerankerScore": 2.0472740978002548,
      "@search.captions": [
        {
          "text": "ウィーン",
          "highlights": null
        }
      ],
      "id": "9465",
      "title": "ウィーン"
    },
...
    {
      "@search.score": 4.8915977,
      "@search.rerankerScore": 1.8480307757854462,
      "@search.captions": [
        {
          "text": "レイキャヴィーク",
          "highlights": "<em>レイキャヴィーク</em>"
        }
      ],
      "id": "112253",
      "title": "レイキャヴィーク"
    },
...
    {
      "@search.score": 7.277628,
      "@search.rerankerScore": 1.7982495501637459,
      "@search.captions": [
        {
          "text": "パリ",
          "highlights": "<em>パリ</em>"
        }
      ],
      "id": "31",
      "title": "パリ"
    },

キャプションは入力された単語だけではなく、クエリが持っている単語をもとにした何かしらの基準（おそらく言語モデルで近い単語？）で選択されていると思われます。首都というカテゴリーで絞り込んでしまったので、ヒットした文章が似たようなものが多くなったせいか、残念ながらそこまでSemantic Rankerが意図を汲み取るところまでは行きませんでした。

フランスの歴史

視点を変えてみましょう。質問そのものの答えではなく、クエリの意図に近いものが出てくるかを見てみましょう。ここまでのクエリでフランスに関するクエリを投げていました。今回のインデックスに「フランスの歴史」で検索すると「30820」件のドキュメントがヒットし、上位にはフランスには関係ない「歴史」のページや「フランス」の文学、都市など「フランスの歴史」とは少し離れた意味のものが上位に来ています。

  "@odata.count": 30820,
  "value": [
    {
      "@search.score": 12.888079,
      "id": "17875",
      "title": "スコットランドの歴史"
    },
    {
      "@search.score": 12.718105,
      "id": "10665",
      "title": "世界の歴史"
    },
    {
      "@search.score": 12.701981,
      "id": "31397",
      "title": "ベトナムの歴史"
    },
    {
      "@search.score": 12.579847,
      "id": "22433",
      "title": "フランス文学"
    },
    {
      "@search.score": 12.524254,
      "id": "34667",
      "title": "フランスの国旗"
    },
    {
      "@search.score": 12.52136,
      "id": "108094",
      "title": "ラン (フランス)"
    },
    {
      "@search.score": 12.41088,
      "id": "20717",
      "title": "歴史小説"
    },
    {
      "@search.score": 12.388911,
      "id": "56229",
      "title": "演劇の歴史"
    },
    {
      "@search.score": 12.343941,
      "id": "39669",
      "title": "イギリスの歴史"
    },

このクエリをセマンティッククエリで検索すると次のようになりました。

  "@odata.count": 30820,
  "value": [
    {
      "@search.score": 12.274498,
      "@search.rerankerScore": 1.482184374704957,
      "@search.captions": [
        {
          "text": "自由フランス",
          "highlights": "<em>自由フランス</em>"
        }
      ],
      "id": "96475",
      "title": "自由フランス"
    },
    {
      "@search.score": 11.446766,
      "@search.rerankerScore": 1.3535655084997416,
      "@search.captions": [
        {
          "text": "フランスの地域圏",
          "highlights": "<em>フランスの地域圏</em>"
        }
      ],
      "id": "51845",
      "title": "フランスの地域圏"
    },
    {
      "@search.score": 10.926437,
      "@search.rerankerScore": 1.3261859538033605,
      "@search.captions": [
        {
          "text": "フランス第一帝政",
          "highlights": "<em>フランス第一帝政</em>"
        }
      ],
      "id": "57573",
      "title": "フランス第一帝政"
    },

上位には「フランスの歴史」に関連しそうなタイトルが上がってきています。また、先ほど「歴史」という単語でヒットして上位に来ていた「スコットランドの歴史」は@search.rerankerScoreの値が低くなっていました（31件目に出現）。


    {
      "@search.score": 12.888079,
      "@search.rerankerScore": 0.42768346797674894,
      "@search.captions": [
        {
          "text": "スコットランドの歴史",
          "highlights": null
        }
      ],
      "id": "17875",
      "title": "スコットランドの歴史"
    },

考察

日本語のWikipediaを約10万件入れたインデックスでセマンティック検索を試してみました。デモや説明などでクエリが自然文の質問だったこともあり、質問の回答になりそうなページが上に来るかと期待しましたが、期待しすぎました。

これは、Azure Cognitive Searchのセマンティック検索の仕組みを考えると納得のいくものです。説明を読んだ時にも感じたのですが、入力された文字列でまず検索をし、上位50件をセマンティック検索の対象としています。

ですので、そもそもクエリの文章に出てくる単語が含まれたデータだけが対象となります。このため、クエリに出てこない単語のみで構成されているものは残念ながら対象とできません。また、上位50件だけがSemantic Rankerの対象となっているため、検索にヒットしたとしても上位に食い込まなければ言語モデルによるランキングの対象にもなりません。セマンティック検索といっても、残念ながらドキュメントに出てこない単語（似た単語、質問に対するそのものの回答）まで読み取る機能はありません。

ただ、「フランスの歴史」の検索で見たようにそれぞれの単語だけで検索をしていた場合とは異なり、クエリの意味に沿ったスコアづけにより、通常の検索よりも意図したものに近いデータが出ていることが確認できました。複数の単語で構成されるクエリの場合に、単語だけでスコアを計算した場合よりもよさそうな結果が上位に出てくることがわかりました。

ただし、重要なのは「上位50件」までしかSemantic Rankerの対象にはならない点です。

英語のWikipedia

セマンティックは英語対応が一番最初にリリースされているので、英語のWikipediaについてもデータを登録してみました。

英語のWikipediaのデータを「111,649件」登録しました。スキーマは以下の通り（今回の調査に利用していないものは省略）です。日本語と異なる点はAnalyzerがen.luceneになっていることぐらいです。

フィールド名 : タイプ / Analyzer
id : Edm.String / keyword
categories : Collection(Edm.String) / keyword
title : Edm.String / en.lucene
contents : Edm.String / en.lucene
headings : Edm.String / en.lucene

クエリとデータの確認

日本語同様に首都に関する質問形式にしてみました。

What’s the capital of Italy?

実際にRomeのページがインデックスに存在していることは以下のクエリで確認済みです。

Rome：2302件

POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "count": true,
    "search": "Rome",
    "top": 10,
    "searchFields": "title, contents",
    "select": "title, id, contents"
}

以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります（これも日本語と同じです）。

""\n\nRome (Italian and Latin: Roma ) is the capital city and a special comune of Italy (named Comune di Roma Capitale), as well as the capital of the Lazio region. The city has been a major human settlement for almost three millennia. With 2,860,009 residents in , it is also the country's most populated comune...",

このデータ群に対して「What’s the capital of Italy?」というクエリを、Semantic Searchのクエリと通常のクエリの2パターンで検索をしてみる。

これまでのクエリ（セマンティックではない検索）

まずは、Semantic Searchではないクエリです。

POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "top": 100,
    "count": true,
    "search": "What's the capital of Italy?",
    "searchFields": "title, contents",
    "select": "title,  id"

}

ヒット件数は18049件で、トップ5件は次のような形です。

  "@odata.count": 18049,
  "value": [
    {
      "@search.score": 17.870815,
      "id": "14532",
      "title": "Italy"
    },
    {
      "@search.score": 16.596167,
      "id": "14702",
      "title": "Economy of Italy"
    },
    {
      "@search.score": 16.180624,
      "id": "183878",
      "title": "Louis II of Italy"
    },
    {
      "@search.score": 15.917025,
      "id": "29665",
      "title": "State capitalism"
    },
    {
      "@search.score": 15.88901,
      "id": "215741",
      "title": "Capitalization"
    },

日本語の場合よりもItalyに関連するものが上位に多く含まれます。ただ、Rome自体のページは上位50件には出てきていませんでした。また、capitalとは意味の異なるcapitalizationやcapitalismが上位に来ています。日本語の場合と同様にクエリがどのように解釈されているのか？も見てみます。

POST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
   "analyzer":"en.lucene",
   "text": "What's the capital of Italy?"

}

結果は以下の通りです。

  "tokens": [
    {
      "token": "what",
      "startOffset": 0,
      "endOffset": 6,
      "position": 0
    },
    {
      "token": "capit",
      "startOffset": 11,
      "endOffset": 18,
      "position": 2
    },
    {
      "token": "itali",
      "startOffset": 22,
      "endOffset": 27,
      "position": 4
    }
  ]

日本語とあまり変わってはいません。ただ、単語が入力されたものとは少し変わっています。これは、en.luceneの処理で、stemmingが行われているためだと思われます。たとえば、「capital」の場合、Stemmingにより「capital」「capitalize」などの単語が元になりますが、動詞、名詞などの違いなく検索できるようにするためにこのようなStemmingの処理が行われます。ということで、これらの単語を含むドキュメントがヒットしています。Italyが一番上に来ているのはItalyという単語が多く含まれるからのようです。

Semantic Searchクエリ

では、Semantic Searchのクエリに変更してみましょう。

POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "top": 100,
    "count": true,
    "search": "What's the capital of Italy?",
    "searchFields": "title, contents",
    "select": "title,  id",
    "queryType": "semantic",
    "queryLanguage": "en_us"
}

queryType、queryLanguageがsemantic searchのクエリを実行するためのパラメータになります（公式ガイド参照）。今回は英語のデータであるため、英語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。

結果は次のようになります（上位5件抜粋）。

  "@odata.count": 18049,
  "value": [
    {
      "@search.score": 17.870815,
      "@search.rerankerScore": 1.9688458815217018,
      "@search.captions": [
        {
          "text": "Italy",
          "highlights": null
        }
      ],
      "id": "14532",
      "title": "Italy"
    },
    {
      "@search.score": 14.239678,
      "@search.rerankerScore": 1.9419755563139915,
      "@search.captions": [
        {
          "text": "Capital city",
          "highlights": null
        }
      ],
      "id": "181337",
      "title": "Capital city"
    },
    {
      "@search.score": 10.181764,
      "@search.rerankerScore": 1.8902588561177254,
      "@search.captions": [
        {
          "text": "Lepontii",
          "highlights": null
        }
      ],
      "id": "325133",
      "title": "Lepontii"
    },
    {
      "@search.score": 10.865718,
      "@search.rerankerScore": 1.875102698802948,
      "@search.captions": [
        {
          "text": "ItalY",
          "highlights": null
        }
      ],
      "id": "14482",
      "title": "ItalY"
    },
    {
      "@search.score": 11.689348,
      "@search.rerankerScore": 1.8201303631067276,
      "@search.captions": [
        {
          "text": "Savoy",
          "highlights": null
        }
      ],
      "id": "27885",
      "title": "Savoy"
    },

日本語で見てきたように、検索結果数を見ると、通常のクエリと同じ値で、残念ながら50件までにRomeは入っていないため、Semantic Rankerによるブーストもかかりませんでした。ただし、「Capitalization」や「State capitalism」といった別の意味（地理に関するものではない単語）のものが上位に出てこなくなっています。これは、capitalという単語が地理に関する意味を持っていると判断された結果のように見えます。 Capitalizationの@search.rerankerScoreは上位のスコアに比べて小さいものとなっています。

    {
      "@search.score": 15.88901,
      "@search.rerankerScore": 0.93921028636395931,
      "@search.captions": [
        {
          "text": "Capitalization",
          "highlights": null
        }
      ],
      "id": "215741",
      "title": "Capitalization"
    },

What’s the capital of Finland?

上位50件以内(20件目)に「Helsinki」のページが出てくるクエリでセマンティック検索をしてみました。


POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview
Content-Type: application/json
api-key: {{api-key}}

{
    "top": 100,
    "count": true,
    "search": "What's the captial of Finland?",
    "searchFields": "title, contents",
    "select": "title,  id",
    "queryType": "semantic",
    "queryLanguage": "en-us"
}

結果としては、2件目にHelsinkiが返ってきていたので、Semantic Rankerがによる並び替えがうまくいきました。（下記の結果は上位3件を抜粋したものです）。

  "@odata.count": 16673,
  "value": [
    {
      "@search.score": 14.026371,
      "@search.rerankerScore": 2.42378556355834,
      "@search.captions": [
        {
          "text": "Vanaja (Finland)",
          "highlights": null
        }
      ],
      "id": "7132102",
      "title": "Vanaja (Finland)"
    },
    {
      "@search.score": 12.434971,
      "@search.rerankerScore": 2.383675143122673,
      "@search.captions": [
        {
          "text": "Helsinki",
          "highlights": null
        }
      ],
      "id": "13696",
      "title": "Helsinki"
    },
    {
      "@search.score": 13.380153,
      "@search.rerankerScore": 2.2026549801230431,
      "@search.captions": [
        {
          "text": "Rauma, Finland",
          "highlights": null
        }
      ],
      "id": "178635",
      "title": "Rauma, Finland"
    },

考察

今回の英語のクエリではSemantic Rankerがある程度の役割をはたしていそうだということはわかりました。 Capitalがいくつもの意味を持っていることもあり、文章をもとにより意味の近いドキュメントが上位に来たということです。ただ、英語の場合も基本的には上位50件以内のデータに対して処理が行われるので上位50件以内にデータが入らなければうまくいかないようです。

まとめ

Azure Cognitive Searchの新機能であるセマンティック検索について調べてみました。まだPublic Previewですが、簡単に使えるような仕組み（データの再登録なし、クエリでパラメータを追加するだけ）が用意されているのは便利でした。ただ、最初に想像していたもの（私の早とちりもありますが）ほどのセマンティック検索とは行きませんでした。似たような言葉の意味を持ったものを探してくれたり、答えそのもののページのスコアがすごく高くなるといったものではありませんでした。

仕組み上、クエリに含まれる単語で検索し、上位50件以内のデータだけが対象になる(残念ながら現時点ではこの件数の変更はできません。)ため、これまでの検索とは劇的に変化するものではないことはわかりました（銀の弾丸はないんですけどね）。

ある程度の挙動をわかっていれば、Wikipediaのようなデータでもそれなりの結果は取得できそうだということはわかりました。

「言語モデル」でクエリとヒットしたデータをもとにスコア計算をし直しているようですが、この部分がどのようなデータ・クエリだと有効活用できるのか？というのをもう少しいろいろな角度で試してみる必要がある気がします（適材適所が何なのか？）。あとは、上位50件までが対象なので、それ以上の件数のデータの並びに関してはこれまでと同様の結果となる点は注意しないといけません。また、今回試していないほかの機能（スペルチェック、Semantic Answerなど）にメリットがあるのかもしれません。

ざっくりですがセマンティック検索について調べてみました。こんなデータだとどうなの？ここの考え方が間違ってるのでは？などの指摘がありましたら、コメント欄またはTwitter（@johtani）でコメントを頂けたらと。

Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード

Fri, 30 Apr 2021 00:26:12 +0900

Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売していました。小指のあたりの傾斜が使いやすいかも？ということで、組み立ててみました。

もちろん購入はKochi Keyboardさんからです（購入はこちらから）。

Lunakey Miniビルドガイド

作者のYoichiroさんが公開しているビルドガイドが詳細まで書かれています。こちらをまずは参照してください。

Lunakey Mini ビルドガイド (Rev.4以降)

ビルドログ（主にツイート）

私の組み立てについては、Twitterでツイートしていたものがありますので、そちらを貼っておきます。ちなみに、ツイートしていて躓いているときに、作者のYoichiroさんからたびたびコメントをいただきました。ありがとうございました！！

間にいくつかコメントを差し込んでいます。

結局両方のダイオードつけてしまいました。今日はここまで pic.twitter.com/3qLI6EpfXB
— Jun Ohtani (@johtani) April 12, 2021

ハンダはつけた pic.twitter.com/ySE9SA3gZn
— Jun Ohtani (@johtani) April 13, 2021

コンスルー問題

左手じゃん、T。Tのダイオード浮いてた。右手も一回全部見直すか
— Jun Ohtani (@johtani) April 13, 2021

ここで問題が発覚。右手（ツイートではぼけていて、左手と書いています）についてはダイオードが1か所浮いていただけなので、はんだ付けですぐ直りました。左手側が大問題です。そもそも右手につけたProMicroへの書き込みができませんでした。キーボードによっては、ダイオードなどを付ける前からまず、リセットボタンを付けて、ProMicroを指して書き込みをする場合もあります。ただ、その書き込みができない。（ちなみにこのタイミングでテスターをつけっぱなしにしていたのが発覚し、9V電池切れのため翌日に持ち越した。。。）

さて、デバッグのお時間です pic.twitter.com/CaEOv4E5Bg
— Jun Ohtani (@johtani) April 14, 2021

ただ、ProMicro刺した状態で、リセットボタン、リセットボタンの足をショートさせても書き込みはできず、ProMicroのGndとResetの足のショートでは書き込みができる。
— Jun Ohtani (@johtani) April 14, 2021

テスターで調べてみたところ、リセットボタンとProMicroがうまく通電していません。

だいぶ進んだけど、Eの列がおかしいなぁ。さて、どこの接触だ？ pic.twitter.com/5tci12Vk05
— Jun Ohtani (@johtani) April 14, 2021

どうも、左手の基盤のProMicroの足の穴がコンスルーとの接触が悪いみたいでした。コンスルーの足を無理やりまげて（3個のコンスルーの足を折りました。。。）、通電できるようにして解決（結局あとでいくつかの足についてははんだ付けしました）。

終わった。LEDの予備はんだまでやってからおしまいにしよ
— Jun Ohtani (@johtani) April 16, 2021

LED実装

鬼門の表面実装ですが、LEDを1個破損するだけで乗り切りました。ちょっと色はおかしかったですが、これはおそらくProMicroの足のせい。

一個逆につけてしまい、お亡くなりになりましたが、まぁ、良いかな。まずは右手 pic.twitter.com/zldu6fRsXR
— Jun Ohtani (@johtani) April 18, 2021

ソケットの実装x2

ロープロファイル（Kailh choc v1）のキースイッチも試してみたいので、MXと両方のソケットをはんだ付けしました。両方利用できるのは便利ですね。はんだ付けも楽しいし。

ソケットを片手だけ(両方のソケットつけるのでまだ、1/4) pic.twitter.com/7XFRDx0D0I
— Jun Ohtani (@johtani) April 18, 2021

キースイッチ設置

親指以外にはKailh Box Silentのピンク軸（Kochi Keyboardから）、親指にはKailh Input Club Hako Violet（AliExpressで購入したもの。リンクは遊舎工房のもの）をつけました。どちらもそれほどぶれもないものです。Silent ピンクはリニアで静かでそれほど力がいらないスイッチになっています。親指はタクタイルで小気味のいい音が気に入っています。Sofleもこのキースイッチになってます。

残りのソケットつけて、キースイッチも設置して、動確してボトムプレートも装着。残りはキーキャップ。 pic.twitter.com/hGc1TtI6fu
— Jun Ohtani (@johtani) April 25, 2021

キーキャップ＋キーマップ

お試しにXDAのキーキャップをはめてみたのですが、キーの境目がわかりにくく、タイプミスが多かったです。その後のツイートにあるようにOEMに切り替えています。

キーマップについては、Lunakey Miniの作者のYoichiroさんが作ったRemapというブラウザベースでキーマップの書き換えができるツールで楽々変更ができました。JISキーまで対応しているのでJISベースでキーマップを作成している私にはうってつけでした。 Remapの利用方法についてはサリチル酸さんのブログが詳しく書いてあります（本当に頭が下がります）。

Remap使ってキーマップいじったら、すごく楽だった。
— Jun Ohtani (@johtani) April 26, 2021

BLE + LPME-IO化

ここまでで、USB接続で動作はしていたのですが、Sofle同様に3台をBluetoothで切り替えながら使いたかったので、 Corne Light v2につけていたBLE+LPME-IO(Corneの実装などは前のブログを参照)を抜き取って、Lunakey Miniに移植してみました。

BLE ProMicro化は作者の方のブログで行われていたので、LPME-IO対応も何とかなるだろうと。

BLE+LPMEに変えた。後でブログ書こう pic.twitter.com/mGePN52v6k
— Jun Ohtani (@johtani) April 29, 2021

LPME-IOへの対応はCorneとSofleの時に行なったこともあり、なんとなくあたりがついていました。流れとしては、以下の通りです。

BLE Micro Pro用の設定ファイルを作成
- BLE Micro Proのサイトの「キーボードの設定ファイルを編集する」のコマンドでコンフィグファイルを生成
LPME-IOのジャンパをはんだでブリッジ
- 1.で生成したコンフィグから、Corne Lightと同じ個所のジャンプをすれば良いとわかったので今回はスキップ
TRRSのI2C対応
- Corne LightのLPME-IO対応の時と同様にSDAとSCLをTRRSの足にショートカット
- ただ、今回右手側は、下記ツイートのようにOLEDの足からTRRSの足にショートカットしました。Corneの基盤を見ていた時にこれでも行けそうだな？と思っていたので、試してみた次第です。ちなみに、左手はCorneの時と同じPro Microから長い銅線を引っ張っています（電池基盤があったので、外すのがめんどくさかったため）。
BLE Micro Proにファームウェア書き込み
- BLE Micro Proのサイトの手順に従います。
- 設定ファイルには1.で出力されているLPME用のファイルを使用。

といった感じです。キーマップが設定されていないので、Remapで設定しなおしました。 Remapは、キーマップをPDFで出力する機能までついていて、すごくいいですね。サイコー

あと、足。 pic.twitter.com/W0Wpf5k5SE
— Jun Ohtani (@johtani) April 29, 2021

傾斜がつくように奥側に高さを出すためのゴム足を貼り付けました。あとは、3台のPCにBluetoothで接続すれば終了です。（AD_WO_Lのキーを利用して追加していくのを毎回忘れる。。。）

疑問点

ちょっとだけ疑問点がありますが、時間があればそのうち調べるかな。

Remapはクラウドに設定ファイルをセーブできるけど、json形式で手元にダウンロードしたりはできないのかなぁ？
LEDは有線じゃないと点かないみたいだけど、音はどうなんだろう？
- 音が出せそうなら、Bluetoothの接続切り替えするときに音の出方を変えるとかをやってみたいなぁ。

まとめ

ということで、Lunakey Miniを組み立てて、BLE+LPME-IO対応してみました。はんだ付けはだいぶ慣れてきましたし、今回もトラブルがあったおかげでテスターを利用して、どのあたりがおかしいかという調査をするのも慣れてきました。あとは、キーの配置の違いを体感して、どれが自分に合ってるかなぁ？というのを試したり仕様と思います。ロープロファイルも試してみようかな。

あ。もちろん、このブログは組み立ててBluetoothで接続したLunakey Mini Rev5、Kailh Box Silentピンク軸＋Input Club Hako Violetで書きました！！久々に数字列がないので記号入力とかがちょっとバタバタしましたｗ

スライド作成の環境をMarpにしてみた

Mon, 05 Apr 2021 18:45:11 +0900

みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？

私は、Macでスライドを作るときは前職ではテンプレートもあったのでKeynoteでしたが、ちょっとしたものはMarkdownベースのDecksetを利用していました（買い切りタイプの有料ソフト）。

フリーランスになってもこちらを利用していたのですが、Windows環境に切り替えたので使えなくなってしまいました。一度はGoogle Slidesで作ったのですが（第39回Es勉強会スライド）、既存の資産を流用したくなりどうしたものかと悩んでい(ツイートし)たら。

Macの頃はDecksetってアプリでMarkdownで書いてたんだけど、Winに移動したのでこのタイミングでGoogle Slidesにでもしようかなと考えてるところ。Markdownでスライド作るのほかになんかあるか探すほうがいいかなぁ？
— Jun Ohtani (@johtani) March 18, 2021

僕はこれ使ってますhttps://t.co/sFaAmKZY6V
— miyake / ZEN (@kazuyukimiyake) March 18, 2021

ということで、利用してみようかなとなりました。

Marpとは？

Markdownでプレゼンテーションのスライドを作ることができるOSS?になります。

Marp公式サイト

といっても、これ自体を使わなくても、VS Code上でプレビューしたりHTML形式で動作するスライドを吐き出すことが可能です。なので、VS Code用のプラグインを利用しています。

サンプル

この間利用したスライドはこんな感じのMarkdownになってます。 ---でページを区切りつつ、記述していく形です。

---
marp: true
theme: poster

---

<!-- _class: big-center -->
# 本当にその検索は<br/>自分が想像している検索に<br/>なってますか？

<br/>
<br/>

> 2021/03
> Jun Ohtani / @johtani

---
![bg right:40% 40%](johtani_face.jpg)
# 自己紹介



- フリーランスエンジニア 
- 検索技術勉強会主催者
- Apache Solr入門(第2版まで)や
データ分析基盤構築入門の著者の一人

---

プレビューで見るとこんな感じです。

プラグイン

Marp for VS Code

プラグインをインストールするのも簡単ですよね。マーケットプレイスからインストールすれば完了です。

機能については上記のページにあるように、プレビューとスライドの出力です。プレビューでは、Markdownのプレビューみたいな形で、スライドが表示できます。

先日この機能を利用して作成して、HTMLで出力して利用しました。 PDFとかPPTX出も出せるようなので、今後試してみようかなと。

Decksetのスライドとの違い

ページの区切りなども同じだったので、大筋ではそれほど違いはありませんでした。ただ、画像周りとスタイルの設定は細かく修正をしました。

変更した点としては、以下のようなものがあります。

ヘッダ部分の変更
- 上のサンプルにありますが、marp: trueを含む部分がMarp独自の記述です。
ページごとのちょっとした変更
- ページごとにスタイルの変更ができるみたいで（Decksetではできなかったはず？）、タイトルページのスタイルを変えてあります。
画像の指定
- 画像の読み込み自体は違いはないのですが、画像の配置についての指定方法は
カスタムテーマ用CSSの作成
- デフォルトではなく、Decksetで用意されているような感じのスタイルに変更してみてます。

カスタムテーマはCSSで設定できるので、CSSファイルを用意して、VS Codeの拡張機能の設定からファイルパスを指定する形です。

ということで、当面はMarpでスライドを作っていくことになるかと思います。まぁ、ただ、スライドを作るいこと自体が減ってきてはいるのですが。ほかの配色を試したり、ヘッダフッタとかも試してみるのもいいかもな。

気が向いたら、CSSをどこかにアップロードするかもです。

※今回のブログはGateronサイレントクリア軸をルブしてみた、Corne Light v2で最後の数行を書いてみました。キースイッチだけだとこすれる音が減った気がしてましたが、キーキャップを付けたら少しこすれる音が気になる感じです。

検索技術に関する情報交換を目的としたSlackができました！

Wed, 31 Mar 2021 23:28:14 +0900

新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。検索技術勉強会も、もう1年以上開催できていないです。

スピーカーの人にオンラインでしゃべってもらうのもありだとは思うのですが、懇親会とセットでその価値があったかもなぁと思うところもあり、オンラインでの開催に乗り気になれないまま時間がたってしまいました。 (配信周りを調べるのがめんどくさいなぁというのもあったかも（反省）)

そんな中、takuya-aさんと話をしていて、エンジニア同士のゆるいつながりができる場所が欲しいですねぇということに。

はー、検索技術勉強会、オフラインでできないまま１年以上たってしまったのか。オンライン勉強会とかはスピーカーの人の負担とかもあるし、Discordみたいなオープンな場だけ用意してみるのありかなぁ？ただ、活発に話がされるのかどうかわからんし、ROMな人ばかりだとアレなんだけどなぁ。
— Jun Ohtani (@johtani) March 30, 2021

そこからの、このツイートです。ちらほらと興味のありそうな人が出てきたねという話をしていたら、Slackのワークスペースが出来上がってましたｗ

検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff
— takuya-a (@takuya_b) March 31, 2021

ありがとう、takuya-aさん！

ということで、検索周りでわいわいできる場になればいいなぁと。盛り上がってくれば、オンラインでの勉強会とかもありかもしれないですね！興味のある方は、上記ツイート内のリンクからご参加下さい！！

OData式と日本語の検索(NGram)とフレーズ検索

Wed, 03 Mar 2021 16:23:33 +0900

Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderby）、取得する項目名の指定（$select）です。

私は、Luceneの構文に慣れているので、普通のsearchパラメータを利用しようとします。が、OData式として特殊な書き方がいくつかあるようなのでこちらの利用方法も調べてみました。その時、N-Gram（よくやるのはN=2）で陥る問題の話もあるのでこちらについても言及します。

OData式で検索

次のような3件のドキュメント(フィールド名はbodyとします)をN-Gramで登録していたとします。

ミルクティを飲みたいです。
マティーニはカクテルですが、ミルクセーキは？
風呂上がりのミルクは最高です。

この時、OData式でミルクティという単語で検索してみましょう。

検索条件は$filterで指定します。フルテキスト検索用に関数が用意されており、こちらに単語を指定します。

$filter=search.ismatchscoring('ミルクティ')

こんな感じ。フィールドの指定がない場合、対象のフィールドは検索可能なフィールドすべてが検索対象になります（公式ガイドのクエリパラメータのqueryTypeに説明あり）。

では、実行してみましょう。で返ってくるのは？1だけかな？と思う人が多いかもしれません。が、結果は3件とも帰ってきます。

問題点は？

では問題点はどこでしょう？ ismatchscoringのオプションなどを見る前に、転置インデックスを用いた検索エンジンの挙動をおさらいしましょう。転置インデックスの仕組みを理解することで、なぜそんな挙動になるのか？というのがわかりやすくなります。おさらいにはElasticsearchをベースに話をしますが、Azure Cognitive Searchでも同じような挙動になります。

転置インデックスとトークナイザー（アナライザー）の関係（おさらい）

昨年、オンラインで開催されたOSC広島で発表した資料（録画あり）でもざっくりと説明しています。

View 本当にその検索は自分が想像している検索になってますか？ on Notist.

ざっくりですが、おさらいです。

検索エンジンでは、入力された文章を、ある規則（アナライザー）で単語に分割し、その単語ごとにどのドキュメントに出現したのか？というリストが作られます。このリストが転置インデックスです。書籍の後ろにある索引を想像するとどんなものかがわかりやすいです。単語に対してその単語が出てくるページ番号がわかるという仕組みです（下図は本の索引の一例）。

書籍の索引は著者や編集の方により厳選された単語のみが採用されています。が、検索エンジンでは文章を単語に区切る機能が存在します。この「ある規則」で単語を区切る仕組みが「アナライザー（トークナイザー）」と呼ばれる機能です。例えば英語用のアナライザーに英語の文章が入力されたとき、文章はこのように単語に区切られたもの（単語列）を出力します（下図）。

今回はNGramの話なので、NGramのAnalyzerを利用してみるとこんな感じになります。

実際に出来上がる転置インデックスは次のような形になります。

検索の仕組み（おさらい）

出来上がっている転置インデックスに対して検索をする場合、入力文字列（検索条件）に対して、転置インデックス作成時と同様にAnalyzerが動作します。処理としては、

クエリのパース
フィールドのAnalyzerで処理
転置インデックスを検索

という形です。例えばこんな感じ。

同じAnalyzerの処理が入ることで、転置インデックスに採用されているのと同じ単語が出てくるため、検索がきちんとできるということになります。

英語と日本語（NGram）の違い

英語と日本語の違いは、スペースの意味になります。英語の場合は、スペースが単語の区切りになりますが、日本語の場合スペースでは区切られていません。

ですので、検索窓に入力された文字列は、英語の場合、クエリのパースの時点で単語に区切られます。そのあとにAnalyzerになるので、基本的には単語単位でAnalyzerの処理が動きます。そのあと、転置インデックスへの検索となります。なので、多くの場合はAnalyzerの出力は1単語です（類義語などを利用していたりする場合は異なりますが）。

日本語の場合、スペースでは区切られていないので、クエリのパースの時点で入力された文字列がそのままAnalyzerにわたります。今回はAnalyzer（NGram）が単語に分割し、それをもとに検索処理が実行されます。

ismatchscoringの問題点は？（やっと帰ってきました）

さて、回り道をし、簡単ですが転置インデックスやAnalyzerについて説明しました。では本題です。

$filter=search.ismatchscoring('ミルクティ')

このismatchscoring関数ですが、そのほかにも引数の指定が可能で、省略した場合にデフォルトで採用される値がいくつかあります。公式のドキュメントにパラメータの意味が掲載されています。

今回は、第4引数のsearchModeの値が問題点です。デフォルトでは、anyが指定されます。この、anyは検索語（今回はミルクティ）の任意の検索語句が一致する必要があることになります。「検索語句」？なんでしょう？これが、ここまで回り道をして説明してきた、Analyzerの出力した単語になります。「ミルクティ」はNGram（N=2）のAnalyzerを通すと、

「ミル」「ルク」「クテ」「ティ」

という4つの単語が出力されます。これが、「検索語句」です。「任意の」とあるので、上記4つの2文字のどれか？が出現すれば検索条件にヒットしたこととなります。

ですので、以下のように（一部のみ色を変えてます）3つの文章にはそれぞれの文字が含まれているため、先ほどの条件では3件の結果が返ってくることになります。

ミルクティを飲みたいです。
マティーニはカクテルですが、ミルクセーキは？
風呂上がりのミルクは最高です。

NGramで一部分の単語だけで一致したものがヒットしてしまうと違和感があるので、allに変更します。

$filter=search.ismatchscoring('ミルクティ', 'body', 'simple', 'all')

今度はどうなるでしょう？

ミルクティを飲みたいです。
マティーニはカクテルですが、ミルクセーキは？

先ほどよりもマシになりました。 3がヒットしなくなっています。3の文章には「ティ」などが出てこないためです。ただ、感覚的に2番目がヒットするのは少し違和感がありますよね？確かに4つの単語がすべて出てきていますが、「ミルクティ」とは少し遠いです。

さらに「ミルクティ」にヒットさせるにはフレーズ検索にする必要があります。 Elastic社のブログの日本語の検索に関する記事でも出てきますが、フレーズで検索することで「ミルクティ」だけにヒットさせることができます。

「フレーズ検索＝語順を保証する検索」となります。ですので、

「ミル」「ルク」「クテ」「ティ」

この順序で出てきた場合のみ、検索にヒットしたことになります。 OData式でフレーズ検索する場合は、単語をダブルクォート"でくくる必要があります（公式ドキュメントの例に記載あり）。

$filter=search.ismatchscoring('"ミルクティ"', 'body', 'simple', 'all')

これで結果は以下の1件だけとなります。

ミルクティを飲みたいです。

これでNGramで部分一致のような挙動で日本語の検索ができるようになりました。

ちなみに、フレーズにした場合は第4引数はanyに変更しても1件だけの検索結果となります。フレーズ検索には「すべての語が含まれる」、「すべての語が順番に現れる」という2つの条件が含まれるためです。

$filter=search.ismatchscoring('"ミルクティ"', 'body', 'simple', 'any')

この例の引数をミルクティを"ミルク" "最高"のような検索条件に変えた場合、「“ミルク”」「“最高”」の2つの条件をanyで扱うため、「“ミルク”」「“最高”」のどちらかが出てくれば良い結果となり、3件の結果が返ってきます。第4引数をallに変更すると、「“ミルク”」「“最高”」の両方が出てこなければならないため、3件目のデータのみが返ってきます。

$filter=search.ismatchscoring('"ミルクティ" "最高"', 'body', 'simple', 'all')

これは、

$filter=search.ismatchscoring('"ミルクティ"', 'body', 'simple', 'any') and search.ismatchscoring('"最高"', 'body', 'simple', 'any')

と同じ意味となります。少し長くはなりますが、後者の書き方をプログラムで書くと思います、私の場合は。検索窓に入力された単語に必ず"を追加する処理を書くために、画面入力の文字列を一旦パースをすることになるからです。

まとめ

簡単？にですが、OData式でのフルテキスト検索と、NGramでのフレーズ検索について説明しました。英語の場合、もともとスペースで区切られているので、フレーズといわれてピンときますが、日本語の場合はAnalyzerの挙動をわかっていないと「？」となるかと思います。なぜフレーズ検索が必要なのか？というのが少しでもわかっていただければと。ちなみに、NGramのTokenizerには別の落とし穴もありますが、その話はまた後日にでも。

参考として日本語関連の検索に関する記事のリンクを残しておきます。

参考

Elasticsearch日本語でフレーズ検索が必要なわけ
NGramも含め、Elasticsearchでの日本語の検索の設定やクエリについては、Elastic社のブログで日本語で書かれた記事が詳しいのでこちらをご覧いただくのがいいです。

自宅の作業環境(2021/02)

Thu, 25 Feb 2021 18:43:02 +0900

自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。前回のブログ(2020/09)、前々回のブログ(2020/03)はそれぞれリンクをたどってください。

現状のデスクトップはこんな感じ

PC

別のブログにまとめましたが、Windowsメインに切り替えました。ハードの話以外に、Windows OSに切り替えたときにいくつか入れたものもあります。それは、移行のブログに少しだけ書いてあります。

ひさびさにWindowsに戻ってきていますが、だいぶ慣れました。まぁ、それほど大したことをやってないというのもあるかもですが。。。

メインPC以外にこれまでのmacをブラウジング用にサブディスプレイにつなぎ、マウスをLogicool Flowで行き来できるようにし、キーボードはKVMスイッチで切り替えてやりくりしていました（最新環境はキーボードのところを参照してください）。

Amazon | サンワダイレクト USB切替器キーボード・マウス用 KVMスイッチ

キーボード

いくつかDIYしましたが、今はメインでSofle Keyboard v2を利用しています（Kochi Keyboardさんで購入できます）

Sofle keyboard v2を有線で使っていましたが、最近Bluetooth対応して無線化しました（その時のブログはこちら）。ですので、PCとの接続の切り替えはキーボード上で特定のキーの組み合わせを押すことで、切り替えられるようになっています。 KVMとは異なり、Bluetoothの接続が切り替わるのにタイムラグがある＋どこにつながっているのか？というのがわからないので、想定していないところでキーが入力されていることがあります。これは、何とかしたいかもなぁと考えてはいるところ。

マイク＆オーディオインターフェース

基本的に自宅でリモート作業をしています（ありがとうございます）。なので、ミーティングもオンラインです。となるとやはり、音がいいほうがお客さんにも喜ばれるかなぁと。 2020年3月時点ではSAMSONのGoMicを利用していました。これもいい音なのですが、大きいマイクでもいいかなと。あとは、ほかの使い道もあるかも？ということで、オーディオテクニカのマイク（＋ポップガード）とフォーカスライトのオーディオインターフェースに変えてみました。自分は実感ないですが、きっと役に立っていると思いますｗ

Amazon | audio-technica サイドアドレスコンデンサーマイクロホン AT2050 | コンデンサ | 楽器

Amazon | AUDIO-TECHNICA AT-PF2 ポップフィルター | マイクアクセサリ | 楽器

Amazon | Focusrite フォーカスライトオーディオインターフェイス 2イン/2アウト 24bit/192kHz Scarlett Solo (3rd Gen) ステッカー付きセット【国内正規品】 | 楽器・音響機器 | 楽器

ディスプレイ

以前は、MacBookProの16インチで、メインディスプレイの下に2枚目のディスプレイも兼ねて開いて利用していました（前回のブログ参照）。自作PCに切り替えたので、ディスプレイがなくなってしまうので、同じような大きさのモバイルモニターを利用しています。今のところは据え置きになっていますが、持ち運べるので、ほかの部屋や外出時にも使えるんではないかなと。ディスプレイの足などはないので、邪魔にもならず便利ですね。

Amazon | モバイルモニターモバイルディスプレイ 4K 15.6インチ cocoparスイッチ用モニター非光沢IPSパネル薄い軽量HDRモード/FreeSync対応/ブルーライト機能 3840x2160 UHD/USB Type-C/標準HDMI/mini DP/カバー付3年保証付 | cocopar | ディスプレイ通販

音楽再生環境

サブディスプレイにサンダーボルトディスプレイを使用していたので、Mac Miniを接続していましたがサンダーボルトディスプレイには退役してもらいました。それに伴って、Mac Miniも別の場所に移動しました。音楽再生環境にラズパイ４を復活させました。以前購入したセットについていたケースではファンの音が気になっていたので、ヒートシンク型に変えました。結構重いですが、冷えてそうです。

Amazon | Geekworm Raspberry Pi(ラズベリーパイ) 4 B 用アーマー金属ケースパッシブ冷却/シェル熱放散ラズベリーパイ4 コンピュータモデルB適用 (アーマーケース（ファン無し）) | Geekworm | 冷却パーツ・ファン通販

Webカメラ

カメラ自体に変更はないですが、付属品をいくつか。 Webカメラではないカメラもつけてみたいなと思い、モニターアームにカメラを付けられるものを付けてみました。ただ、おっさんの顔をきれいに映してもなぁという結論に至ったので、Webカメラが乗っかっています。。。あとは、デスクトップPCになり、カメラのケーブルだけではPCまで届かなくなってしまったのでUSB Type-Cの延長コードを買ってみました。実はこれ2本目ですが。。。スタンディングデスクの昇降でケーブルに負荷がかかってしまったことがなんどかあり、1本目の延長コードは接触が悪くなってしまいました。。。時々外したりしていて、ケーブルの配置がおかしいときがあるので、気を付けるようにしています。

Amazon | 長尾製作所モニターアーム用 VESA カメラ＆マイクマウント NB-MV001MH | 長尾製作所 | モニタアーム&スタンド通販

Amazon | iVANKY USB Type C 延長ケーブル USB 3.1 Gen 2(4K@60Hz/1.0m/オス－メス)10Gbps高速データ転送 3A急速充電 usb-c 変換 Huawei MateBook13, iPad Pro11, Nintendo Switch, MacBook等対応 | IVANKY | USBケーブル通販

照明

裸の蛍光管だったのですが、リモコンで点灯したり、照度を変えられるようにしたかったので、パナソニックの照明に変えました。

Amazon | パナソニック LEDシーリングライト調光・調色タイプリモコン付 6畳 3, 699lm HH-CD0620AZ 【Amazon.co.jp限定】 | パナソニック(Panasonic) | ホーム＆キッチン

変えたのはよかったのですが、部屋が長細い＋Webカメラの位置（自分から見て左にカメラを置いて、部屋の奥への画角？になっている）のせいで、右半分の顔が暗くなる場合がありました。幸い、右にはスチールラックが組んであるので、そこにつけられる照明を購入して女優ライトみたいな感じで使っています（頻繁ではないですが）

Amazon｜ルミナスメタルラック用 LEDライト磁石で簡単設置連結可能幅60cm 昼白色 LED60R-N｜メタルラックパーツオンライン通販

フットレスト

昨年3月くらいに配置して、座っているときに足を置くのに便利に使っていました。が、1台だと幅が足りないので最近2つ目を購入して並べて使っています。片足ずつ載せられるのは便利ですね（基本ガニ股なので。。。）。

Amazon | サンワダイレクトフットレストスチール製角度10° 幅40×奥行30cm 足置き台 100-FR011 | フットレスト | 文房具・オフィス用品

ということで、最近はこんな環境で仕事をしています。当分これで更新しないんじゃないかなぁ。（サブディスプレイが左に寄っているので、局面ディスプレイが気になっているところですが。。。）

Azure Cognitive Searchでオートコンプリートやサジェストをしてみる

Fri, 05 Feb 2021 17:52:00 +0900

Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。

公式ドキュメント

日本語で公式ドキュメントが公開されています。使い方や流れについてはこちらをまずは見れば使えると思います。

本ブログでは、ざっくりとした機能の紹介と内部がどんな挙動をしていそうか？、日本語だとどういう感じになるのか？という点を紹介しようと思います。

どんな機能？

検索窓でよく、キーワードを入力しているときに検索キーワードの候補が表示されることがあります。このキーワードの候補を表示するための機能が今回紹介するSuggesterと呼ばれる機能です（日本語の公式ドキュメントでは「先行入力エクスペリエンス」）。 Suggesterには、以下の2つの機能が用意されています。

Autocomplete：キー入力しているときに、入力されている文字列で始まる単語で、検索できるもの（転置インデックスに登録されている単語）をリストで返す機能
Suggestion：入力した文字列で始まるキーワードを含む、元のデータを返す機能

利用方法

Suggesterの機能を利用するにはインデックスに設定を追加する必要があります（新規、既存どちらでも可）。ただ、既存のインデックスに設定を追加した場合、内部にすでに存在するドキュメント（データ）については、このSuggesterのデータは作られません。ですので、既存データを再度登録しなおすといった作業が必要となるので注意が必要です。

本ブログでは、いくつかAzure Cognitive Searchのサンプルのリクエストが出てきます。Visual Studio CodeのREST Client Extensionの書式となります。拡張機能の簡単な紹介は昨年のブログをご覧ください。

設定編

Suggesterの設定では、主に以下の2つを設定する必要があります。

name: suggesterの名称。クエリ時に指定します。
sourceFields: 入力データのもととなるフィールド名。
- String型のみ指定可能。また、Azureで用意されたアナライザーだけが利用可能です。自分で用意するカスタムアナライザーは利用できないので注意が必要です（制限についてはこちら）。

今回使用するサンプルのインデックス設定は次の通りです。

インデックス作成のリクエスト（@host、@api-keyはご自身のものに置き換えてください。）

## 設定
@host = 名前.search.windows.netと記載
@api-key = APIキーを入力

### Create index with suggester
POST https://{{host}}/indexes/?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
    "name":"suggester-test",
    "fields":[
       {
          "name":"id",
          "type":"Edm.String",
          "key":true,
          "searchable":false
       },
       {
          "name":"name",
          "type":"Edm.String",
          "searchable":true,
          "analyzer":"ngram_analyzer"
       },       
       {
          "name":"category",
          "type":"Edm.String",
          "filterable":true,
          "facetable": true
       }
    ],
    "suggesters": [
       {
          "name": "name_suggester",
          "searchMode": "analyzingInfixMatching",
          "sourceFields": [
             "name"
          ]
       }
    ]
}

公式ドキュメントのサンプルでは日本語がないので、日本語のデータも入力しています。

データ登録リクエスト

### Index data
POST https://{{host}}/indexes/suggester-test/docs/index?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
  "value": [
    {          
      "@search.action": "upload",  
      "id": "1",
      "name": "Microsoft Office",
      "category": "microsoft"
    },
    {          
      "@search.action": "upload",  
      "id": "2",
      "name": "Microsoft Azure",
      "category": "microsoft"
    },
    {          
      "@search.action": "upload",  
      "id": "3",
      "name": "GitHub Enterprise",
      "category": "github"
    },
    {          
      "@search.action": "upload",  
      "id": "4",
      "name": "GitHub dot com",
      "category": "github"
    },
    {          
      "@search.action": "upload",  
      "id": "5",
      "name": "Bluetooth Mic",
      "category": "hardware"
    },
    {          
      "@search.action": "upload",  
      "id": "6",
      "name": "東京スカイツリー",
      "category": "japanese"
    },
    {          
      "@search.action": "upload",  
      "id": "7",
      "name": "東京タワー",
      "category": "japanese"
    },
    {          
      "@search.action": "upload",  
      "id": "8",
      "name": "東京特許許可局",
      "category": "japanese"
    },
    {          
      "@search.action": "upload",  
      "id": "9",
      "name": "グランメゾン東京",
      "category": "japanese"

    },
    {          
      "@search.action": "upload",  
      "id": "10",
      "name": "東京都庁",
      "category": "japanese"
    }
  ]
}

以上が事前準備です。データ登録時に内部でSuggester用のデータを内部で生成しているようです（公式ドキュメント）。

クエリ編

最初に説明しましたが、Suggesterの中ではAutocompleteとSuggestionという2種類の機能が用意されています。それぞれについて例をもとに説明していきます。

Autocomplete API

検索窓に入力された文字を元に、前方一致でどのような単語で検索できるか？という候補を表示するための機能です（2単語も対応していますが今回は省略。APIの仕様はこちら）。

たとえば、micという文字が入力されているところでAutocomplete APIを呼び出す時は、次のようなリクエストです。searchというパラメータに入力値を与えます。suggesterNameはインデックス作成時につけた名前になります。

POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "search": "mic",
   "suggesterName": "name_suggester"
}

レスポンスとして、次のようなJSONが返ってきます。

{
  "@odata.context": "...",
  "value": [
    {
      "text": "microsoft",
      "queryPlusText": "microsoft"
    },
    {
      "text": "mic",
      "queryPlusText": "mic"
    }
  ]
}

サンプルデータとして登録したデータにcategoryというフィールドを入れていました。 Autocompleteは条件を絞り込んで結果を返すこともできます。 filterにODataの書式で条件を書けます。 categoryフィールドにmicrosoftが設定されているデータだけを取得するということができます。

### Autocomplete with filter
POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "search": "mic",
   "suggesterName": "name_suggester",
   "filter": "category eq 'microsoft'"
}

レスポンスはこちら。先ほどとは違い、micというデータは返ってきていません。

{
  "@odata.context": "...",
  "value": [
    {
      "text": "microsoft",
      "queryPlusText": "microsoft"
    }
  ]
}

英語の場合、「単語」の単位は字面の通りです。スペースで単語が区切られているのでわかりやすいです。日本語の場合は普通の人には少し想像しにくいです。 東京という文字を入力してみます。

### Autocomplete in Japanese
POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "search": "東京",
   "suggesterName": "name_suggester"
}

すると返ってくるのは以下の通り「東京」だけになります。

{
  "@odata.context": "...",
  "value": [
    {
      "text": "東京",
      "queryPlusText": "東京"
    }
  ]
}

入っているデータは「東京スカイツリー」、「東京タワー」などです。普通に考えると、これらがそのまま返ってくると思うかもしれませんが、違います。

これは、Suggesterの元となるフィールドのAnalyzerの挙動によります。今回のインデックスのnameフィールドのanalyzerにはja.luceneです。これは、日本語用のアナライザー（Kuromoji）になります。いわゆる形態素解析器で日本語の文字列を「単語」に分割します。英語についてはスペース区切りで分割しますが、日本語についてはKuromojiが内部の辞書とアルゴリズムに基づいて単語に分割してくれます。 Azure Cognitive Searchでは、Analyzerの挙動を確認するためのAPIも用意してあるので実行しみると、

### Autocomplete in Japanese
POST https://{{host}}/indexes/suggester-test/analyze?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "text": "東京スカイツリー",
   "analyzer": "ja.lucene"
}

このような結果が返ってきます。

{
  "@odata.context": "...",
  "tokens": [
    {
      "token": "東京",
      "startOffset": 0,
      "endOffset": 2,
      "position": 0
    },
    {
      "token": "スカイ",
      "startOffset": 2,
      "endOffset": 5,
      "position": 1
    },
    {
      "token": "ツリー",
      "startOffset": 5,
      "endOffset": 8,
      "position": 2
    }
  ]
}

ja.luceneのAnalyzerによって、3つの単語に分割されているのがわかります。 Autocomplete APIの実行結果も、このAnalyzerによって分割された単語をもとに、候補となる単語を前方一致で検索して結果を返しているのです。ですので、「東」と入れても「東京」が返ってくるのがわかります。一方で、「東京ス」と入力した場合は次のような結果となります。

{
  "@odata.context": "...",
  "value": [
    {
      "text": "スカイ",
      "queryPlusText": "東京スカイ"
    }
  ]
}

これは、autocompleteModeと呼ばれるパラメータの挙動となります。デフォルトでは、oneTermという設定で、最後の単語（例の「東京ス」の場合は「東京」「ス」と区切られるので「ス」という文字を単語とみなす）にマッチする単語（例では「スカイ」）が返ってきます。 queryPlusTextについては、入力された文字にtextで返ってきた単語をくっつけたものが取得できます。

英語であれば、スペースで区切られており、単語が切れているのが簡単にイメージできますが、日本語の場合は少し違和感が出るかと。

このように、入力された文字が含まれる「単語」を基本的に返す動作をするのがAutocomplete APIです。

Suggest API

では、もうひとつのSuggest APIはどういったものでしょうか？ autocomplete APIに似ていますが、返ってくるデータが登録されたデータそのものになります。

たとえば、micという文字列を入力とした場合、

POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "search": "mic",
   "suggesterName": "name_suggester"
}

次のような結果が返ってきます。Autocompleteの時は単語でしたが、こちらは入力データがそのまま返ってきています。入力データの中にmicで始まる単語が含まれたものが候補となっています。

{
  "@odata.context": "...",
  "value": [
    {
      "@search.text": "Bluetooth Mic",
      "id": "5"
    },
    {
      "@search.text": "Microsoft Office",
      "id": "1"
    },
    {
      "@search.text": "Microsoft Azure",
      "id": "2"
    }
  ]
}

日本語の場合、Autocompleteとは異なり、その単語を含むものがサジェストされるので、「東京」をsearchに指定すると「東京」を含むデータが出てきます。

### Suggest in Japanese
POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "search": "東京",
   "suggesterName": "name_suggester"
}

レスポンスはこちら。単語を含む元の文字列が返ってきます。ここまでは違和感はありません。

{
  "@odata.context": "...",
  "value": [
    {
      "@search.text": "東京タワー",
      "id": "7"
    },
    {
      "@search.text": "グランメゾン東京",
      "id": "9"
    },
    {
      "@search.text": "東京都庁",
      "id": "10"
    },
    {
      "@search.text": "東京スカイツリー",
      "id": "6"
    },
    {
      "@search.text": "東京特許許可局",
      "id": "8"
    }
  ]
}

では、「東京」「特許」という2つの単語をスペースで区切ったものが入力されたとするとどうでしょう？

### Suggest in Japanese
POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "search": "東京 特許",
   "suggesterName": "name_suggester"
}

スペースがありますが、内部処理では形態素解析器が分割した後でこの単語の順番で出てくるものを探しているので、出てくることになります。

{
  "@odata.context": "...",
  "value": [
    {
      "@search.text": "東京特許許可局",
      "id": "8"
    }
  ]
}

なお、このSuggestのAPIは、単語の語順を気を付ける必要があります。「特許」「東京」と順序を入れ替えたスペース区切りの場合は、

### Suggest in Japanese
POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30
Content-Type: application/json
api-key: {{api-key}}

{
   "search": "特許 東京",
   "suggesterName": "name_suggester"
}

結果は返ってこないです。おそらく内部では、フレーズクエリで、最後の単語だけを前方一致で検索するような仕組みが動いているのだと思われます。スペースで区切られてはいるが、順序があるので少し違和感を感じるかもしれません。英語だとフレーズの部分のイメージは沸きやすいのですが。

短い文章のデータ（例：本のタイトルやランドマーク名など）では、このSuggestAPIを利用するとデータそのものが返却されるので、便利かもしれません。

まとめ

ということで、Azure Cognitive SearchのSuggesterの簡単な紹介でした。APIのページにはそのほかのパラメータについても説明があるので、使ってみようと思う方は目を通していただくのがよいかと。

今回のブログは裏の仕組みがどんな感じなのか？を想像しながらAPIについて調べた形になります。日本語の場合に、少し違和感を覚える人もいそうだろうなということでブログを書いてみました。今回は書いていませんが日本語でAutocompleteをやりたい場合は、読み仮名でも漢字が表示されるほうがよいという場合もあると思います。その場合は、用意されている機能では難しいので、独自実装するといった方法になりそうです。英語や、読みを利用しない場合は、挙動を理解していれば役に立つ場面もありそうです。

「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris

Thu, 04 Feb 2021 16:40:44 +0900

オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。

原著はオライリーじゃないのかというのが、まず最初の気づきでした。

NANDからテトリス

コンピュータのハードウェアからOS、さらにその上で動くアプリケーションまでを動作させるというのを少しずつやっていくという書籍みたいです。イントロと1章を読みましたが、1章では論理回路の話でした。

実際に物理的に作るわけではなく、シミュレーターなどのソフトウェアが用意されており、そのソフトウェア上で動くものを作っていくことになります。ソフトウェアのために専用のサイトが用意されて、ダウンロードもできるようになっているので、実際に手を動かしながら理解を進める感じになるのかと。

目次を見ていただくとわかりますが、すごく幅が広いです。 1年で読み終われるかなぁ？まぁ、のんびりやっていこうかなと。

用意されているソフトウェアなどで便利だなと思ったのは、どの章からでも興味のある部分から始められるようになっているようです（まだ始めてなくて。。。）内部ではすべてのパーツがそろえてあるけど、章ごとのプロジェクトでは、個別に自分で実装したものがあればそちらが動くという挙動のようです。

ということで、ちょっとずつやっていこうかなと。ほんとにテトリス動くのかなぁ？

Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード

Mon, 01 Feb 2021 00:15:22 +0900

Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。そこに、Kochi KeyboardさんからSofle Keyboard v2というのが発売されたので組み立ててみました（去年末に）。また、先日Corne Light v2のBLE化に成功したので、Sofle keyboard v2のBLE Pro Micro + LPME-IO化にもチャレンジしてみました。

Sofle keyboard v2 ビルドログ

自分で書くよりもすごくよくできたビルドログがKochi Keyboardさんで公開されているので、そちらを参考にしてください。

Sofle Keyboard v2ビルドガイド

すごく詳しく書いてあります。なので、こちらを見ていただければ問題ないかなと。ただ、自分ではいくつか失敗したので自戒を込めてログを残しておきます。

OLED用のジャンパをはんだ付けし忘れ

単にビルドログを流し読みしたツケが。。。 Sofleは同じ基盤を左右で利用します。なので、右手と左手で、同じ基盤の表と裏を利用します。 OLED用のジャンパする部分は両面に用意されていますが、はんだでジャンプするのはPro Microが実装される面となります。

両面にジャンプ用のランドがあるとは気づかないで、左手の裏面をジャンプしてすべて実装し終わってから、OLEDが表示されないことに気づいてしまいました（ビルドログ用にと思って撮った写真に証拠が残ってますねｗ）。。。

ということで、またはんダッシュ太郎くんのお世話になりました（Pro Microを外してジャンプしました）。本当に有能ですよ彼は。。。

Amazon | サンハヤトはんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ

ソケットのはんだ付け甘すぎ

あとは、慣れてきたなぁと思っていたところに天罰が。キースイッチのソケットを付けるの慣れてきたなーと思って、サクサクとつけていたのですが、いざキースイッチをはめるときにボロボロとはがれていきましたｗ半分くらいは外れたんじゃないかな？ちゃんとはんだ付けした後にピンセットなどで軽くいじってみるべきですね。。。

滑り止め

利用しているキーキャップがOEMプロファイルということもあり、数字キー側を少し高くしたほうが入力しやすいです。そのために、少し大きめのソフトクッションを購入しました。

Amazon | WAKI ソフトクッションCN-020 クリアータイプ: 産業・研究開発用品

上の左右の角に貼り付けると、がたつきがあったので少しずらして貼り付けて安定させています。 OLEDのプレートの部分を押すと手前が浮き上がってしまいますが、そこにはキーはないので問題ないかと。

ということで、毎回気づきがあって面白いですね。。。

Sofle keyboardのBLE化

Corne LightのBLE化がうまくいったので、もうひとセットのぎけす屋さんから購入しました。 BLE Micro ProやLPME-IO、電池基盤などについては前回のCorneのBLE化の記事を参照してください。

ハードウェア編

Sofle keyboard v2は残念ながらせきごんさんの公式ページの対応キーボード一覧には掲載されていません。が、Sofle KeyboardのGitHubのページには次のような記載があります。

Sofle is 6×4+5 keys column-staggered split keyboard with encoder support. Based on Lily58, Corne and Helix keyboards.

基盤の写真のPro Micro周りもCorneに似ています。ということで、おそらくBLE + LPME-IO化が行けるのでは？と予測して作業に取り掛かりました。

PCBの確認

Sofle Keyboardの基盤の設計図はGitHub上に公開されています。この設計図を見る方法をまずは探しました。

自作キーボードについて探すにはまずはサリチル酸さんのブログ「自作キーボード温泉街の歩き方」です。回路図なので、設計ノウハウあたりのカテゴリーにあるだろうと探したところ見つかりました。

（設計者向け）オートルーターを使って睡眠時間を確保しよう

配線のテクニックというブログですが、回路図を書くためのツールKiCadについて記載があります。このブログにある以下の記事をもとに、KiCadのインストールや使い方をちょっとだけ勉強しました。

foostanさんのMeishi Keyboardの開発者向けガイド(JP)
KiCadことはじめ

KiCadの中の回路図エディタ「Eeschema」でSofle keyboardのPCBのフォルダを開くと回路図が開きます。実際の基盤になる前に、Pro Microのどの足と何がつながっているのか？などが見て取れます。前回のCorneのBLE化でLPME-IO対応したときに、学習しましたが、 TRRSの足とPro MicroのSDAとSCLをつなぐことで、LPME-IOを使うことができるようになるというのがわかっています。それをもとに回路図を見たところ、以下のような記述がありました。

どうも、JP9とJP10というはんだでジャンプする場所を用意してくれていそうです。先を見越した設計本当にありがたいですね。

JP9とJP10のはんだ付け

今ついているPro Microを外し（またはんダッシュ太郎が活躍）、基板を確認したところ対象の個所がありました。下の写真は左手の裏側です。

これらをはんだでジャンプします。

右手は表側にあるので、Pro Microを外した後にジャンプしました。

左手は裏側です。

Corne Lightでは、Pro Microの足から導線を使ってTRRSの足につなぎましたが、今回はすっきり実装できました。ジャンプした後はBLE Micro Proをはんだ付けします（はんだ付けせずに動作確認しようとしましたが、うまく通電しなくてちゃんと動かなかったです）。

LPME-IOのジャンパ

LPME-IOのGitHubページにあるように、利用するキーボードによって、いくつかはんだでジャンプする必要があります。これは、BLE Micro Pro用のConfigファイルを見て、対象を決める必要があります。が、Sofleは事前に用意されたものがありません。

Configファイルの生成

用意されていないConfigファイルが、QMKの設定ファイルから生成することができるようななっています（本当に感謝しかないですね）。手順はBLE Micro Proのドキュメントにありました。

新しいキーボード用の設定を作成する - QMK用の設定から変換する

この変換スクリプトで３種類のconfig（右手用、左手用、LPME-IO用）が生成されます。私の場合はLPMEを利用するので、lpmeという名前の入ったconfigを利用します。中を見るとcol以下の記載が以下の通りだったので、8からDをジャンプします。

"col_pins":[18, 17, 16, 15, 14, 13, 18, 17, 16, 15, 14, 13],

ここまででハードウェア側が終了です。

ファームウェア・設定編

ハードウェアの実装が終わったので、ファームウェアおよびアプリの設定です。

ファームウェアのセットアップ

キーボードをUSBで接続し、BLE Micro Pro Web Configuratorのページにアクセスすると、セットアップ初期画面が出てきます。

公式ページの「キーボードを選ぶ」を参考にファームウェア、アプリのアップデートを行います。「設定ファイルの書き込み」のタイミングでupload your ownを選択すると、ファイル選択画面が出てくるので、変換スクリプトで生成したJSONファイルを選択します。このとき、Mas Storage Classとしてキーボードが認識されている状態だとうまく書き込めなかったので、キーボードのドライブを「取り出し」してからファイルをアップロードしました。

キーマップの設定

BLE Micro Proのアプリが設定をきちんと認識すれば、あとはWeb Configuratorでキーマップの設定が可能になります。これまた、残念なことに、BLE化する前のキーマップをJSONファイルで保存してなかったので（泣きそうｗ）、QMKのkeymap.cのファイルをもとに、ブラウザ上でがんばって設定しましたｗまた、新しい設定ではBLE関連のキーをマッピングとして追加しています。

Bluetooth接続

あとは、接続確認です。 MacとWin２台と接続するのですが、Win→Mac→Winの順番でBluetoothの接続をやっていたら、なぜか３つ目のWindowsで接続候補に出てくるけど、接続しようとするとタイムアウトをするという現象に遭遇しました。 MacのBluetoothの設定を一旦削除してから、Win→Win→Macの順番でペアリングしたところ問題なく接続できました。ただ、これが本当の対処なのかどうかは不明です。３番目だと接続できなかったWindowsマシンは再起動もしてみたのですがダメでした。この辺よくわかってないなぁ。

まとめ

ということで、Corne Lightに引き続き、Sofle Keyboard v2もBLE＋LPME化に成功しました。導線なども使わずにLPME対応ができたので見た目もすっきりしています。これで、KVMスイッチだと２台までしか切り替えできなかったのが、３台をひとつのキーボードで操ることができるようになりました。だいぶ楽になりそうな予感がしています。

まだ、完ぺきではないので、次のような対応をやっていく予定です。

ロータリーエンコーダー対応：BLE以前はQMKのkeymap.cの中でロータリーエンコーダーの動作を記述していたので、BLE Micro Proでどうやるのかを調べたい。encorder.jsonというファイルがあったのでその辺ではないかな？
OLED対応：Corne Lightの時と同様に、OLEDが点かなくなったのでこの辺りを調べたい。

ということで、とりあえずキー入力するのには困らない程度にはできたので、より便利にする方法を時間を見つけて模索する感じになりそうです。あと、KiCadも面白そうなのでこっちもちょっと触ってみたくなってきたかも？

Corne Light v2のBLE+LPME-IO対応 #DIYキーボード

Mon, 11 Jan 2021 11:42:31 +0900

メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne（初めてのDIYキーボード）が長いUSBケーブルでつながっています。

Amazon | サンワダイレクト USB切替器キーボード・マウス用 KVMスイッチ

時々必要になって、デスクにキーボードだけ引っ張ってきて利用するのですが、ケーブルの取り回しがまぁ邪魔で。。。 BLE対応（BLE Micro Pro）をしてみようかなということに。

BLE + LPME-IO対応

分割キーボードをBLE対応(それぞれにBLE Micro Proを実装)すると、キーボード間のつながりがいまいちになることもあるというのをちらほら見ていたので、BLE Micro Pro + LPME-IOという構成で、 Corneのキーボード同士はTRRSケーブルで接続し、PCとCorne間をBluetoothで接続する構成にしてみました。

BLE Micro Proについては、公式ドキュメントにいろいろと記載があります。

材料

ということで、材料は以下の通り。セット販売は売り切れていたので、個別に購入しました。コンスルーと電池以外は１つずつです。

実装

まずは、それぞれ組み立てです。

電池基盤

以下の記事を参考にはんだ付けしました。

注意点は以下の通りです。

基盤が軽いので固定が必要（マスキングテープでマットに貼り付けたらましになった）
電池ホルダーが変形しやすい（設置して、足を折るために上から押さえつけたら、本体が曲がってしまった。。。）
部品が細かいので大変（老眼だから？）

BLE Micro Proとの接続は参考にしたyfuku docsにある方法（余っていたピンヘッダを１本ずつ使ってはんだ付け）を採用しました。（パッと見大丈夫そうだったので電池基盤の裏に絶縁テープは貼ってないです貼ってないです）

BLE Micro Pro（もげ対策）

BLE Micro Pro自体はコンスルーをはんだ付けするだけですが、今回はもげ対策として、ダイソーで買ってきたグルーガンでちょっとだけ補強してみました。初グルーガンだったので不細工だけど。これ難しいな。

効き目あればいいけど？

LPME-IO対応

いくつかのジャンパをはんだでブリッジ

まずは、LPME-IOのREADMEのページの導入手順を読み、いくつかのピンをジャンプしました。せきごんさんのBLE-Micro-Proのリポジトリに、CorneのLPME用コンフィグファイルを見ると、ジャンプするのは20, 19, 18, 17, 16, 15に対応している、F,E,D,C,B,Aの６つです（写真撮り忘れた。。。）。

TRRSのI2C対応（って言い方であってるのかなぁ？）

ジャンプだけでいけないかなぁ？と思いましたがダメでした（USBでつないでみたけど、左手（BLE-Micro-Proがついている側）だけ入力可能です。

BLE Micro Proの公式サイトにLPME-IOについても記載があります。実績のあるキーボード一覧にCorne Lightの記載もあったので、試してみようと思ったのが発端です。

ただ、LPME-IOの欄に注意書きが。

*LPME-IOを使うには改造が必要

また、一覧の最初にも記載があります。

LPME-IOを使うにはキーボードの左右の有線通信がI2Cである必要があります。とくにOLEDに対応しているキーボード等の場合は、I2C用のピンをTRRSジャックに接続する改造を施すことでI2C化できる場合があります。

まだ、自作キーボードの仕組みをがっつり理解しているわけではない初心者なので、まぁ、ちょっとわからないかなと。。。 BLE Micro Proのはじめにのページを見ると、 Self Made keyboard in JapanのDiscordに専用チャネルがあるようで、過去ログを検索してみました。検索したところ、Corneの場合Micro ProのSDA(写真の青い線)とSCL(写真の黄色い線)（参考：Corneの基盤の図）をそれぞれ、TRRSの２つのピンに接続する必要がありそうだというコメントがありました。

Corne Cherry v2の場合は、接続するためのショートカットが用意されていましたが、Corne Light v2だと見当たりませんでした。ということで、線を使って物理ショートカットしました。ちなみに、ショートカットは両手ともに必要なようです。

USB-Cで接続テスト

上記対応が終わって、基板に設置してUSB-Cケーブルで接続したところ、外部ドライブとして見えるようになりました。

キーマップの書き換えとか

公式ドキュメントのBLE Micro Pro Web Configuratorを使うの手順通りに書き込みを行っていくと、特に問題なく接続できました。便利すぎですね。キーマップの変更は、これまでのCorneのキーマップJSONファイルからコピペして書き込んだだけです。（この後、BLE用のキーマップを書き足すためにもう一度変更しますが）

LPME-IO対応なので、Micro Proは片側しかないので、書き換えも楽々でした。

BLEで接続テスト

今回の目的だったWindowsにBluetoothで接続できるようにしてみました。最初はサリチル酸さんの記事を見ていたのですが、キーコードがちょっと変わっているようでした。

で、よくよく見ると、BLE Micro Pro Web ConfiguratorにBLE関連のキーも用意されているじゃないですか。。。

BLE関連のキーを割り当てた後は、USBをオフにして、Bluetoothをオン、BTNEWで新しくペアリングするようにすれば接続完了でした。

課題

これまでと違い、すんなり実装ができましたがまだいくつか気になる点が。

複数の機器とペアリングして切り替え
- Macともペアリングしてみようとしたのですが、切り替えがうまくいかないようで。。。
OLEDつけるにはどうするんだろう？
- 左手側は電池が乗っているのですが、右手側はLPME-IOだけなので、上にOLEDを載せる余裕があります。
- なので載せてみましたが点かないですね。ファームウェアを何かしないといけないんじゃないかな？調べないとなぁ。

という感じです。まだちゃんと長時間使っていないので、他の問題点も出てくるかもしれませんが、まぁとりあえず使ってみてからかな。うまくいくようなら、メインマシンにBluetoothモジュール追加してみるのもありかと考えているところです。

調べながら、自分なりに対応してみましたが他にもいい方法とかあれば教えてもらえると助かります。

PCもDIYしました

Thu, 31 Dec 2020 22:48:46 +0900

振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。組み立てたに使ったパーツのアフィリンクを貼っておきます。

10月くらいにPC組もうと思って、組み上がったのは11月半ばでした。最初はもうちょっと小さいPCにしようと思ってたのに気づいたらATXになってました。パーツの選定の基準は以下のツイートです。影響されやすいなぁ。

タワーってほど大きくなくていいと思いますが、NZXT H510 ぐらいの大きさは欲しいですね。https://t.co/s1c1fOnPyI
単純に、スペースがないと組みにくいのと冷えにくい、買ってきたものがやっぱりこれだと入らない、というリスクがかなり減るので。
— さぼてん（さぼ福）🌵 (@cactusman) October 9, 2020

今年3台作りました。ノートPC使えない体になります。 pic.twitter.com/8zDmeRwNkS
— miyake / ZEN (@kazuyukimiyake) October 9, 2020

白いケースいいなぁという感じで、ケースとCPUクーラーが決まったんで、ググってこちらのHAKKAさんのYouTube見ながら妄想してました。パーツがなかなか揃わなくて。そして、PCが光るのどうなの?と思ってたのに、気づいたら光ってました(なぜ?)。

グラボがない状態(CPU内蔵GPU)で12月頭までは動作してました。

購入自体はTSUKUMO、ビックカメラオンライン、パソコンSHOPアーク、イートレンドオンラインショップでオンラインで購入しました。

拡張カードは実は差し込んだら最初うまく動かなくてサポートに連絡しました。同じ構成の検証機を用意して解決方法を見つけてもらいました。しかも数日で。サイコーのエクスペリエンスでした!

日本語でサポートしてもらえてしかも数日で解決してもらった。ASRockのサポートすばらしかったです！ https://t.co/8FasCInIqt
— Jun Ohtani (@johtani) December 8, 2020

その他

ケースのフロントパネルのUSB-Cポートを使えるようにするために。

Amazon | Cablecc USB 3.1フロントパネルソケットType-E-マザーボード用USB 3.0 20ピンヘッダーオス拡張アダプター | cablecc | PCアクセサリ・サプライ通販

最近のPCパーツはUSBでモニタリングできるみたいで、マザボのUSBポートが足りなかったので拡張しました。

Amazon | マザーボードのUSB 9ピン増設内部用4ポートUSB2.0 HUB | ノーブランド品 | USBハブ通販

白いケースだし、「映え」のために白いケーブルを。

Amazon | Novonest 電源専用延長スリーブ補助電源モジュラーケーブル長さ300mm 6本1セットスリーブガイド24点セット付き【SC304】 | ｎｏｖｏｎｅｓｔ | 電源ユニット通販

組み立て中

手元にあったCPUでBiosアップデート(Ryzen 5000シリーズにしたかったから。まだできてないけど)。

応急処置でBiosアップデートしてる pic.twitter.com/mXf2B5kwqB
— Jun Ohtani (@johtani) November 8, 2020

さーて、頑張るぞー pic.twitter.com/HmlGqREjmP
— Jun Ohtani (@johtani) November 13, 2020

さて、仮起動実験ですよと pic.twitter.com/5HP3cbs6SH
— Jun Ohtani (@johtani) November 13, 2020

きたきたー pic.twitter.com/4sL3ymecEo
— Jun Ohtani (@johtani) November 13, 2020

コネクター刺しまくらないと pic.twitter.com/Soye3lS4M9
— Jun Ohtani (@johtani) November 13, 2020

完成はこんなかんじ

初期構成

組み上がったよー pic.twitter.com/sBwpvLsZh3
— Jun Ohtani (@johtani) November 14, 2020

グラボデプロイ

設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA
— Jun Ohtani (@johtani) December 4, 2020

グラボのおまけも付けてみた。

まぁ、せっかくついてきたので取り付けてみました（グラボ下の光ってるパネル）。 pic.twitter.com/068IxaV1ps
— Jun Ohtani (@johtani) December 4, 2020

とまぁ、こんな感じでした。メモリは多分使い切れないだろうなぁと思いながら、やってみたかったという感じです。。。

今年の振り返りと来年の抱負（2020）

Thu, 31 Dec 2020 18:13:24 +0900

今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。

振り返り（2019年に書いた抱負から）

まずは去年の抱負を元に書きますが、3月以降はコロナウィルスの影響でいろいろと生活が変わってしまいましたね。

職につく

厳密には達成してないことになるのかな？

1月末にフリーランスはじめました(仮)という記事を書きましたが、そのまま、現時点では個人事業主でフリーランスとして4社ほどお手伝いさせていただいています。

お手伝いしてるお客さんの事例が出てた。直接的に類似画像検索の部分を手伝ってるわけではないんですが、Azure Cognitive Searchの調査とかやってます。 / 「ハッカソン」で社外の知見を積極的に活用! 富士フイルムソフトウエアが実践するサービス開発の理想形 - https://t.co/yDIwYmYDBM
— Jun Ohtani (@johtani) June 19, 2020

名前出てた。ZOZOさんの手伝いさせていただいております。 / ZOZOTOWNにおける検索速度改善までの道のり - ZOZO Technologies TECH BLOG - https://t.co/OqaFMYe0TY
— Jun Ohtani (@johtani) August 20, 2020

こんな感じです。コロナウィルスの影響もあり、完全リモートで仕事をさせていただいています。感謝しかないです。

ブログプラットフォームの移行

昨年の振り返りの時点で目を付けていたHugoへの乗り換えを行いました。乗り換えについてもまとめてあります。

無事移行できて、特に困ってない感じです。

プログラミング

昨年よりは書いた気がしています。まぁ、書きなぐって放置してるのもありますが。。。

細々としたツールがいくつか。

あとは、Linderaという形態素解析も手伝ってみました。ちょっと後半は忙しくなり、コーディングが減ってるんで、また復活させないと。

Rust再入門

Tantivyは結局触れてないけど、Linderaを手伝えました。あとは、ちょっとしたツール(bulk2es-rs)なども作りました。知り合いとやっていたRust the bookを読むのも一通り終わりました。 Linderaまわりのリファクタとかを年明けにやろうかな?

検索の勉強

仕事になりました。というか、しました。ブッチャー本も買ったんですが、手を付けられてないので、年明けから心機一転、よみ始めようと思います。

検索技術勉強会の継続

残念ながらだめでした。年初にスピーカーの方に連絡は入れて履いたのですが、コロナウイルスの影響で今年はオフラインの勉強会は無理だろうとい事で延期したままです。オンラインの勉強会もいくつか開催されていましたが、検索技術勉強会は残念ながらモチベーションもわかずのまま今年も終わってしまいました。単に話を聴くセミナーのようなものよりは、Podcastのような形を取るのがいいのかもなぁとは思っているのですが。。。だれか、サクッと話したい人いたらやってみませんか?

振り返り(今年あったできごと)

さて、ここからは今年の出来事を。

自宅環境の改善
Windowsへの移行
キーボードDIY
フリーランス
ブログ書いたなぁ

3月以降はずーっと自宅で仕事してました。ということで、自宅の環境がどんどんアップデートされていった1年でした。最終バージョンは年内に間に合わなくて、年明けに書きますが。。。途中経過はこんな感じでした。今は更に変わっていますが。

12月バージョンでも書きますが、ずっと自宅で作業だったのもあり、自作PCをやりたくなったので、久々にWindowsに帰ってきました。Ubuntuもチョット検討しましたが、Windowsに今は落ち着いています。自作PCはこんな感じ。自作PCブログも後で書きますね。

設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA
— Jun Ohtani (@johtani) December 4, 2020

AutoHotKeyで色々と弄っているので、素のWindowsは触れる気がしないけど。。。

自作つながりで、キーボードもDIYしました。

分離キーボードには昨年から興味があったのですが、手を付けていませんでした。今年は自宅でずっと作業でしたから、これを機会に作ってみました。既製品(Moonlander)も気になってはいたのですが、DIYキーボードはプラモデル感覚で作れそうだし面白そうだなと。今年一番ハマったものかもしれないです。知り合いが始めたKochi Keyboardで最初に発売されたのがCorne Light v2だったので、これが初めての分割キーボードです。 40%キーボードからいきなり入ったので最初はかなり大変でしたが、なれると入力が早くなる気がします。ホームポジションからほぼ動かないのはいいですね。最初は数字列がないのでアホか???と思っていましたが。今は、Sofle(60%キーボード)がメインになっています。40%から60%に移行すると数字のキーが遠いなと思ってしまいますねw

どうなるものかと思いつつ、フリーランスを続けています。最初に仕事をいただいた富士フイルムソフトウェアさんには非常にお世話になっています(今もお手伝いさせてもらっています、ありがたい)。来年も精進していきます!

今年はブログを書きました、最後はちょっと息切れしてる感じになってるけど。。。もっとカジュアルに書くようにしないとなぁ。年明けにまだ書いてないブログを書いていかないと。「自作PCブログ」「Sofleのビルドブログ」「2020年買ってよかったブログ」とか。

来年の抱負

ということで、来年の抱負です。

フリーランス継続?
プログラミング
検索の勉強
検索のポッドキャスト?

とりあえず今年は乗り切れました。来年も食べていくためにもフリーランスを継続できるように、お手伝いさせて頂いてる各社に継続してもらえるように精進していきます。色々と勉強させて頂いてるのでほんとうにありがたいです。

プログラミングは今年の後半はスローダウンしてしまったのでがんばらないと。検証用のコードやちょっとしたツールを書くほうが多いので、もう少し継続してメンテナンスするようなものも書きたいなぁと。

検索の勉強はまずはブッチャー本を買ってしまったので、ここからでしょうか。値段も厚みもすごいので、コツコツ元を取れるようにがんばります。。。

来年もまだまだ自宅で仕事が続きそうなので、勉強会というよりもポッドキャストみたいなものをやるのがいいのかもなと。 2020年初にやらせていただいた、「検索システム探訪」をポッドキャスト風にやるのもありなのかもなぁ。興味ある人いたら連絡ください。公開しない雑談とかもありだと思ってるので。

今年は色々ありましたが、無事に乗り切れました。気軽にランチなどで遊びに行けない状況ですが、雑談相手になっていいなと思う方、連絡お待ちしています。

さて、来年はどんなキーボード作るのかなぁ(え?また作るの??)。今後もよろしくおねがいしまーす!

Index Template V2

Thu, 17 Dec 2020 23:55:55 +0900

Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。

本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたIndex Template V2について調べたのでどんなものかをまとめてみます。リリースブログには出てきてない（7.8のEsのページのWhat’s newには出てた）ので気づいてない人も多いのではないでしょうか？

Index Templateとは？

まずはIndex Templateがどんなものかを説明しましょう。

Indexの設定やマッピングはデフォルト値以外を設定したい場合に、毎回"mappings"や"settings"の設定を指定してIndexを作成するのは手間がかかります。そこで便利な機能として提供されているのがIndex Templateです。このIndex TemplateはCluster Stateに保管されます。

Index Templateを利用するときの流れは以下の通りです。

Index Templateの作成
Indexの作成

例えば、3ノード構成のクラスターでインデックスを作成するときに常に"number_of_shards: 3"を設定したいとします。 Index Templateは次のような感じになります。

PUT _template/blog_num_shards
{
  "index_patterns": "blog_*",
  "settings": {
    "index": {
      "number_of_shards": 3
    }
  }
}

または日本語のシンプルな形態素解析のアナライザーの設定を"jp_“という名前でるようできるようにしたい場合には次のような感じになります。

PUT _template/jp_simple_kuromoji
{
  "index_patterns": "jp_",
  "settings": {
    "index": {
      "analysis": {
        "simple_jp": {
          "type": "custom",
          "tokenizer": "kuromoji"
        }
      }
    }
  }
}

インデックステンプレートの登録が終われば、インデックスを作成するタイミングでIndex Templateが適用されます。例えば、blog_2020というインデックスを作成すると、number_of_shards: 3のインデックスが作成されます（デフォルトは1）。 jp_blog_2020というインデックスを作成すると、simple_jpというAnalyzerが設定されています。このように、インデックス名を意識するだけで設定が適用されていくのが利点です。

ちなみに、Index TemplateはIndex作成時に適用されるだけなので、Index Templateを変更してもこれまでのインデックスへは影響はありません。

これまでのIndex Templateの問題点

と、Index Templateが便利なのはわかりましたが、ではなぜ今回V2がリリースされたのでしょうか？先ほどの例を見るとわかりますが、これまでのIndex Templateは部品化が難しいのが問題でした。 Index Templateはそれぞれがインデックスの作成時に適用されます。が、Index TemplateにIndex Templateを組み込むことはできません。例えば、先ほどサンプルとして作成したjp_simple_kuromojiのIndex Templateはjp_で始まるインデックスにしか適用できません。

では、blog_で始まるインデックスにもkuromojiのシンプルなアナライザーを使いたくなった場合はどうなるでしょう？残念ながら、jp_simple_kuromojiと同じ設定をblog_num_shardsのテンプレートに追加するか、jp_simple_kuromojiのindex_patternsの部分だけを書き換えた新しいテンプレートを用意するか、jp_simple_kuromojiのindex_patternsにjp_を追加する方法です。いずれにしてもIndex Templateの継承（複数のテンプレートを1つのインデックスに紐づける）が必要となります。この時、複数のIndex Templateが適用されるため、適用する順番が出てきます。この順番をIndex Templateのorderパラメータで指定できます。

ただ、これも問題のもととなっていました。複数あるIndex Templateのどれがどの順番で適用されるのか？それはインデックスを作成時にようやくわかります。使いたい側（インデックス）が、使いたいもの（テンプレート）を指定するのではなく、その逆（使いたいものに使いたい側の情報を設定しなくてはならない（index_patternsやorder））になっているのでわかりにくくなっていました。

ということで解決策としてリリースされたのがIndex Template V2です（ちなみに名前にV2とは言ってるわけではなく、現在のIndex Templateの機能がlegacy index templateという名前になり、Deprecatedになっています（まだログには出ない））。

Index Template V2

7.8のWhat’s newドキュメントではComposable Index Templateと紹介されています。大きく3つのエンドポイントが提供されます。

Component Template 用API
- テンプレートのコンポーネントという単位で管理するためのAPI。
- 登録更新、削除、取得が可能
Index Template 用API
- Index Templateを管理するためのAPI
- 登録更新、削除、取得が可能
Simulate index template API(Experimental)
- Index Template

Legacy Index Templateとの大きな違いは、

テンプレートをコンポーネントにできる
1つのインデックスに適用されれるテンプレートは1つだけ

という点です。これまでとは挙動が異なるので注意が必要です。

新しいIndex Templateを利用する際の流れは次のようになります。

Component Templateの作成
Index Templateの作成
作成したIndex Templateの挙動を確認
実際にIndex名を指定してIndex Templateの挙動を確認

という形です。では、それぞれの機能を見ていきましょう。

Coponent Template API

テンプレートコンポーネントを管理するためのAPIです。具体的なAPIごとに説明していきます。

PUT _component_template

コンポーネントを登録、変更するためのAPIです。公式ドキュメントはこちらです。先ほどのkuromojiのAnalzyerをコンポーネントとして登録してみましょう。

PUT _component_template/jp_simple_kuromoji
{
  "template": {
    "settings": {
        "index": {
        "analysis": {
          "analyzer": {
            "simple_jp": {
            "type": "custom",
            "tokenizer": "kuromoji_tokenizer"
            }
          }
        }
      }
    }
  },
  "version": 1,
  "_meta": {
    "description": "simpleなKuromoji analyzer"
  }
}

先ほどと特に違いはありません。templateという階層が1段増え、index_patternsがなくなりました。 template部分はIndexに設定するsettings、mappings、aliasesが指定可能です。ちなみに、“template"の中身をそのままIndex作成時に使用した場合にエラーにならない設定である必要があります。ここは注意が必要です。例えば、component Aでkuromojiのアナライザーの設定をし、component Bでそのアナライザーを使用するフィールドのmappingだけを記述した場合、component Bでエラーが発生します。上記のようなシチュエーションでは、Index Templateで利用するフィールドを定義し、component Aを利用する宣言をすれば問題ありません。

そのほかに使えるパラメータで便利なものを紹介しておきます。

クエリパラメータ
- create: URLに指定するパラメータ。trueを指定することで、既に存在する場合にエラーを返してくれる。更新も同じAPIなので間違わないようにするために利用すると便利。デフォルトはfalse
リクエストボディ
- _meta: テンプレートにメタ情報を付与できる。_metaの中は自由に記述可能。コメントなどを書いておくとあとでわかりやすい

GET _component_template

コンポーネントを取得するためのAPIです。公式ドキュメントはこちらです。一覧での取得とリストでの取得が可能です。

一覧取得サンプル

GET /_component_template
GET /_component_template/*

これ以外に、IDを指定して取得することも可能です。

GET _component_template/jp_simple_kuromoji

*を利用して複数取得も可能です。

GET _component_template/jp*
GET _component_template/j*_*

DELETE _component_template

コンポーネントを削除するためのAPIです。公式ドキュメントはこちらです。 IDを指定してコンポーネントを削除できます。

DELETE /_component_template/jp_simple_kuromoji

ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。

DELETE /_component_template/jp_*
DELETE /_component_template/*

ちなみにIndex Templateで利用されているコンポーネントを削除しようとした場合はエラー（ステータスコード400）が返ってきます。 *などを使用して削除しようとした場合は、ひとつでも利用されているものが含まれている場合は削除は実行されずにエラーだけが返ってくるようになっています。

Index Template API

Index Templateを管理するためのAPIです。 Component Template APIで定義したコンポーネントを利用してテンプレートを作成できます。コンポーネントを利用しないで単体で完結したテンプレートも作成可能です。具体的なAPIごとに説明していきます。

PUT _index_template

Index Templateを登録・更新するためのAPIです。公式ドキュメントはこちらです。

これまでのLegacy Index TemplateのAPIのエンドポイント(_template)ではなく、(_index_template)というエンドポイントになっていることにまず注意してください。先ほど作成したjp_simple_kuromojiコンポーネントと、追加で作成した3_shardsというコンポーネントを利用して blog_で始まるインデックスに適用できるIndex Templateを作成してみましょう。

PUT _index_template/blog_template
{
  "index_patterns": ["blog_*"],
  "template": {  
    "mappings": {
      "properties": {
        "hoge": {
          "type": "text",
          "analyzer": "simple_jp"
        }
      }
    }
  },
  "priority": 100,
  "composed_of": ["jp_simple_kuromoji", "3_shards"]
}

composed_ofというパラメータに利用したいコンポーネントを配列で記述していきます。 Index Templateが適用される時に、ここに記述されている順番でコンポーネントが適用されていきます。ですので、最後に書いてあるテンプレートが一番強いことになります。これは例えば、同じ設定値number_of_shardsを2つのコンポーネントが設定している場合に、最後に設定した値がインデックスに採用されるという意味です (公式ドキュメントにサンプルが掲載されています)。なお、存在しないコンポーネントをcomposed_ofに指定した場合は400エラーが返ってきます。同じコンポーネントを複数重複して指定した場合は特にエラーにはなりませんでした。 composed_ofを指定しなければ、単体で完結したテンプレートを定義可能です。

次に重要な設定はpriorityです。これまでのテンプレート機能と異なる点で説明しましたが、

1つのインデックスに適用されれるテンプレートは1つだけとなっています。この1つを決めるための値がpriorityになります。インデックス名によってはindex_patternの定義によって、複数のIndex Templateにマッチします。例えばblog_*と*_2020のIndex Templateがあった場合にblog_2020というインデックスを作った場合です。この時、Elasticsearchはpriorityの大きい値を持ったIndex Templateだけを適用します。 blog_*のIndex Templateのpropertyが10、*_2020のIndex Templateのpropertyが100だった場合、*_2020のテンプレートが適用されます。Legacy Index Templateではorderという似たパラメータがありましたが、こちらは適用する順序を決定するためのものでした。挙動が違うので注意しましょう。

ちなみに、blog_*と*_2020のpropertyがどちらも10というIndex TemplateをPUTしようとした場合、2番目にIndex TemplateをPUTするタイミングでエラーが返ってきます。

そのほかに使えるパラメータで便利なものはPUT _component_templateと同様にcreateと_metaです。

GET _index_template

Index Templateを取得するためのAPIです。公式ドキュメントはこちらです。一覧での取得とリストでの取得が可能です。

一覧取得サンプル

GET /_index_template
GET /_index_template/*

これ以外に、IDを指定して取得することも可能です。

GET _index_template/blog_template

*を利用して複数取得も可能です。

GET _index_template/blog_*
GET _index_template/b*_*

DELETE _index_template

Index Templateを削除するためのAPIです。公式ドキュメントはこちらです。

IDを指定してコンポーネントを削除できます。

DELETE /_component_template/jp_simple_kuromoji

ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。

DELETE /_component_template/jp_*
DELETE /_component_template/*

最後のサンプルを実行すると、Elasticのツールなどが登録したIndex Template以外はすべて削除されてしまうので本当に気を付けましょう。

Simulalte API

さて、コンポーネントとテンプレートを作成したので確認をしましょう。 Legacy Index Templateでは確認するためには実際にインデックスを作成するしかありませんでしたが、V2ではSimulate APIが用意されています。このSimulate APIには2つのAPIがあります。

POST /_index_template/_simulate/<テンプレート名>
POST /_index_template/_simulate_index/<インデックス名>

Index Templateの確認のためのAPIとインデックス名を指定したときに出来上がるIndexの設定を確認するためのAPIです。 Indexを実際に作成しなくても確認できるのは便利ですね。

例えば先ほど作成したblog_templateを試してみましょう。

_index_template/_simulate API

POST _index_template/_simulate/blog_template

レスポンスはこんな感じです。

{
  "template" : {
    "settings" : {
      "index" : {
        "analysis" : {
          "analyzer" : {
            "simple_jp" : {
              "filter" : [
                "kuromoji_readingform"
              ],
              "type" : "custom",
              "tokenizer" : "kuromoji_tokenizer"
            }
          }
        },
        "number_of_shards" : "3"
      }
    },
    "mappings" : {
      "properties" : {
        "hoge" : {
          "type" : "text",
          "analyzer" : "simple_jp"
        }
      }
    },
    "aliases" : { }
  },
  "overlapping" : [
    {
      "name" : "blog_template2",
      "index_patterns" : [
        "blog_*"
      ]
    }
  ]
}

templateにコンポーネントがマージされた結果が出力されます。 overlappingはindex_patternsがかぶる可能性があるIndex Templateの情報が出力されます。サンプル用にblog_template2という、同じindex_patternsでpriorityが低いものを登録してあるためです。 index_patternsが完全に同じではなくとも、重複する可能性があるものはここに出力されます。例えば、index_patternsがb*という別のIndex Templateを作成してからSimulate APIを実行すると、overlappingにそのIndex Templateも出力されます。

Simulate Index Template APIのもう一つの機能は登録前のIndex Templateの確認です。リクエストのURLのテンプレート名をなくし、PUT _index_templateと同じJSONをリクエストボディとして送信した場合、コンポーネントをマージしたテンプレートがどんなものかを確認できます。

POST _index_template/_simulate
{
  "index_patterns": ["blog_*"],
  "template": {
    "mappings": {
      "properties": {
        "hoge": {
          "type": "text",
          "analyzer": "simple_jp"
        }
      }
    }
  },
  "priority": 10,
  "composed_of": ["jp_simple_kuromoji"]
}

このリクエストを送信すると、コンポーネントがマージされた結果が返ってきます。index_patternsがかぶるものがある場合はoverlappingも一緒に返却されます。

_index_template/_simulate_index API

今度はインデックス名を指定するSimulate APIを試してみましょう。

POST _index_template/_simulate_index/blog_2021

これだけです。

{
  "template" : {
    "settings" : {
      "index" : {
        "analysis" : {
          "analyzer" : {
            "simple_jp" : {
              "filter" : [
                "kuromoji_readingform"
              ],
              "type" : "custom",
              "tokenizer" : "kuromoji_tokenizer"
            }
          }
        },
        "number_of_shards" : "3"
      }
    },
    "mappings" : {
      "properties" : {
        "hoge" : {
          "type" : "text",
          "analyzer" : "simple_jp"
        }
      }
    },
    "aliases" : { }
  },
  "overlapping" : [
    {
      "name" : "fuga",
      "index_patterns" : [
        "b*"
      ]
    },
    {
      "name" : "2021",
      "index_patterns" : [
        "*_2021"
      ]
    }
  ]
}

例で作成したblog_templateが適用されていますが、それ以外にindex_patternsに合致したがpriorityが低くて適用されなかったものがoverlappingに出力されています。実際に適用されたテンプレートの名前も別途出力してくれるとわかりやすいかもしれないですね。 (*_2021というインデックスパターンのテンプレートを試しに作ってみたのですが、これはバグがありそうです。2021に合致するインデックス名をSimulateしたらoverlappingに合致しないものがたくさん出てきました。バグ報告しとくか)。

Kibana対応

ここまで、Index Template V2のAPIの説明でしたが、Kibanaでの対応についても調べてみました。

Index Management（Stack Management機能。Elasticライセンスが必要だが無償の機能）

7.9からKibanaのIndex管理画面でComposable Templateが利用できるようになっています（GitHub Issue）。画面のスクショを一通り貼っておきます。残念ながら、それぞれのJSONの編集部分では補完などはサポートされていないようでした。頑張って自分でsettingsやmappingsのJSONを記述していく感じになります。JSONとして正しいかどうかはチェックしてくれます。 Index Templateのウィザードでは、ボタンでコンポーネントを追加したり削除したり、順序を入れ替えたりといった作業が可能になっています。また、プレビュー表示が可能なので、composed_ofで選択したものが今どのように適用されているか？といったのも確認できるようになっていました。結構便利に管理できそうです。ちなみにスクショは7.10の画面になります。

Component Template周り
- 一覧表示とウィザード

Index Template周り
- 一覧表示とウィザード

Console(Dev Tools。OSSで利用可能)

リクエストを実行は可能ですが、自動補完機能は一部のみ対応しているようです(GitHub Issue)。

対応済みの機能

DELETE _component_template (ただし、ここまで。存在するコンポーネント名は補完されない)

上記以外はまだ未対応のようです。プルリクエストチャンスかも？

参考

まとめ

ちょっと長くなってしまいましたが、新しいIndex Templateについての紹介でした。これまでと違い、複数のテンプレートが適用されない点があるのでそこは注意が必要そうです。コンポーネントをうまく使えば、管理が簡易化はされそうですね。

Index Template v2

Thu, 17 Dec 2020 00:00:00 +0000

Corne Chocolateを組み立てた #DIYキーボード

Thu, 03 Dec 2020 23:13:44 +0900

はじめまして、pyspa。ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。コンビそろってキーボード記事ですね。

今年はDIYキーボードにはまった（はめられた？）年でした。もともと分割キーボードには興味があり、自宅で作業するのが基本となったのもあり手を出した次第です。まだまだ使いこなすところまでは来てないかもしれないですが、組み立てたり、問題点のキリ分けしたり、試行錯誤するのは楽しいなと。

今回はCorne Chocolateというキーボードを組み立てたのでそちらのビルドログ（かつ今後のための教訓）になります。 LEDを使ったキーボードがどんなものなのか＋薄いキーボードも気になるなということで取り組んでみました。今回もいくつか失敗をしつつ、リカバリーして動くものができました。

パーツ（材料）

基本のパーツは今回もKochi Keyboardさんから購入しました。

キット : Corne Chocolate（ベースキット）
キースイッチ : Kailh Choc v1 Blue (25gf リニア) 5個
キーキャップ : Kailhロープロ刻印キーキャップ

ケーブル類は家に転がっていたケーブルを利用しました。キースイッチセットもあるのですが、軽いキータッチが好みなので、一番軽いKailh ChocのBlueを試してみたくキースイッチを個別に選択しました。キーキャップはShiroを作るときに調達していたものを利用した形です。

今回も公式のビルドガイドにざっと目を通してから着手しました。

準備

ビルドログにもあるようにPCBがリバーシルブなので、作業中に迷子にならないようにこんな感じで表にマスキングテープで目印をつけておきました。

今回から耐熱ワーキングマットで作業をすることにしました。机の天板に傷つくの嫌だし。気兼ねなくはんだできるのでおすすめです。

https://t.co/0qntPD8qIa
2ヶ月ぐらいにここで買いました！
— 西田和史(k.bigwheel) (@k_bigwheel) November 11, 2020

ダイオード、OLEDソケット、コンスルー、TRRSソケット、

こちらは前回のCorneとほぼ同様だったのでビルドガイド通りに進めます（写真撮り損ねました。。。）前回との違いはダイオードの形です。表面実装するタイプのダイオードなので向きに気を付けつつ、つけていきます。

ビルドガイドに向きやダイオードのつけ方が紹介されています。拡大鏡とピンセット必須ですね。前回同様に、ここまででいったんqmk_toolsでファームウェアをインストールして、ピンセットを使いながらキーの認識とOLEDの動作確認を行いました。今使っているファームウェアがあるのでそれを入れて問題ないかを確認しました。

LED実装

今回のメインイベントです（そして苦杯をなめたイベントでもあります）。ビルドガイドにも記載がありますが、信号が流れる順番があるようなので1番から取り付けていきます。また、ビルドガイドにLEDに関する注意事項もいくつか掲載されています。必ず読みましょう。

この1～6までのLEDがすごく大変でした。。。

表面実装のLED（Underglow LED）で四苦八苦

いくつかのブログを参考にしながら作業を進めました。

コルネキーボードを作りました～LED取り付けに四苦八苦記～ | キオクノロンダリング
- SK6812miniの仕様などについて書いてあります。デバッグするのにすごく役に立ちました。

Corne Chocolateビルドログ - nokの雑記
- 手書きでどんな感じでやればいいのかを解説してくれています。最終的にはこの方法が一番だったのかも？
自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方
- あとで出てきますが、リカバリ方法の参考になりました。

皆さん苦労されてますね、そして私も苦労しました。。。

試してみた方法、考察は次の通りです。

LEDチェック用のファームウェアをインストールして1つつけては動作確認
- HelixのLEDテスト用ファームウェアをインストールしました。
白光 1C型こて先
- 失敗した後にリカバリするために購入しました。
- LEDのランドなどが2Cよりも面積が小さいので、そのサイズに合わせたこて先のほうがよかったようです。
はんだの温度（温調できるはんだごて必須）
- 最初は250℃でやっていましたが、なかなかはんだが溶けません。そのせいで焦りも出てきます。
- 最終的には270度で作業しましたが、温度のせいでLEDが壊れたのはなかった気がします。1Cのこて先だったので無事だったのかもしれません。
フラックスなし
- あると楽だったのかも？残念ながら試してないです。
予備はんだ手法（だめっぽかった）
- 基盤のランド4か所に予備はんだをし、はんだを温めつつLEDを乗せる方法
- LEDの裏にも予備はんだ
- どちらも試してみましたが、温めている個所以外のはんだと高さの違いが出てしまい、LEDが浮いてしまいます。4か所を同時に温めることはできないので、すこしずつ調整しているうちにLEDを物理的に壊してしまうことがありました。。。

ちょっとコツが分かったかも？ pic.twitter.com/ruwrmEWCAe
— Jun Ohtani (@johtani) November 19, 2020

わかった気になっていますが結局失敗しました。。。

結局最後までこれというコツはわかってない気がします。結局3つか4つのLEDがお亡くなりになりました。うまくいかなかった原因は、予備はんだで傾きなどができ、それを修正していくうちに基盤やLEDにダメージを与えてしまったのだと思います。

よく見ると基盤が一部剥がれかけてるのがわかるかなぁと。

リカバリー

右手側の表面実装の4番と5番が失敗しました。

4番目（以下のツイート右側画像の上）
- こちらは、1度付けたLEDをはがすときにはんだを取り除くのが不十分な状態でLEDをはがしたために、基板のランドごとはがれてしまいました。
- なのでここはLEDはつかないです。。。
5番目(以下のツイート右側画像の真ん中あたりの黄色い線がつながっているLED)
- LED自体はつけてありますが、青色しか発光しなくなっています。

4番目が完全に死んでしまったので、無事な3番目のLEDのDINに流れている信号を 5番目のLEDのDINにも流れるようにするために10芯コードでショートカットさせました。（リカバリ方法は先ほど紹介したブログが非常に参考になりました、先人の知恵ありがたし）。黒い線も売っていたのですが、自戒も込めて目立つ色にしてみました。

勉強させていただきました、、、 pic.twitter.com/Zp16fJKziM
— Jun Ohtani (@johtani) November 22, 2020

ちなみに、左側のショートカットのコードはつけた後に1か所LEDの向きが違うことに気づき必要なくなっています（上記の基盤が傷ついている画像をよく見ると上下が逆になってるのがわかる人にはわかるかも）。

片方は導線なくて良くなった。表から見たら向きが違うのに気がついたわ、、、 pic.twitter.com/7TSDMPPxlX
— Jun Ohtani (@johtani) November 22, 2020

最終的に2か所おかしいLEDにはなりましたが、幸いにもアンダーグローです。 Kochi Keyboardさんで購入したキットのボトムプレートはFR4なのでほぼ見えません！（負け惜しみ）

ソケット

さて、気を取り直してソケットをつけていきます。 Dozen0にて経験済みなのでそれほど手間はかかりませんでした。 LEDの失敗の時に1Cのこて先を購入していたため、ソケットの横の隙間からこて先が差し込めたのが便利でした（LEDでダメージを受けていたのもあり写真撮り忘れ）。

完成

ということで完成です。デフォルトで赤く光ってます。キーキャップがLEDを透過してくれるタイプだったのがこれまたよかったですね。作る前は光らなくてもなんて思ってたのに。

キーマップ(v2)

Corne Lightで作業を数週間ほどして、いくつか入力しにくい部分があったのでマッピングを少しだけ変えました。相変わらず日本語キーボードベースですが、数字のレイヤーにいくつかの記号を使えるように割り当てました。コーディングをするときに、ライブラリのバージョン（例：7.10.0とか）やIPアドレスを入力していてレイヤー切り替えのためのキーを押したり話したりするのは効率が悪すぎたためです。数字との組み合わせでよく使いそうな以下のキーを数字のレイヤーに移動しました。

セミコロン（JP_SCLN）
コロン（KC_QUOT）
アンダースコア（JP_UNDS）
コンマ（KC_COMM）
ピリオド（KC_DOT）
スラッシュ（KC_SLSH）

#include "keymap_jp.h"

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
  [0] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
       KC_TAB,    KC_Q,    KC_W,    KC_E,    KC_R,    KC_T,                         KC_Y,    KC_U,    KC_I,    KC_O,   KC_P,  JP_MINS,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LCTL,    KC_A,    KC_S,    KC_D,    KC_F,    KC_G,                         KC_H,    KC_J,    KC_K,    KC_L, JP_SCLN, KC_QUOT,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LSFT,    KC_Z,    KC_X,    KC_C,    KC_V,    KC_B,                         KC_N,    KC_M, KC_COMM,  KC_DOT, KC_SLSH, KC_RSFT,
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI,   MO(1),  KC_SPC,     KC_ENT,   MO(2), KC_RALT
                                      //`--------------------------'  `--------------------------'

  ),

  [1] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
       KC_ESC,    KC_1,    KC_2,    KC_3,    KC_4,    KC_5,                         KC_6,    KC_7,    KC_8,    KC_9,    KC_0, KC_BSPC,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      KC_LEFT, KC_DOWN,   KC_UP,KC_RIGHT, JP_SCLN, KC_QUOT,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      JP_UNDS, XXXXXXX, KC_COMM,  KC_DOT, KC_SLSH, XXXXXXX,
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI, _______,  KC_SPC,     KC_ENT,   MO(3), KC_RALT\
                                      //`--------------------------'  `--------------------------'
  ),

  [2] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
       KC_TAB, JP_EXLM, JP_DQUO, JP_HASH,  JP_DLR, JP_PERC,                      JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      JP_MINS,  JP_EQL, JP_LBRC, JP_RBRC,  JP_YEN,   JP_AT,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD,
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI,   MO(3),  KC_SPC,     KC_ENT, _______, KC_RALT
                                      //`--------------------------'  `--------------------------'
  ),

  [3] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
        RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, RGB_SPI, XXXXXXX,                      XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, RGB_SPD, XXXXXXX,                      XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI, _______,  KC_SPC,     KC_ENT, _______, KC_RALT\
                                      //`--------------------------'  `--------------------------'
  )
};

LEDの色が変えられる！（気づくの遅い）

あと、キーマップを変更しているときに4つ目のレイヤーにRGBなどのボタンがあるのに気付いて押してみたら、LEDのパターンや色を変えることができるのに気付きました。（遅すぎでは。。。）

キーキャップが白いのもありこんな感じの色にしてみています。

ユニコーンガンダムっぽくなった pic.twitter.com/vHxZkMrYyP
— Jun Ohtani (@johtani) November 28, 2020

まとめ

ということで、失敗も多々ありましたがキーボードとしてはちゃんと動くできたものができたので安心しました。今後、状況が落ち着いてきて自宅以外で仕事をするときにはCorne ChocolateをPCと一緒に持ち歩くと思います。薄くて邪魔にならなくてよさそうです。

今回もはんだっしゅ太郎大活躍でした。本当に買ってよかった。 LEDがつかないときはちょっと落ち込みましたが、これのおかげで立ち直れたのもありますし。あとは、試行錯誤しつつLEDとかの理解ができたのも楽しかったです。キーマップの変更時にLEDの変更などができるのに気づいたのはちょっと遅すぎたので、qmkの仕組みや割り当てられるキーにどんなものがあるのかをもう少し研究したいなと思います。

さて、次はどんなことを試すかなぁ。

Corne Light v2を作成した #DIYキーボード

Thu, 05 Nov 2020 00:25:27 +0900

前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとしては2つ目になります。

まとめで書いていたお店が開店したので、購入してみました。購入したのはこちらのKOCHI KEYBOARDさんです。ついこの間オープンしたばっかりのお店です！

なんで作ったの？

スプリット型（セパレートタイプ？どっちが正しいんだろう？）のキーボードに興味があって、KOCHI KEYBOARDさんで買えたのがこれだったというのが大きな理由です。こういうのってタイミングだと思うので。あとは、組み立てていくのがプラモデルみたいで面白いというのもあります。基本的にここのところ自宅で仕事をしているので、ノートPCのキーボードにこだわる必要もないなというのも理由ですね。今後も当面は自宅で仕事になると思いますので。

Corne Light v2

foostanさんが設計された（って言い方であってるのかな？）、3x6のサイズに親指の3キーが配置された分離型のキーボードの一種です。シリーズ？の名前としてはCorne Keyboardと呼ばれています。（そういえば、由来は何だろう？自作キーボードがどうやって設計されていくのかという流れがまとめられた作者の方のブログがおもしろいです。）また、基板の設計などがGitHub上でMITライセンスで公開されています。オープンソースなハードウェアというのも面白いです。

ビルドログ

作者の方がビルドガイドを公開してくれています。ですので、こちらに沿って作業をしていきます。ちなみに、私は今回Gateronのクリア軸を選択してみました。さらさらと入力できるのが好きなので。サイレント軸にも興味はあるのですが、今回は実際にスプリット型のキーボードを早く触ってみたいというのが勝ちました。キーキャップについては後述します。ツイートに都度、写真をアップしていたので組み立ては画像でお楽しみください（時々取り忘れてるけどｗ）。

うむ pic.twitter.com/svW9WdzaZv
— Jun Ohtani (@johtani) October 21, 2020

刺して曲げる pic.twitter.com/M0jfQJg2k8
— Jun Ohtani (@johtani) October 22, 2020

両方できたと。ハンダまでやって今日はおしまいにすっか pic.twitter.com/HgsSrxqpcg
— Jun Ohtani (@johtani) October 22, 2020

写真取り忘れたけど、ProMicroつけた pic.twitter.com/RS4z0lqsUZ
— Jun Ohtani (@johtani) October 22, 2020

OLEDもついたと。今日はここまで pic.twitter.com/p6Z8MMP0Xz
— Jun Ohtani (@johtani) October 22, 2020

ここまでは順調です。

OLEDがつかない？

ビルドガイドに従って、この後キースイッチをつけちゃうと問題の切り分けが難しくなるということで、ここまでの段階でQMK Toolboxを使ってProMicroにファームウェアを書き込んで、それぞれのキーのソケットの取り付け部をピンセットでショートさせつつ、キーが入力されるかどうかを見ていきます。 QMK Toolboxについてはサリチル酸さんのブログがわかりやすいので参考にさせていただきました（わかりやすい記事をありがとうございます）。で、ビルドガイドにあるように動いてるかを確認しようとしたのですが。。。

さて、ファームウェア書き込んだけど、OLEDがつかないな。どっかつながってないのか？
— Jun Ohtani (@johtani) October 24, 2020

ビルドガイドのようにはいかず。。。 USBでPCとつないだ状態で、QMK Configuratorをサイトで開いて、キーボード入力テストを開くと、ショートさせたキーがPC側で認識されているかのテストができます。これで、一通りキーは認識できていそうだというのはピンセットでショートさせながら確認しました。ただ、OLEDには何も表示されないんです。。。

前回Dozen0を組み立てた時に、ソケットのはんだ付けが甘かったというのもあったので、 OLEDやソケットのはんだを温めなおしたりしてみて、何度か確認してみたものの特に進展がなしです。（ちなみにうまくいかないのもあって、ぼけたツイートしたりもしてます。）

まぁ、OLEDはビルドガイドを見てもオプション扱いなので、それよりも触ってみたい衝動に駆られて、キースイッチをはんだ付けしていきます。

ちなみに昨晩、OLEDはとりあえず置いといてって感じでキースイッチつけてた。キーキャップはまだない pic.twitter.com/SzLmzNg60Y
— Jun Ohtani (@johtani) October 26, 2020

それも終わって、問題点の切り分けに何かできないかな？と思ってやったのがOLED単体でArduinoと接続してみて動くかどうかです。 Qiitaにちょうどいい感じの記事を見つけたのでこれまた参考にさせていただきました(4本のジャンパー線を一人で持ちながら確認するの大変だったｗ)。

はんだでの修正にしっぱい

で、自分の中での結論として、「OLEDソケットのはんだ付けが怪しい」となりました。そこで、まずは外してみようかと思ったのが間違いでした。はんだごてとはんだ吸い取り線で何とか外せるだろうと思っちゃったんですよ。 OLEDピンソケットは足が4本あって、とりあえずとれるところまではんだ吸い取り線で吸い取ってみましたが、さすがに基盤の穴に流れ込んだはんだまでは吸い取れず、頑張って温めながらソケットを抜こうとがんばって、ラジオペンチでピンソケットを引っ張りながら引き抜きました。かろうじて引き抜きはできたのですが、ソケットは足が折れてしまいました。

作者登場（OLED問題の解決）

そんなところにCorneの作者の方がツイートを拾ってくれたみたいで以下のような返信を頂きました。

OLEDが点かないのはファームのせいかもしれません(最近以前のファームで動かない新しいタイプのOLEDモジュールが出回るようになりました)。お手数ですが、https://t.co/vfSBfIeeJX のブランチのものを試して頂けますか？(ただいまPRレビュー中でまだマージされていない状態です)
— foostan (@foostan) October 25, 2020

暗闇に光明とはこのことです。教えていただいたブランチを手元でビルドしてファームウェアを書き込むと、

すごい、出ました！右側のディスプレイにロゴが。ありがとうございます（左側のOLEDはソケットのはんだ付け直し失敗したのでもうちょっと先になりますが）！
— Jun Ohtani (@johtani) October 26, 2020

なんと、ファームウェア書き込んだ瞬間にOLEDが点くじゃないですか。感謝感激ってやつです。お礼を言うのに便乗してOLEDの問題の切り分けの方法についても聞いてしまいました。

OLEDリベンジ

片側は無事だったのですが、もう一方は修復が困難になったので救世主を発注します。自作キーボードの作成に便利なものリストとして、いくつかのブログに上がっていたのですが、必要ないだろうと見送っていたツールです。

Amazon | サンハヤトはんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ

本当にすごく使いやすかったです。 OLEDのピンソケットが修復不可能だったのですが、ProMicro用に付属して余っているピンヘッダがちょうどいい長さでした。なので、これを4本分切り取り、OLEDモジュールにつけてしまったOLEDヘッダピンを抜き取って、代わりに切り取ったピンヘッダをつかって、OLEDと基盤を直接はんだ付けすれば修復できそうだと判断しました。

はんだシュッ太郎君を使ってOLEDについてるヘッダピンをまずは除去。そのあとはこんな感じで繋げました。

見にくいかもだけど pic.twitter.com/YAHoxjgppN
— Jun Ohtani (@johtani) November 5, 2020

取り外しにくくはなったけど、無事両方のOLEDが点くのも確認できました。やったー。

ヤッター、両方のOLEDがついたよー pic.twitter.com/6KLDWvnaEC
— Jun Ohtani (@johtani) October 28, 2020

キースイッチがご機嫌斜め

キーキャップは別途、AliExpressで発注をかけたのですが、ここまで来たら待ちきれないですよね？ということで、手元にあった上海問屋のキーボードのキーキャップが同じMXキースイッチ用のものだったので移植しました。キーキャップ付けてみないとわかならいものですね、1つだけキースイッチがうまくはまっておらず、斜めについているのがこの時点で判明しました（ボトムプレート付けた後だったので、プレート外してから、はんだで修正）。

ちなみにキーキャップはめてる途中で、一箇所キースイッチが斜めにはんだ付けされちゃってるのを発見して慌てて直しました。 pic.twitter.com/qofHp3o4Pc
— Jun Ohtani (@johtani) October 30, 2020

無事使えるようになりました。

アンスコが打てない＆Escどこ？

キーキャップ付けたので仮運用ということで、まずはデフォルトのキーマップをもとにどんな感じで入力できるのかを試してみました。ここにも罠がｗブラウザでQMK Configuratorを開いてデフォルトのキーマップを確認しながら試し打ちをしていたのですが、どうも思ったのと違う動きをしているキーが。

まずBASEレイヤー（レイヤー0）の右側のシフトと、LOWERレイヤーやRAISEレイヤーのEscです。入力しているとどうも、右のシフトがEscで、レイヤーを切り替えてもTabのままだなと。しょうがないので、OLEDが出なくてもいいのでQMK Toolboxでダウンロードしてきたものを利用したら想定通りなのにと。きちんとqmk_firmwareの構成を理解しないままやってたつけでしたね。結論としては、OLED用に教えてもらったブランチではキーマップが書き換わっていたようでした。 make crkbd:defautでビルドした時に利用されるkeymap.cがキーマップの定義が書いてあるファイルです。 qmk/qmk_firmwareのリポジトリにあるkeymap.cとfoostanさんにもらったブランチでは差分があったみたいでした。

おかげで、qmk_firmwareのkeymap.cの仕組みがわかったし結果オーライです。問題があって調べるとどんな作りになってるかとかちゃんと確認できますしね。手順通りにやってるだけで問題が起きないと、どんな仕組みになってるのかがわからないので人に聞きまくるしかできなくなっちゃいますしね。

これでEsc問題は解決したのですが、アンスコがどうしても入力できません。自作キーボード以外はすべて日本語配列のキーボードを使用しているのもあり、日本語配列のキーボードだとどうもキーのマッピングが異なるようだと。

ググって参考にしたのはこの辺でした。

そのほかにもVIAのファームなども試したのですが、どれもうまくいかず。色々ググってみて最終的な解決策はkeymap.cでkeymap_jp.hというファイルが読み込まれていないので、日本語用の設定とかを読み込んでみたつもりがうまく反映されていないという感じでした。

JISにする場合、keymap_jp.hっていうヘッダファイル読み込んだほうがいいです
— Yoshi Yamaguchi (@ymotongpoo) November 3, 2020

今の時点ではこんなキーマップにしてあります。今後も日本語配列のキーボードをベースに考えていくつもりです。


#include QMK_KEYBOARD_H
#include "keymap_jp.h"

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
  [0] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
       KC_TAB,    KC_Q,    KC_W,    KC_E,    KC_R,    KC_T,                         KC_Y,    KC_U,    KC_I,    KC_O,   KC_P,  JP_MINS,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LCTL,    KC_A,    KC_S,    KC_D,    KC_F,    KC_G,                         KC_H,    KC_J,    KC_K,    KC_L, JP_SCLN, KC_QUOT,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LSFT,    KC_Z,    KC_X,    KC_C,    KC_V,    KC_B,                         KC_N,    KC_M, KC_COMM,  KC_DOT, KC_SLSH, KC_RSFT,
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI,   MO(1),  KC_SPC,     KC_ENT,   MO(2), KC_RALT
                                      //`--------------------------'  `--------------------------'

  ),

  [1] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
       KC_ESC,    KC_1,    KC_2,    KC_3,    KC_4,    KC_5,                         KC_6,    KC_7,    KC_8,    KC_9,    KC_0, KC_BSPC,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      KC_LEFT, KC_DOWN,   KC_UP,KC_RIGHT, XXXXXXX, XXXXXXX,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI, _______,  KC_SPC,     KC_ENT,   MO(3), KC_RALT\
                                      //`--------------------------'  `--------------------------'
  ),

  [2] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
       KC_TAB, JP_EXLM, JP_DQUO, JP_HASH,  JP_DLR, JP_PERC,                      JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      JP_MINS,  JP_EQL, JP_LBRC, JP_RBRC,  JP_YEN,   JP_AT,
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD,
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI,   MO(3),  KC_SPC,     KC_ENT, _______, KC_RALT
                                      //`--------------------------'  `--------------------------'
  ),

  [3] = LAYOUT_split_3x6_3( \
  //,-----------------------------------------------------.                    ,-----------------------------------------------------.
        RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,                      XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, XXXXXXX, XXXXXXX,                      XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\
  //|--------+--------+--------+--------+--------+--------|                    |--------+--------+--------+--------+--------+--------|
      RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, XXXXXXX, XXXXXXX,                      XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\
  //|--------+--------+--------+--------+--------+--------+--------|  |--------+--------+--------+--------+--------+--------+--------|
                                          KC_LGUI, _______,  KC_SPC,     KC_ENT, _______, KC_RALT\
                                      //`--------------------------'  `--------------------------'
  )
};

キーキャップが待ちきれなくて

この右下のトンガリがちょっと気になる pic.twitter.com/W0A0z67cns
— Jun Ohtani (@johtani) October 30, 2020

キーキャップが待ちきれなくて上海問屋のキーキャップを付けてみて、いろいろ試行錯誤してみました。

あー。上下関係ないのか。だからみんなこんな感じにしてるのか？ pic.twitter.com/KTBlPLespr
— Jun Ohtani (@johtani) October 30, 2020

どのくらい離すのが良いか実験中 pic.twitter.com/ozK4WyBXY8
— Jun Ohtani (@johtani) November 2, 2020

キーキャップもいろいろあるのね

届いた。 pic.twitter.com/jccNW1ZcEM
— Jun Ohtani (@johtani) November 2, 2020

もう一個 pic.twitter.com/9y6qat4JiN
— Jun Ohtani (@johtani) November 2, 2020

とりあえずセミコロンの位置につけてみた。 pic.twitter.com/TDk5213IHi
— Jun Ohtani (@johtani) November 3, 2020

今はこのDSAプロファイルの青いグラデーションのキーキャップを使っています（Dukeはここにはいないですｗ）。キーキャップのプロファイルはこれまた、サリチル酸さんのブログがわかりやすく書かれています（ほんとすごいなぁ。）。

高さ調節

そのまま使っていたのですが、やはりもうちょっと奥側に高さがほしいなと。ダイソーなどで打っているケーブルクリップがお試しには良さそうだったのでこんな感じで内側がちょっとだけ高くなるような感じにして使っています。

こうなった。とりあえず仮運用 pic.twitter.com/VkhjawdhLM
— Jun Ohtani (@johtani) November 4, 2020

まとめ

ということで、駆け足ですがCorne Light v2のビルドログでした。いきなりフルキーボードから40％キーボードかつ異なる並びにしたので、混乱しっぱなしですが、いい頭の運動になっているし、なにより作って動かすまでの間にいろいろと調べたり試行錯誤できたのがすごく楽しかったです。

あとは、スプリット型＋Column Staggeredになったので「c」や「b」を間違えまくっていますが、いい気付きでした。まだまだ記号とかの入力に慣れていないですが、ちょっとずつ身に着けていけたらなと。

ただ、もう次のキーボードをDIYしたい気持ちも出てきているので困っているところです。

書ききれてないこともあるかと思うので、ここはどうしてるの？これはどうやったの？などあれば、Tweetなりコメントなりを頂けたらなと思います。いやぁ、DIYキーボード楽しいわ。

Windowsへの移行（その１）

Sun, 18 Oct 2020 23:01:50 +0900

ヒゲが不評だったのでいつも通りの長さに切りました。

前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので現状を忘れないようにブログに残しておきます（また同じ作業する予定なので）

インストールしたものたち

今のところインストールしたのはこの辺。特にコメントしたいものについてこのあと明記します。

ドライバインストール from CD
MX Ergoのソフトインストール。接続はコネクター
Windowsアップデート
Chrome
Visual Studio ビルドツール(Lindera用)
JetBrains Toolbox
- IntelliJ
- CLion
- Rider
Visual Studio Code
Slack
Teams
Google Drive共有
Gitter
~~Divvy for Windows~~
Zoom
DeepL
Sophos
Twitter for Windows
Office 365
AutoHotKey
WSL2 - Ubuntu
Windows Terminal
Rustup
Git for Windows
wsl-ssh-agent
PeaZip
Speccy
Hugo (WSL2のUbuntuにapt-get install hugoした)
PowerToys

AutoHotKey

前回のブログに書いたように、カーソル系のEmacsショートカットが体に染みついて離れないのです。そこで、ググって見つけた記事はこちら。 AutoHotKeyというツールが Windowsに常駐して、特定のキー入力の時に、別の操作を実行してくれるツールです。

見つけた記事にあった、https://github.com/lintaro-jp/gtk-emacs-theme-like.ahkのキーマップをもとに、いくつか変更したものを使用させていただいています。

書き換えたのは、以下の通りです。

Ctrl+\でIMEの切り替え（Wnn風）
Ctrl+kをEmacsと同じ挙動に（もとにしたキーマップでは、カーソルから行末までが削除されてしまう）
Win+sでもファイル保存（Ctrl+sと同じ挙動に。デフォルトではCortanaが起動して邪魔くさいので）

すごく快適です。そのうち、もう少し自分が使いやすいようにキーマップを追加していったりするかもしれません。特に、Macのショートカットがしみついているものについてなどです（仮想デスクトップ切り替えとか？）

PowerToys

Divvyをインストールしたのですが、グローバルショートカットがうまく動かなくていまいちでした（なんでだろ？）そこでググって見つけたのが@ITのPowerToysの記事でした。 PowerToysはMS製のOSSツールで、GitHub上で公開されています。中には「ColorPicker」、「FancyZones」、「File Explowrer Add-ons」など、複数のツールが入っています。「FancyZones」です。

Windowsでは、デフォルトで、アプリにフォーカスしているときにWin＋カーソルでウィンドウの配置場所をいくつか（左右どちらかに半分、4分の1(右上、左上など)）に配置してくれるAero Snapというものが動いています。が、上半分などデフォルトにない柔軟な配置を設定することができません。 MacではDivvyというツールをいれて、それを実施していたのですが、先ほど書いたようにWindows版はあるものの、なぜかグローバルショートカットが動かず、システムタスクトレイのアイコンをクリックしなければいけませんでした。

それを解消してくれるのがFancyZonesです。 FancyZonesの設定項目で、自分で画面上にどのような割り当て領域を作るかを設定できます。さらに、マルチディスプレイ、仮想デスクトップを使っている場合、それぞれのディスプレイかつ仮想デスクトップで個別にレイアウトが設定できるようになります。レイアウトを設定した後は、Shiftキーを押しながらウィンドウを移動すると、設定した領域が出てきて、あとは、割り当てたい領域にウィンドウを移動するだけでその領域いっぱいにウィンドウをリサイズしてくれます。また、設定を変えることで、Shiftキーを押さなくてもウィンドウ移動するだけで領域にリサイズすることも可能です。また、Aero Snapの機能をオーバーライドしてWin＋カーソルで動作させることも可能になります。

WSL2 + Windows Terminal

三宅さんからコメントを頂いたので。

もう少し幅広い感じですかね。あわせて Windows Terminal 使うとわりと快適です。
— miyake / ZEN (@kazuyukimiyake) October 15, 2020

なんとなく噂は聞いていましたがということで、MSのドキュメントを見ながらインストールしました。クイックスタートに則って作業するだけで特に問題なくUbuntuまで無事インストールできました。 Windows Terminalも同様です（クイックスタートで入れることになる）。

Git for Windows + wsl-ssh-agent

少してこずったのがこちらです。チュートリアルに記述はあったのですが、どちらで作業するのか？などが少しわかりにくかったので。ググって出てきた記事をもとに作用しました。

RustのプロジェクトファイルをMacから丸ごとコピーしていたのですが、Git for Windowsを入れるまでは、CLion+Rust pluginの環境では、.gitファイルをきちんと認識してくれませんでした（この時WSL2と少し混同してた）。

無事環境は用意できました。作業の手順は以下のような感じです。 Macで使用していた.sshのディレクトリを持ってきて作業しました。

Windows側での作業

Macから.sshディレクトリをc:\\Users\johta\にコピー
Git for Windowsのインストール
OpenSSHクライアントの設定
- 管理者権限でコマンドプロンプトを起動して
  - sc config ssh-agent start=auto
  - sc start ssh-agent
[wsl-ssh-agent(https://github.com/rupor-github/wsl-ssh-agent)のインストール
- ダウンロードして.7zファイルを展開
- wsl-ssh-agent-gui.exeとnpiperelay.exeをc:\\Users\johta\binに移動
- c:\\Users\johta\bin\wsl-ssh-agent-gui.exeのショートカットをスタートアップに作成
- 作成したスタートアップのリンク先に -setenv -envname=WSL_AUTH_SOCKを追加
Git BashでOpenSSHを利用するように設定
- setx GIT_SSH C:\\Windows\system32\OpenSSH\ssh.exe
ssh-addで秘密鍵を登録
- ssh-add .ssh/id_rsa

WSL2のUbuntuでの作業

Ubuntuはgitがすでに入っていたのでインストールはスキップ
git config --global user.name "Jun Ohtani"
git config --global user.email "メールアドレス"
mkdir .ssh
.bashrcの最後行にwsl-ssh-agentのWSL2 compatibilityにあるexportからfiまでをコピー。この時、パスを自分のパスに変更すること(私の場合$HOME/winhome/.wslの部分を/mnt/c/Users/johta/binに書き換えました)

これで、WSL2側では.sshのファイルを管理しなくても、Windows側のOpenSSHに接続してssh周りの処理をしてくれるようになりました。

PeaZip

wsl-ssh-agentが.7z形式で圧縮されていたので、ダウンロードしました。とりあえずこれを入れてみたのですが、ほかにお勧めがあれば教えてほしいです。

Speccy

CPUの温度やスレッドごとのCPU使用率などを見てみたいので入れてみました。これもとりあえず入れてみた感じなので、ほかにお勧めのソフトがあれば教えてもらえればと。リソースマネージャーでもスレッドごとのCPU使用率は見れたのですが、温度が見れなかったので。

Hugo +

WSL2にあるUbuntuにsudo apt-get install hugoしてインストールしました。

そこで、VS Code の Remote Extension です。WSL2 から ‘code’ で起動できます😎
— Daiyu Hatakeyama@Microsoft, Hacking Generative AI (@dahatake) October 17, 2020

あとは、畠山さんに教えてもらったVSCodeのRemote - WSLを入れて、 WLSに接続した状態でVSCodeを起動して記事のMarkdownを書くと、VSCodeのターミナルを開くとWSL2に接続してくれて、hugoコマンドが実行できます。

まとめ

とりあえず、ブログが書ける環境ができました。 Mac上にあった各種プロジェクトのディレクトリをコピーして、Rustの開発もできるようになりました。

今後も環境構築は続いていきます。Javaとか入ってないし。 SDKMan使ってたけど、切り替えどうしよう？とか。

そういえばSDKMAN!をJDK切替に使ってたけど、結局windows側のパスは通らんので自力インストールになった。scoopがよさげ
— きしだൠ(K1S) (@kis) October 17, 2020

IDE系から呼び出すターミナルはWSL2がいいなぁとか。

https://t.co/X4Jj4tih1I
— そーだい@初代ALF (@soudai1025) October 17, 2020

ほかにもおすすめなどがあれば教えてください！

Windowsをお試し中

Thu, 15 Oct 2020 11:04:02 +0900

ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。

自宅で作業することが多くなってきたので、自作PCでもと思っていますが、OSをどうしようか悩み中。とりあえず、試しにWindowsにしてみるかということで、10年ぶりくらいにWindowsに帰ってきました (この文章はMacで入力してますが)。

むかしむかし

もともとはWindowsを使っていたのですが、Win7くらいに32bitと64bit混在の時期に、 Xkeymacsを利用するときに少し手間がかかるなぁと思ったのもあり、Macに移行しました。 Macだと自分がよく使うEmacsっぽいショートカットがデフォルトいろんなアプリで使用できる利点があったからです。

ただ、最近、TL上で光るPCとかを見てしまったのもあり、自作PC(どちらかというとDIYかな?)熱が復活しました。まだ、OSをWindows、Ubuntuのどちらをメインにしようかな?と悩んでいるところではありますが、まずはWndowsをちょっと試してみるかなと。

まずは、やりたいことをちょっとリストアップしておこうかなと思います(きっと、先人の知見が集まってくるはず!)。

どうしてもほしい機能

大学の頃にSunOSやSolarisを使用し、Emacsでメールを読んだしていたせいで、Emacsのショートカット操作が体から抜けない状態です(抜こうとしてないという話もあるが)。ですので、社会人になってからWindowsを利用していたときはXkeymacsというソフトのお世話になっていました(神アプリでした。まだあるのかな?)。

ショートカット操作とか

カーソル移動(必須)
- 上下左右：Ctrl+n、p、f、b
- 行頭、行末：Ctrl+a、e
編集
- デリートキー：Ctrl+d
  - Ctrl+hがバックスペースだけど使わないな、そういえば
- カーソルから行末までをカット：Ctrl+k
  - 必須!

カーソル移動がホームポジションから移動しなくてもいいのもあって、多用してしまっています。これ、WindowsとかUbuntuでいい感じにできるのあるのかな? できれば、IMEやブラウザのURLのサジェストなどもこのカーソル移動で移動できると嬉しいです。 (昔はM-%とかで置換などもやってたけど最近はやらないな。)

デスクトップ操作系

仮想デスクトップ
- やることごとにデスクトップを切り替えて使うので
ウィンドウのリサイズ?
- DivvyというアプリをmacOSで利用中
- 自分で登録したサイズ(例：画面右半分)にウィンドウサイズを変更などがショートカットで可能

仮想デスクトップはあると思うけど、ウィンドウのリサイズの便利なツールあるかなぁ?

利用するアプリ

SNS、オンラインミーティング

Twitter
- macOSではTweetDeckと夜フクロウを使用
Slack
- ネイティブアプリ
Gitter
- ネイティブアプリ
Chatwork
- ブラウザ
Teams
- ネイティブアプリ
Zoom
- ネイティブアプリ
Google Meet
- ブラウザ
Discord
- ネイティブアプリ(最近使ってないな)

色々使ってますが、最悪ブラウザで使う感じかな?

オンラインストレージ

Google Drive
- 同期アプリ使ってる
Dropbox
- あんまり使ってない

開発系

JetBrainsのIDE
- Toolbox App
- IntelliJ
- CLion + Rust plugin
- Rider
zsh
- macOSで標準になったから
コマンド系
- git
- SDKman
  - ant
  - gradle
  - JDK
- Rust
- Hugo
Jasper
- GitHubのIssueとかを見るネイティブアプリ
- 自分が関連しているIssueとかが楽に見える(メールだと埋もれてしまう)

エディタ

Visual Studio Code
- 開発系では?と思われるかもだけど、Markdownエディタとして使ってる
Emacs by Homebrew
- 最近は起動してない

その他

カレンダー
- macOSのカレンダーで複数のGoogleカレンダーを取り込んでる
ScanSnap
- Ubuntuで使えるやつあるのかな?
- Mac miniにつないであるので、画面共有とかで入れればそれでOK
画面共有
- winやubuntuからMac miniとか見えるかな?
キーボード共有
- macも使うので、KVMスイッチとかかな?
マウス共有
- MX ErgoのFlowを使うと行き来が簡単にできたので良さそう。
- ただし、Ubuntuだとどうなるのか?
システム監視系
- CPUの温度とかCPU、メモリの使用率とか

まとめ

とりあえずこんなところです。カーソル移動系が一番重要なので、そのへんから色々とちょっとずつ試していく予定。ぜひオススメアプリとかあれば教えていただければと。

Dozen0を作成した #DIYキーボード

Sun, 11 Oct 2020 23:53:26 +0900

今年の春くらいから、セパレートタイプのキーボードが気になっています。また、なんか知らないですが、Twitterのタイムラインが自作キーボード(DIYキーボード)で盛り上がってる気がします。 (たぶん、気になってるから余計目についてる)。これとか。このスライドから、自分がやってるのは「まだ」DIYキーボードだなということで、タイトルに使ってみました。

#toruby "DIYキーボードは実質Ruby" 本日のスライドです! とちぎでこの話をできてよかった!!!q: https://t.co/RJot71Ngu9
— Kakutani Shintaro (@kakutani) September 12, 2020

セパレートタイプのキーボード

今年の夏まではMac Book Pro 16インチのキーボードを利用していました(参考:自宅の作業環境(2020))。これまで、自宅で作業することよりも、外で仕事をすることが多く、また、外といっても様々な場所(サムライズムだったり、オフィスだったり、カフェだったり)で作業をすることが多かったので、ノートPCのキーボードにしていました。流石にキーボードを持って歩くほどは気にしていなかったので。

ただ、コロナウイルスの影響もあり、ほぼ自宅で作業することとなりました。となると、前から気になっていたセパレートタイプのキーボードが俄然気になり始めます。 (といいつつ、寄り道してたりしますが)

気になっていたのはこのあたりなのですが、

流石にいきなり行くにはちょっと気が引けるなぁと(なかなかいいお値段)。また、自分が日本語キーボードを利用しているというのもちょっとあります。

キースイッチの感触を知りたくて

ただ、日々、楽しそうな自作キーボードの記事や画像が流れてきます。で、思い出したのが自分の趣味。プラモデルです。色を塗ったりはしないですが、組み立てるのは楽しいなと。じゃあ、趣味と実益を兼ねればいいのでは?(ほんとか?)となり、作る気になってきました。

ただ、全く知らない世界だし、どんなものなんだろう?と。市販のキーボードでも、キーの押し具合が色々合ったり、形もまちまちです。また、このご時世ですので、自宅からあまり出ていないので遊舎工房さんなどに遊びにも行けず。

そんなところに流れてきたのがキースイッチのテスターでした(世の中誘惑だらけ)。

スイッチテスター人気スイッチ詰め合わせ 18個セット

「なるほど、これでどんな感触かわかるじゃないか!」と、気づけばポチッと押していました。。。届いて、「ふむふむ、これがこういう感触なのか。なるほど」ポチポチ押しながら、さらに自作キーボードについて調べていきます。

いろんな感触なんだなぁ pic.twitter.com/PaGDMIRJiv
— Jun Ohtani (@johtani) September 22, 2020

キースイッチのストロークの深さを知りたくて

まぁ、当たり前なのですが、先程のキースイッチテスターどこにもつながっていません。キーボード触ってるとわかりますが、ストロークが違いがあるんですよ。ただ、これだとわからない。けど知りたい。

で、ググっているとArduinoを使ってLチカやってる人とか、キー入力させている人がいるじゃないですか。これでは?そういえば、Arduinoもどきうちにもあるぞ?と。で、準備をしていたときに見かけてしまったのがこのツイートでした。。。

https://t.co/ALl7OcRVRa 高機能テスターとしてもおすすめ
— Kakutani Shintaro (@kakutani) October 4, 2020

やられてしまいました。。。

dozen0作りました

ということで、前置き長かったですが、Dozen0というキーボード(マクロパッド?)を遊舎工房さんから購入して作ってみました。手順はビルドガイドという形でまとまっています。

基本的にはこれに沿って作成しました。

パーツと手順の確認

さてと。 pic.twitter.com/GTBJ7zDleN
— Jun Ohtani (@johtani) October 10, 2020

まずは入っているパーツがきちんとあるか確認します。また、ビルドガイドでどんな作業があるのかをざっと眺めておきます。まぁ、プラモデルといっしょですよね。

キットにはキースイッチとキーキャップは含まれていません。これはご注意ください。私は、キースイッチテスターとして入手していたキースイッチとキーキャップがどんな押し具合なのかを確認したかったので特に問題ありません。

ハンダづけ

Amazon | 白光ダイヤル式温度制御はんだこて FX600 | ハンダゴテ

Amazon | 白光こて先 2C型 T18-C2 | ハンダゴテパーツ

Amazon | 白光(HAKKO) セラミックヒーターはんだこて専用こて台クリーニングスポンジ付き FH300-81 | ハンダゴテパーツ

Amazon | goot(グット) 高密度集積基板用鉛入りはんだ Φ0.6mm スズ60%/鉛40% ヤニ入り SD-60 | ハンダゴテ

はんだ付け用に揃えた道具です。「自作キーボードハンダゴテ」とかでググると出てきたものがこれだったので。デフォルトのコテ先ではなく、2Cのコテ先に付け替えてから作業を開始しました。

私の持っていたソケットはCherry MX系なのですが、気が向いたらKailh Chocも試したくなるかも?ということで、すべてはんだ付けしました。本格的にはんだ付けしたのは大学以来だからもう20年近く経ってますね。ソケットの足をプリント基板にはんだ付けするのですが、2Cのコテ先が大きくなかなか手こずりました(これがこのあと問題を引き起こしました)。

ソケット、リセットスイッチ、ProMicroをはんだ付けすればはんだの作業は終了です。

pic.twitter.com/jjUo162n54
— Jun Ohtani (@johtani) October 10, 2020

pic.twitter.com/p5atvtHfFN
— Jun Ohtani (@johtani) October 10, 2020

スイッチの取付と組みたて

試したいキースイッチを選んでトッププレートにつけていきます。

キーテスターからスイッチとキーキャップ持ってきて完成。動作確認はまだなのでまた、最初に戻るかもだけど、、、 pic.twitter.com/ZmBd3bgOKI
— Jun Ohtani (@johtani) October 10, 2020

組み立ても終わり次は実際の動作確認です(ツイートしていますが、予想通りの展開でした)。

ファームウェアの書き込み

USBで接続して、ファームウェアの書き込みです。書き込み手順はビルドガイドにありますが、QMK Toolboxの使い方やQMK Configuratorの使い方は以下のサリチル酸さんのブログがわかりやすかったです。

実際に書き込んで動かしてみると。。。。

うーん、上半分が死んでる気がするなぁ。
デフォルトキーマップの書き込みはできたけど、カーソルの上とかバックスペースが入らないw
— Jun Ohtani (@johtani) October 10, 2020

とりあえず、もう一回確認してみた。デフォルトのキーマップで、「Cut」「Paste」が強く押さないと入力されない。UpとDeleteは動くようになってた。CopyとBkSpがうんともすんとも言わない。下段のキーは全部動く。https://t.co/zEyINdAK6t
— Jun Ohtani (@johtani) October 10, 2020

といった具合に上半分が動作があやしいです。

再度、はんだ付け

ということで、ネジを外して上の段のソケットをはんだで温めてみると、片側だけ温めるとはずれるじゃないですか。どうやら、うまくソケットの足が基盤にはんだ付けできていなかったようです。この時、最初に作業したときに2C型のコテ先が大きくて、ソケットの足に入らなかったのを思い出したので、最初にはんだごてについていたコテ先に戻してから作業をしました。これだとソケットの足の隙間に入るんです。ということで、挙動のおかしい上段のソケットをすべてつけ直したところ無事動作しました。

上の段、全体的にソケットがうまくはんだ付けできてなかったみたいだった。今回はMX系のスイッチしかないので、Kailh Chocのソケットの導通は未確認。ざっとブログにまとめるか。
— Jun Ohtani (@johtani) October 10, 2020

現在のキーマップ

これが今のキーマップです。仕事中のBGMをラズパイ4の音楽プレーヤーで流していますが、部屋から出るときや、打ち合わせがあるときに音楽の停止、開始などを画面共有経由でやっています。が、わざわざマウス移動するのもめんどくさいなと。これに使えそうだというのもあったので、Dozen0を購入したというのがあります。残念ながら、Prev Trackとかがうまく動かないので、ショートカットを調べてキーマップ書き換える予定ですが、非常に便利になりました。

まとめ

ということで、Dozen0を作ってみましたが、楽しかったです。すんなりと行かなかったのがまた良かったです。試行錯誤して動いたときの喜びが何倍もありました。また、キースイッチの感触も知ることができました。たぶんGateron Silentクリア軸もしくは赤軸くらいが良さそうだなぁと(こうやって沼へ。。。)。キーマップの仕組みを調べたり、もっと面白い使い方できないかな?と探りつつ、次のステップに進もうかなと。

次は本格的なセパレートタイプのキーボードを作る予定です。が、お店のオープンを待ってからということになってます。はやくオープンしないかなぁ!!

がんばって!!
— Jun Ohtani (@johtani) September 29, 2020

LinderaのFSTをDoubleArrayTrieに変更した話

Mon, 05 Oct 2020 11:36:18 +0900

2020/10/06 11:00くらいにマージされました。

@minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ) 。最近趣味でRustを勉強しているので、こちらを少し手伝っています。

Rustの勉強仲間である@takuya_bさんや@ikawahaさんと話をしているときに、FST部分をDouble Array Trieに置き換えると速度が向上するのでは?という話が出まして、@takuya_bさんがDouble Array Trieを作るらしいという話になったので、下準備などをしつつ、作ってもらったライブラリyadaを組み込んでみたという話です。

ベンチマークの追加

下準備として、今のLindera(FST実装)がどのくらいの性能なのか?というのを計っておく必要があります。幸いにも、Linderaのオリジナルの開発者の方が、criterion.rsというライブラリを使ったベンチマークプログラムを作成してくれていました。

ただ、1種類だけだと少し心もとないなというのと、長い文章やパターンを増やしたほうが良さそうだなということで、ベンチマーク自体をいくつか追加しました(追加したときのPR)。

種類としては、5種類のベンチマークです。

システム辞書のみのTokenizerのコンストラクタ呼び出し
カスタム辞書ありのTokenizerのコンストラクタ呼び出し
システム辞書のみのTokenizerのtokenize処理の呼び出し
カスタム辞書ありのTokenizerのtokenize処理の呼び出し
青空文庫の坊っちゃんのテキストをシステム辞書のみのTokenizerでtokenize

1,2はコンストラクタ部分だけの処理をベンチマークテストする目的で作成しました。 LinderaはTokenizerがtokenize処理するのに利用するデータをいくつか内部で保持しています。これらはファイルにシリアライズされており、Tokenizerのオブジェクト生成時に読み込みやデシリアライズ処理が発生します。この部分だけも速度を計測したい目的でコンストラクタだけを切り出しました。

3,4はTokenizerのメインの処理です。コンストラクタはベンチマークの対象外にしました。純粋にtokenizeの処理だけを切り出して計測するためです。カスタム辞書がある場合、ない場合は念の為切り出した形になっています。

5は長い文章(文章が多いのでバリエーションも増える)を扱いたいために別にしました。

これで、一応下準備が完了です。ちなみに、Criterionは賢くて、前のベンチマークの結果と最新の結果を比較してくれる機能があります。どんな感じで出てくるかはベンチマーク結果をご覧ください。

yadaの組み込み

ベンチマークの準備をしていたところyadaがリリースされたので、Linderaへの組み込みを検討し始めました。

というわけで、またダブル配列を書いてしまったので crate として公開しました。フィードバックお待ちしております！ https://t.co/As7h0tfmjf
— takuya-a (@takuya_b) September 20, 2020

中身の理解

lindera-fstを利用して、prefix searchしている処理があるので、そこで利用しているFSTをyadaに置き換えれば良さそうだと判断して、処理を読んでいきます。

Tokenizerは、PrefixDictという構造体でlindera-fstを利用している
- prefixメソッドが入力文字列を元に、FSTを前方一致検索して、ヒットした単語の情報をIteratorとして取り出せる(単語の情報は「入力文字列の先頭からの文字数」と「ヒットした単語のWordEntry構造体」)
- PrefixDictのfstは辞書(例：ipadic)ごとにlindera-<辞書名>-builderで生成される
システム辞書としては、デフォルトではlindera-ipadic-builderでfstを構築している
- 構築処理はこの辺

という感じです。また、辞書周りのファイルがそれぞれどんな役割なのか、どんなデータの持ち方をしているのか?といった点を、変更点の調査のついでに書き出してみました。lindera-dictionary/FILES.md。TODOになっている部分も追記が終わっています(PR)

変更点

実際に変更したプログラムの詳細についてはのPRを見ていただくとして、簡単には以下の点になります。

Rustのバージョンを1.46.0に(おもにREADME.md)
- yadaが利用している機能に1.46.0で導入された機能があるため
lindera-fstをyadaに変更(lindera-core/Cargo.toml, lindera-ipadic-builder/Cargo.toml)
- 合わせて、dict.fstというファイル名をdict.daに変更
dict.daに関して構築部分と検索部分を変更
- FSTではFSTから返ってくる値(入力文字列に出てきた単語に関連する値)はu64だったが、yadaのDoubleArrayがu32しか扱えないため、u32に変更。テストの記述はしていないが、扱うデータ的にu32で問題なさそうだったので。
- 検索部分：PrefixDict構造体のprefixメソッドでDoubleArrayのprefix_common_searchを使用
  - DoubleArray自体がprefix_common_searchのメソッドを持っていたので、処理が簡単に置き換え可能だった。FSTはprefixメソッド内で独自で前方一致検索を実装していた。
- 構築部分：lindera-ipadic-builder/src/lib.rsのbuild_dictとbuild_user_dictのdict.da構築処理
  - ipadicのCSVファイルを読み込んで、見出し語をキーに、辞書にある単語情報のベクタを値とするBTreeMapを生成し、このBTreeMapに基づいてFSTを構築していた部分をDoubleArray構築処理に置き換えた。
  - シフト演算などで、実際の値(dict.vals)へのポインタを作っていたのだが、ここの処理を読み解くためにFILES.mdを書き出した。

という感じです。そもそもデータ構造がどうなっているのか?から読み解いて、変更部分を洗い出して変更していった形になります。取り込み作業中にいくつかyadaに要望(このへん)を上げて、変更を取り込んでもらい、最終的にyadaのバージョン0.3.2で問題なく動きそうだという形になりました。@takuya_bさん、対応ありがとうございました。

エッジケースバグの発見

作っててよかった、テストケースでした(実際にはベンチマークテストですが)。取り込み作業中に、Lindera本体のcargo testはすべてOKになるが、ベンチマークを取ろうとしたときに、坊っちゃんの文字列を入力にしたベンチマークが失敗するという事象が発生しました(PRのコメント参照)。切り分けのために、入力の文章のどこでおかしくなるのか?DoubleArrayのbuildメソッドに渡している値がおかしくないか?などをすこしずつ調べていくと次のバグが判明したという感じです。

特定のデータ(ipadicの見出し語一覧)をDoubleArrayに入れて、特定の文字列(「は相」)をcommon_prefix_searchにいれたら、返ってくる情報(0から何バイト目の文字が一覧に存在した)が、不正な値が返ってくるというバグでした。 @takuya_bさんに見てもらいつつ(DoubleArrayの中身わからん。。。)、修正してもらいました。素早い対応ありがとうございます。

yada 0.3.1 をリリースしています。特定の条件で不正な遷移を許すダブル配列が構築されてしまうバグを修正しています。このエッジケースは @johtani さんが見つけてくださいました。ありがとうございました！ https://t.co/CiftZi5GDn
— takuya-a (@takuya_b) September 30, 2020

やはり、いろんな文字列入れてテストしてみるの重要ですね。ということで、ベンチマークだけでなく、テストケースとしても坊っちゃんのファイルを読み込んでトークナイズするようにPRでテストケースを追加しています。

ベンチマーク結果

yadaを利用した変更が終わったので、再度cargo benchを実行して計測です。計測としては、masterブランチでまずcargo benchを実行し、yadaの実装をしたブランチに切り替えてからcargo benchを実行します。すると、Criterion? cargo benchが、最終的な結果に前回との差分でどのくらい性能が改善、改悪したかも合わせて出力してくれます。実行環境と結果は以下のとおりです。

MacBook Pro 16インチ
- CPU：Core i7 6コア 2.6GHz
- メモリ：32GB

コンストラクタのベンチマークについては10%ほど性能が悪くなっています。これは、FSTよりもDoubleArrayTrieのほうがデータが大きくなってしまうためだと思われます。実際にファイルのサイズは次のようになりました。yada(DoubleArrayTrie)のほうが2倍以上大きいことがわかります。また、このファイル以外にもLinderaが利用しているデータはありますが、それらは今回変更の対象にはなっていません。なので、単純にこのファイルの読み込みの処理に時間がかかっているのだと想像できます。

2147765 / FST / dict.fst
5425152 / yada / dict.da

tokenizeのベンチマークについては、11%〜28%の改善が見られました。文章から、内部に保持している辞書に存在する単語を見つけ出す処理に利用されるのがFST、DoubleArrayTrieです。今回の変更では、この処理に利用しているデータ構造だけを変更しました。実際には

DoubleArrayTrieを用いた単語の検索処理
見つかった単語の持つ値(data.valsのオフセット情報)を元にシフト演算

といった処理が実行されます。シフト演算はu64だったものがu32に変更されたくらいなので、大した処理量ではないかと。大部分はDoubleArrayTrieを利用したルックアップ処理が速度向上に寄与していると思います。

まとめ

最近Linderaに加えた変更、作ったPRについて少しブログにまとめてみました。ちなみに、まだPRの段階でレビュー&リリース待ちという感じです。

実際には作ってもらったライブラリを組み込んでみたというだけなのですが、速度が向上した結果が見れたのは面白いです。また、基本的なデータ構造とかアルゴリズムの勉強にもなりました(2次元配列を1次元配列に押し込むとか)。このへんも今後も勉強していきたいです。

組み込む際に色々と協力していただいた@takuya_bさん、@ikawahaさん、巻き込んでくれた@minoru_osukaさんに改めて感謝いたします。

Rustや形態素解析のプログラムの勉強を兼ねて、今後もなにか改善できる部分がないかなどを見ていこうと思っています。 Rustで形態素解析をしたいという人がどのくらいいるかはわかりませんが、おかしなところや疑問点などあればコメントください。

本当にその検索は自分が想像している検索になってますか？

Sat, 19 Sep 2020 00:00:00 +0000

検索対象のデータとデータソース(検索システムに関する妄想その3)

Tue, 15 Sep 2020 11:23:34 +0900

先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。

大体、検索がうまくヒットしないといった場合に、問題になるのがコンテンツ自体のデータもしくは、転置インデックスのキーワードだったりします。そこで今回は、前回のパーツの「データソース・コンテンツ」周りについて少し書いてみようと思います。言葉の定義、それぞれがどんなことをやるのか、とりあえず導入したあとにコンテンツ周りでどんな改善ができるかなどを書いてみます。

言葉の定義

コンテンツ

実際に検索させたいデータになります。コンテンツにはWebページ、データベースのレコード(CMSで登録されたデータなど)、ファイルサーバーにある文書(PDF、Word、Excelなど)などになります。

データソース

コンテンツのマスタデータが保存されている先です。よくあるデータソースとしては以下のものが考えられます。

Webサイト - 自社もしくはインターネットに存在しているWebサイトです。
ファイルサーバー - ローカルネットワーク上のファイルサーバーもありますが、最近ではGoogle DriveやDropboxといった外部のWebサービスもあります。
RDB - CMSや自社システムでのデータの保存先です。

クローラー

コンテンツをデータソースから収集してくるプログラムのことです。 Webサイトやファイルサーバーからコンテンツを収集して検索エンジンに登録するところまでを担当します。 RDBにあるデータを検索エンジンに登録する場合はクローラーがデータを登録するというよりは、RDBにデータを登録するシステムが検索エンジンに登録する機能を持っていることが多いです。

データの収集と登録

収集

クローラーを使用した収集の場合は、サービスの特性とデータソースによって、どの程度の頻度でクロールするのか、クロール対象はどこまでか?といったものを決める必要が出てきます。これらが決まれば収集ができるかと(他に権限とかもありますが。)。収集コンテンツは、そのままでは利用しにくかったり、利用できないことがあるので、次はデータの変換を行います。

データ変換

コンテンツはそのままの形では検索エンジンには扱いにくいデータ形式である場合があります。

Webページの場合

Webページの場合、コンテンツにはHTMLタグが入っていたり、JavaScriptなど検索対象にはしたくないデータなどが入っています。これらを除去して、検索させたいものを取り出す必要があります。また、Titleタグなど、いくつかメタデータとして扱えるものがHTMLで規定されているので、これらを別の項目として取り出して個別に検索できるようにすると便利です。 HTMLをパースしてデータを抜き出す処理ができるライブラリなどがあるので活用します。

ファイル

PDFファイルなど、ファイルの場合もメタデータと呼ばれるファイル自体が持っている情報が存在します。作成者、更新日時、ファイル名、パスなどです。これらも検索時に有効な情報になります。また、ファイルから文字列を抜き出す処理も必要になります。それぞれデータフォーマットが異なりますので、そのフォーマットに合わせて文章データを抜き出す処理が必要です。OSSや製品がありますので、それらを利用して、ファイルから文章を抜き出します。

RDB

RDBのデータの場合、データが正規化されています。検索エンジンでは、非正規化のデータを登録して検索することが基本となるため、まずは非正規化して取り出す必要が出てきます。

例えば、ジャンルやカテゴリ、各種IDなどが実際のコンテンツのレコードに入っていると思いますが、これらをユーザーが入力したキーワードで検索したい場合などは、IDではなく表示名を取り出して、検索エンジンに登録する必要が出てきます。

その他

データごとの変換処理について説明しました。その他に、データのクリーニング処理などと言ったことも必要になってきます。例えば、HTMLのタイトルに必ずサイト名が入っているが、除去したいといった場合や、検索エンジン固有のデータの前処理などもあります。

登録

最後は検索エンジンへの登録です。最近の検索エンジンはJSON形式でデータを受け取る場合が多いので、JSONに変換することが多いです。基本的には各種プログラミング言語のライブラリが用意されているのでこれらを利用するのが基本となります。

検索したい項目、検索させたい方法などを洗い出し、必要なデータを作成して検索エンジンに登録します。登録と書いていますが、更新、削除などもここでの対象となります。

ここまでの流れで、データソースからコンテンツを取得し、変換して、検索エンジンへの登録が終わりました。

検索の改善

検索のログから分析して改善していくのが良いですが、ユーザーからの質問や意見などからも改善すべき点が見えてくると思います。検索ログでは、次のようなものを元に、検索がうまく行かないものを見つけ出します。

0件ヒット
0件クリック

ヒットしていない検索ワードがある場合、コンテンツに問題がある場合があります。まずはこのあたりをとってみるのが良いかと。そもそも、入力されたキーワードにマッチするコンテンツを扱っていないこともわかりますし、入力されたキーワードに似た単語を持ったコンテンツなども存在するはずです。類義語の辞書を用意して、検索にヒットできるようにするといった分析と改善にも利用できます。

あとは、検索エンジン側の話ですが、形態素解析器などを利用している場合に、意図した区切りになっていないために、うまくキーワードがヒットしないと言ったこともあります。

コンテンツの理解

実はこれが一番だったりします。どんなコンテンツを自分たちが扱っているのか?どんなデータがどういった項目でコンテンツに入っているのか?といったところから、コンテンツのデータを元に検索にヒットさせる方法が改善できます。

CMSなど人が入力したデータをコンテンツとして扱う場合、入力画面を改良することで、望んでいるデータを入れてもらえたり、不要なデータが入らなくなる可能性があります。例えば、ECサイトなどで商品の説明文やタイトルにいろいろなキーワードが入っている場合などがあります。むりやりどんなキーワードでもヒットさせたいという入力者の意図もあるのですが、検索しているユーザーにはノイズになることも多いです。適切にカテゴリやジャンル、属性といった項目に分けることでおかしな入力データを減らすことも可能です。

Webサイトなどをクローリングしたものの場合は、サイトごとに文章の特徴があったり、重複している部分などが合ったりする場合があります。これらもコンテンツをよく調べることで、不要な情報を除去したりといったことが可能になります。

まとめ

簡単ですが、検索のデータソースやコンテンツにまつわる話を紹介しました。もちろんここでは紹介しきれていない項目がいっぱいあります。また、具体例ではなく概略をざっくりと書いているのでわかりにくい場合もあるかもしれません。すこしユースケースを絞り込んで書いたほうがわかりやすくなるのかも?

次はUIとか書くかも?

不明点とか疑問点、指摘事項などあればコメントしていただければと。要望などもお待ちしております。

自宅の作業環境(2020/09)

Tue, 08 Sep 2020 11:17:25 +0900

自宅環境に少しアップデートがあったので更新版です。お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響で出かけることもないので、自室の作業環境が更新されている感じです。前回のブログはこちらです。前回のまとめで触れていた2点について更新されています。

まずは、現状のデスクの上の写真です。

基本的には前回紹介したものと大きくは変わっていません(?)。変わったものについて紹介していきます。

デスク

先程の写真ではちょっとわかりにくいですが、スタンディングデスクになりました。

タイマーついてるの便利 pic.twitter.com/E9engTIMnM
— Jun Ohtani (@johtani) April 30, 2020

Flexispotの天板と足の組み合わせにしました。前のElectaの天板が明るめの色だったのもあって、メープルの天板です。組み立てはちょっと大変でした。足が重たいのと、天板にはネジ穴がなく電動ドライバーもないので、ネジ締めと机を起こすのがちょっと大変です。子供に手伝ってもらいながら組み立て設置をしました。オンラインミーティングなどのときには基本、立って作業しています。あとは、デフォルトのタイマー設定のままですが、45分ごとに立ったり座ったりを数回繰り返す感じです。

Amazon | FLEXISPOT オフィスデスク用天板スタンディングデスク120×60cm

Amazon | FLEXISPOT スタンディングデスク電動式昇降デスクメモリー機能付きブラック EN1B（天板別売り）

スタンディングデスクマット

フローリングに45分立ちっぱなしだと結構、足の裏がつかれるんですよ。なので、クッション性が高いフロアマットを立ってるときは利用しています。ちょっとめんどくさいのですが、椅子のときは壁に立て掛けて、立つときにマットを敷くようにして使っています。

ちなみに、ウレタン素材なので開封直後はすごい匂いでした。。。数日は陰干しみたいなのが必要です、ご注意を。ただ、これを利用してから膝やかかとが痛いことはなくなっています。

Amazon | 疲労軽減マットスタンディングデスクマット滑り止め加工立ち仕事耐水耐油耐菌 (ブラック, 75cm*50cm*2cm)

ケーブルトレー

スタンディングデスクだとケーブルをぶら下げた状態だと危なそうだなということで、ケーブルトレーも机の下に追加してあります。電源タップを配置して、ディスプレイなどの電源はこちらから取るようにして、ケーブルトレーからは電源タップとスタンディングデスクの電源コードを垂らすという感じです。実際にはLANケーブルも伸びてたりはしますが。。。また、後で出てくるラズパイ+SSDも最近こちらに移設しました。最初にチャコールグレーを発注したのですが、配送日が未定になったので、Lサイズのシルバーを発注するという慌てようでした。結局、今は両方使っています。テーブルタップにラズパイと、結構乗せるものがあるんですよね。見えない場所だし、色が揃ってないのは気にならないかなと。

Amazon | プラス Garage ワイヤーケーブルトレー Lサイズ幅63.7cm シルバー

Amazon | プラス Garage 配線ケーブルトレー幅40cm チャコールグレー

キーボード+パームレスト

10数年ぶりに外付けキーボードじゃないかな? 少なくともMacに移行してからは、ずっとMac bookのキーボードを使ってました(極稀にMac mini起動後とかにMagic Keyboard使うくらい)。外出して仕事をすることが多かったのもあり、体をキーボードに合わせる感じでした。

が、ずっと在宅で仕事をしていますし、ふるさと納税でRealforce(リンクは楽天)がということで、申し込んでみました。2週間ちょっとで到着。箱が厳重でびっくりしました。

Amazon | 東プレ REALFORCE SA for Mac ホワイト R2SA-JP3M-WH | Realforce

まだ深いキーに慣れつつあると言った感じです。付属の2mmのキースペーサーでAPCを2.2mmの設定で使用しています。最初は3mm+APC 1.5mmでやっていたのですが、流石にキーが敏感すぎてちょっとキーボードに手をおいたまま考え事をしているだけで「lllllllllll」のようになってしまったので現在の組み合わせに落ち着いています。

あと、特殊な設定としてはスペースの横のeng/kanaキーを設定でキーロックして使えなくしました。どうも、ご入力の原因になっているようだったので。日本語の入力切替は、昨日まではCtrl+Spaceを使用していましたが、このブログを書き始めてからCtrl+\に変更しています。むかーし、使っていたIME切り替えのショートカットです(知っている人は知っているやつ)。

マウスは使用しておらず、キーボードの手前にトラックパッドをおいて使っています。パームレストの部分は、サムライズムさんのトラックパッドがきれいに入るmagicTrayPalmです。 Mac book Proと同じような感じでトラックパッドが使えるのがいいですね。興味がある方は、侍割のリンクをたどってもらうと、初めてサムライズムさんで買い物をする方に限り割引がつくようになってるみたいです(なんと、私もなんか割引になる!)。

ディスプレイアーム

外付けキーボードになったのですが、Mac Book Proの画面も活用したく、さらに上下での配置がやはり目線の移動距離が少ないので気に入っていました。ただ、前回のブログで紹介したアームでは少し高さが足りず。。。思案しながらAmazonを回遊していたら、同じ会社の新しいアームがあり、調べると高さが取れそうだということで付け替えました。アーム2本ありますが、今のところ1本だけを使っています。 2本目のアームにカメラを乗せるのもあり?と思いながらまだ試していませんが。玉突き式に前に使っていたアームがサンダーボルトディスプレイ(縦置き)のアームになっています。前にサンダーボルトにつけていたアームは重量オーバーで悲鳴を上げていたので。。。

Amazon | HUANUO 2画面アームデュアルガススプリング式

スマホ充電器

寝室で利用していた斜めに立てかけるタイプのワイヤレス充電器を作業デスクに持ってきました。実は部屋に時計がなく、Pixel 3 XLを使っているので、スマホの画面に常に表示されている時計を置き時計の代わりに使えそうだなと (スマホで写真を撮っているので上の画像ではスマホがありませんが)。結構便利です。ちょっと時間を確認したいときに、メニューバーの時計では流石に小さすぎるのでw

Amazon | Anker PowerWave 7.5 Stand, Qi ワイヤレス充電器

ミキサー

音声のミキサーです。Yamahaのスピーカーは入力が2系統あるのですが、入力したい音声は3系統あります(ラズパイ4、Mac mini、メインディスプレイ)。2入力を1系統にまとめるプラグを試しに買ってみて、Mac miniとラズパイをまとめてみたのですが、残念ながら切り替わるときに数分無音状態が続くという問題が発生しました。 USB給電できるタイプを購入しました。スライダーとかいらないなと思っていたのですが、電話やミーティング時にBGMの音を下げたりするのに地味に便利だったりします。ただ、スライダーを動かそうとすると本体も動いてしまっていたので、本体裏に滑り止めを貼ってあります。

Amazon | Maker hart Just Mixer ステレオ3入力音声ミキサー/電池とUSB電源可能

Webカメラ

おっさんの顔がきれいに写っても仕方ないんですが、下からのアングルよりはいいかなぁということと、今後の勉強会で使えそうかな?ということで、購入してみました。縦でも横でも使える便利なカメラです。また、あんまりないのですが、部屋の中などを写すときにカメラを持ち回せるの便利ですね。ディスプレイの上に置いてしまうと高さがありすぎるということで、スピーカーの上に乗っけています。仮置きなのですが、このままになるんじゃないかな? 打ち合わせ中は画面共有してることが多いのでオンライン飲み会などで主に活躍してる気も。。。

Amazon | ロジクールウェブカメラフルHD 1080P 60FPS StreamCam C980OW オフホワイト USB-C接続

Mac miniのSSD化

見えないところですが、Mac miniのHDDをSSDに差し替えました。性能検証用のマシンとしてMac miniを利用し始めたのですが、計測するたびに速度の差がありすぎるのでおかしいな?と。よくよく考えてみると、このMac miniはFusion Driveだったんです。。。開発などで使う分には大容量だし便利だったのですが、負荷計測に利用する場合は挙動をハンドリングできないので、弊害でしかないです。。。ということで、頑張って差し替えました。想像以上の大手術でした。「Mac mini HDD 交換」などでググると換装している方たちがいらっしゃいます。興味ある方はググってみてください。

さて、復路 pic.twitter.com/SwndXPoKqn
— Jun Ohtani (@johtani) July 25, 2020

Amazon | シリコンパワー SSD 1TB SATA3 6Gb/s 2.5インチ

ラズパイ4

Mac miniの負荷検証マシン化のため+Linuxを触りたかったというのもあり、ラズパイ4を追加しました。 Mac miniは主な使用用途が音楽再生だったのでラズパイ4で肩代わりできるだろう+その他の検証にもラズパイ4が使えそうだと。現在はUbuntuをインストールして、画面共有で操作しています。

Amazon | RasTech Raspberry Pi 4 4B MicroSDHCカード32G

まとめ

かなり快適になりました。キーボードもうるさくないですし、熱くもありません。マイクのポップガードは意味がなさそうなので外しました。

まだいくつか気になってるものもあるので、また更新するかもしれません。

分離式キーボード - 胸を広げた状態でキーを打ったほうがいいのでは?という気がしています。ただ、最近はずっと日本語キーボードを使っているので選択肢が少ないんですよね。。。
サンダーボルト?USB-C?ドック - MacBook Proのポートがすべて埋まっているし、もう少しケーブルを減らせると幸せになれそうなきが。。。
モバイルディスプレイ - MacBook Proのディスプレイを使っているのですが、キーボードの上にかぶってるんですよね、結構。。。クラムシェルにしてiPadもしくはモバイルディスプレイに置き換えたほうがスッキリはしそうかなと。ただ、Touch IDが使えなくなったり、クラムシェル状態でMacBook Proの電源を入れられないというはなしなので、あまり意味がなさそうだなというのもあります。

meteredクレートの紹介

Mon, 07 Sep 2020 23:11:40 +0900

Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。

そもそもの問題

Rustで処理を書いていて、なんかちょっと遅いな?どこの処理で時間がかかってるんだろう? ということがありませんか?ありますよね?

というのを調べるために、最初に思いつくのは自分で計測する方法です。流石にそれはなぁ、と思ったのでググって出てきた方法を最初は使っていました。

Rustで実行時間計測

3年前の記事ですが、とりあえず計測する分には問題なかったのでこちらの方が書いていたマクロを拝借していました。が、ちょっと面倒なのが戻り値がある処理などのときに、このマクロを挟むのが結構めんどくさいなと。また、処理の時間を測りたいのは基本的にはメソッドや関数単位であることが多いです。

で、さらにググっていて見つけたのが、meteredでした。

どんなもの?

計測したい部分に#[metric]のようなアノテーションを追加することで計測対象としてくれます。あとは、計測したものを保存するレジストリという場所を指定するだけです。処理が終わったタイミングなどで、そのレジストリの内容を出力することで、次の情報を計測することができます。

HitCount : 実行された回数
ErrorCount : エラーを返した数(Resultを戻り値にしているメソッドが対象)
InFlight : 処理中の回数かな?
ResponseTime : レスポンスタイム(処理に何秒かかったか)
Throughput : スループット(1秒あたり何回呼ばれたか)

とりあえず試してみたのは、ResponseTimeとThroughputです。他のメトリクスはまた後日(機会があれば)。また、metered::metric::Metricトレイトというものが用意されているようで、これを実装した独自のメトリクスも扱うことができるようです。

使い方

使い方としては次のようになります。

計測対象となるメソッドがある構造体に、メトリクスを保持するためのレジストリを用意
計測対象にしたい構造体のメソッドに#[measure]を追加(このとき、計測したいものも指定する。)

あとは、実行したあとに構造体をダンプするとメトリクスが出力されます。

レジストリの用意

#[derive(Default, Debug, Serialize)]
pub struct NekoParser {
    metric_reg: NekoParserMetricRegistry,
}

NekoParserMetricRegistryという型はこのあとのimplのアノテーションで指定する名前になります。実際にはこの型の構造体を自分で定義する必要はありません。構造体のderiveでDefaultを指定します。構造体のインスタンス化のときにdefault()メソッドを呼び出して初期化したいためです(おそらくレジストリの初期化をやってくれるのだと思う(要確認))。レジストリの用意はこれだけです。

レジストリの指定と計測対象の指定

計測対象側です。少し長いですが、NekoParserのメソッドすべてを掲載しました。まずは、1行目でレジストリの名前の指定(registry = NekoParserMetricRegistry)、レジストリのフィールド名(registry_expr = self.metric_reg)、レジストリの可視性(visibility = pub(self))を定義します。 2行目では、implブロック全体で計測したいメトリクスを指定しています。今回は、スループットとレスポンスタイムを計測したかったので #measure([ResponseTime, Throughput])]と2種類を指定しています。メトリクスが2種類のため配列で指定していますが、1種類だけの場合は[]の記号は必要ありません。

あとは、計測したい各メソッドに#[measure]をつけるだけです。なお、メソッドごとに#[measure(ErrorCount)]といったかたちで個別にメトリクスを指定することも可能です。今回はお試しということもあり、すべて#[measure]だけになっています。アノテーションを付けただけで、メソッド自体を変更はしていません。

#[metered(registry = NekoParserMetricRegistry, registry_expr = self.metric_reg, visibility = pub(self))]
#[measure([ResponseTime, Throughput])]
impl NekoParser {
    #[measure]
    pub fn load_and_parse_neko(&self) {
        let file_path = "./data/chap04/neko.txt";
        let file = File::open(file_path).unwrap();
        let buf = BufReader::new(file);
        let mut out = File::create("./data/chap04/neko.txt.lindera.json").unwrap();
        buf.lines().filter_map(|item| item.ok()).for_each(|line| {
            let tokens = self.tokenize(line.as_str());
            self.output_tokens(&tokens, &mut out);
        });
    }

    #[measure]
    pub fn output_tokens(&self, tokens: &Vec<Token>, buf: &mut File) {
        writeln!(buf, "{}", serde_json::to_string(tokens).unwrap())
            .expect("Error during output json");
    }

    #[measure]
    pub fn tokenize(&self, line: &str) -> Vec<Token> {
        let mut tokenizer = lindera::tokenizer::Tokenizer::new("normal", "");
        let lindera_tokens = tokenizer.tokenize(line);
        let tokens = lindera_tokens
            .iter()
            .map(|lindera_token| {
                let surface = lindera_token.text.to_string();
                let pos = lindera_token.detail[0].to_string();
                let pos1 = if pos != "UNK" {
                    lindera_token.detail[1].to_string()
                } else {
                    String::new()
                };
                let base = if pos != "UNK" {
                    lindera_token.detail[6].to_string()
                } else {
                    String::new()
                };
                Token {
                    surface,
                    base,
                    pos,
                    pos1,
                }
            })
            .collect();
        return tokens;
    }
}

計測結果の出力

最後は計測結果の出力です。今回はテストメソッドで実行して結果を出力する処理を書きました。

let parser = NekoParser::default();で構造体をインスタンス化します。あとは、処理をそのまま実行します。

最後に出力結果をJSON形式の文字列にしてから出力しました。 let serialized ... println!("{}", serialized);という形です。簡単ですね!

#[cfg(test)]
mod tests {
    use crate::chapter04::answer::NekoParser;
    use std::path::Path;
    #[test]
    fn success_output_tokenlists() {
        let parser = NekoParser::default();
        parser.load_and_parse_neko();
        let serialized = serde_json::to_string(&parser).unwrap();
        println!("{}", serialized);
        assert!(Path::new("./data/chap04/neko.txt.lindera.json").exists());
    }
}

出力結果

ここまで紹介したものの実行結果は次のような形でした。レスポンスタイム、スループットともに、最小、最大、99パーセンタイルなどを出力してくれます。出力はメソッド名ごとにくくられているのでとても便利です。

{
    "metric_reg": {
        "load_and_parse_neko": {
            "response_time": {
                "samples": 1,
                "min": 176128,
                "max": 177151,
                "mean": 176640.0,
                "stdev": 0.0,
                "90%ile": 177151,
                "95%ile": 177151,
                "99%ile": 177151,
                "99.9%ile": 177151,
                "99.99%ile": 177151
            },
            "throughput": {
                "samples": 0,
                "min": 0,
                "max": 0,
                "mean": 0.0,
                "stdev": 0.0,
                "90%ile": 0,
                "95%ile": 0,
                "99%ile": 0,
                "99.9%ile": 0,
                "99.99%ile": 0
            }
        },
        "output_tokens": {
            "response_time": {
                "samples": 9964,
                "min": 0,
                "max": 143,
                "mean": 0.03592934564431955,
                "stdev": 1.5152489085107463,
                "90%ile": 0,
                "95%ile": 0,
                "99%ile": 0,
                "99.9%ile": 6,
                "99.99%ile": 143
            },
            "throughput": {
                "samples": 174,
                "min": 39,
                "max": 71,
                "mean": 57.103448275862064,
                "stdev": 3.8417981983375835,
                "90%ile": 60,
                "95%ile": 61,
                "99%ile": 64,
                "99.9%ile": 71,
                "99.99%ile": 71
            }
        },
        "tokenize": {
            "response_time": {
                "samples": 9964,
                "min": 12,
                "max": 79,
                "mean": 16.897230028101177,
                "stdev": 2.331145559054724,
                "90%ile": 19,
                "95%ile": 20,
                "99%ile": 24,
                "99.9%ile": 46,
                "99.99%ile": 79
            },
            "throughput": {
                "samples": 174,
                "min": 39,
                "max": 71,
                "mean": 57.103448275862064,
                "stdev": 3.819293076427424,
                "90%ile": 60,
                "95%ile": 61,
                "99%ile": 64,
                "99.9%ile": 71,
                "99.99%ile": 71
            }
        }
    }
}

出力内容で気になったのはoutput_tokensとtokenizeのthroughputが全く同じ結果が出ていることです。なにかバグを踏んでいる気がします。。。(時間を見つけてソースコード読んでみるか。)

気をつけること

meteredの導入時にわかりにくいコンパイルエラーが出たので備忘録として残しておきます。 (下からコンパイルエラーを読んでしまうくせがあったのが問題なのですが。。。) エラーメッセージは次のとおりです。

error[E0412]: cannot find type `ResponseTime` in this scope
  --> src/chapter04/answer.rs:13:12
   |
13 | #[measure([ResponseTime, Throughput])]
   |            ^^^^^^^^^^^^ not found in this scope
   |
help: consider importing one of these items
   |
1  | use metered::ResponseTime;
   |
1  | use metered::common::ResponseTime;
   |

error[E0283]: type annotations needed
  --> src/chapter04/answer.rs:12:1
   |
12 | #[metered(registry = NekoParserMetricRegistry, /* default = self.metrics */ registry_expr = self.metric_reg)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
   |
   = note: cannot satisfy `_: std::default::Default`
   = note: required by `std::default::Default::default`
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

最初のメッセージにはわかりやすく出ていますが、ResponseTimeをuseせずに利用しようとした場合に以下のようなエラーが出ていました。ターミナル画面が狭かったのでE0283のエラーが目に入り、何を言ってるんだろう?という状態になってしまいました。スクロールアップしたら、答えが載っているのに。。。

コード全体

元ネタはNLP100本ノックの第4章です。コードの全体はGitHubのソースをご覧ください。

まとめ

meteredを簡単ですが紹介してみました。導入自体も簡単で、想像していたような使い方ができたので満足しています。ほかにもプロファイラなどはあるのかもしれませんが、まずはこれを使っていこうかと思っています。

バグらしきものがありそうだったりするので、そのへんは今後調査してみようかと。まだ、ちょっと試してみただけなので、metered自体のオーバーヘッドや、独自のメトリクスの実装方法、メソッドではなく関数に対して利用する場合にはどうするのか?などいくつか疑問点があるので、今後試してみてまたブログに残しておこうと思います。

第4章終了(言語処理100本ノック2020)

Mon, 07 Sep 2020 11:17:07 +0900

Rustで言語処理100本ノックの第4章です。

前回はこちら。

今回は早めに続きをやりました。「形態素解析」ですしね。

第4章の概要

吾輩は猫であるの文章が用意されていて、MaCabで形態素解析した結果をファイルに保存したところからが開始となります。

が、せっかくRustでやっているのでKuromojiのRust版であるLinderaを利用して形態素解析した結果を保存する部分から作成しました。 3章に引き続き、大きな流れのところの説明だけにしておきます。

形態素解析

もとのneko.txtが文章が1行ごとになっているので、そのまま1行ずつ読みならが、形態素解析していきます。読み込みの部分は3章とあまり変わらないので割愛します。以下は、形態素解析の処理と形態素解析結果用の構造体です。

#[derive(Clone, Debug, Serialize, Deserialize)]
struct Token {
    surface: String,
    base: String,
    pos: String,
    pos1: String,
}

まずは構造体です。今回の問題では、必要な情報は4種類だったのでそれを構造体にしました。

表層形（surface）
基本形（base）
品詞（pos）
品詞細分類1（pos1）

deriveでSerialize、Deserializeを付与しているのは、形態素解析の結果をJSON文字列として保存し、あとのそれぞれの課題で読み出すためにserde_jsonを利用するためです。

fn tokenize(line: &str) -> Vec<Token> {
    let mut tokenizer = lindera::tokenizer::Tokenizer::new("normal", "");
    let lindera_tokens = tokenizer.tokenize(line);
    let tokens = lindera_tokens
        .iter()
        .map(|lindera_token| {
            let surface = lindera_token.text.to_string();
            let pos = lindera_token.detail[0].to_string();
            let pos1 = if pos != "UNK" {
                lindera_token.detail[1].to_string()
            } else {
                String::new()
            };
            let base = if pos != "UNK" {
                lindera_token.detail[6].to_string()
            } else {
                String::new()
            };
            Token {
                surface,
                base,
                pos,
                pos1,
            }
        })
        .collect();
    return tokens;
}

次が形態素解析の処理です。入力に1行分の文章を受け取り、出力として、さきほどの構造体をベクタに入れたものVec<Token>を返します。内部ではLinderaのTokenizerをnormalモードでインスタンス化してそのtokenizer()メソッドを叩いているだけです。インスタンス化のときの第2引数は辞書のディレクトリですが、今回はデフォルト辞書(IPADIC)を利用しています。戻り値はLinderaが用意したToken構造体なので、これを今回作成したToken構造体に詰め替えているだけです。

注意点としてLinderaはMeCabとは異なり、未知語(辞書に出てこない単語)の処理が実装されていないので、品詞が"UNK"の場合にはその他の情報が取得できないので、空文字を構造体に設定するようにしました。

結果の保存

形態素解析の結果はJSONで保存しました。もとのファイルが1文が1行になっていたので、 1行を読み込み、形態素解析し、それをVecで取り出して、1行1配列JSONの形で保存するようにしてあります。

fn output_tokens(tokens: &Vec<Token>, buf: &mut File) {
    writeln!(buf, "{}", serde_json::to_string(tokens).unwrap()).expect("Error during output json");
}

serde_json::to_stringにVec<Token>を渡しているだけですが、構造体にderiveをつけているのでよしなにやってくれます(便利ー)。

JSONの読み込み処理

1行1JSONの読み込み処理です。今回も3章のように読み込みながら、各文章ごとの形態素解析結果に対して処理を実施するために、処理を実行するためのtraitをCommandとして用意し、それぞれの問題で形態素解析結果に対して処理を書くような実装にしました。また、設問37で「猫」と共起している単語を処理するという課題があるので、文章に「猫」が入っているものだけを処理できるようにするためのFilterも用意し、これをJSONの読み込み処理のイテレータのfilterにわたすようにしています。特にフィルタリングが必要ない場合ように、NonFilterを予め実装済みです。

trait Command {
    fn execute(&mut self, tokens: &Vec<Token>);
}

trait Filter {
    fn is_target(&self, line: &str) -> bool;
}

struct NonFilter {}

impl Filter for NonFilter {
    fn is_target(&self, line: &str) -> bool {
        true
    }
}

// ch04-30. 形態素解析結果の読み込み
fn load_json<T: Command>(cmd: &mut T) {
    load_json_with_filter(cmd, &NonFilter {});
}

fn load_json_with_filter<T: Command, U: Filter>(cmd: &mut T, filter: &U) {
    let file = File::open("./data/chap04/neko.txt.lindera.json").unwrap();
    let buf = BufReader::new(file);
    buf.lines()
        .filter_map(|item| item.ok())
        .filter(|line| filter.is_target(line))
        .for_each(|line| {
            let tokens = parse_line_json(line.as_str());
            cmd.execute(&tokens);
        });
}

output_tokensではserde_json::to_stringを呼び出してましたが、読み込みでは、serde_json::from_strを使うと構造体にしてくれます。

fn parse_line_json(line: &str) -> Vec<Token> {
    return serde_json::from_str(line).unwrap();
}

あとは、設問ごとにCommandトレイトを実装していく形です。たとえば、32.の動詞の原形を出力する場合は次のようになります。

struct ExtractVerbBase {
    out: File,
}
impl Command for ExtractVerbBase {
    fn execute(&mut self, tokens: &Vec<Token>) {
        tokens
            .iter()
            .filter(|token| token.pos == "動詞")
            .for_each(|token| {
                writeln!(self.out, "{}", token.base).expect("Error during writeln");
                println!("{}", token.base);
            })
    }
}

標準出力とは別にファイルにも出力できるようにExtractVerbBaseにoutでファイルを保持しています。

34. 名詞の連接

「名詞の連接（連続して出現する名詞）を最長一致で抽出せよ．」という課題だったのですが、最初は読み間違えて、名詞の連接の最も長いものだけを出力するようにしてました。。。やっぱり、出力結果とかのサンプルは用意しといてほしいなぁ。。。

impl Command for ExtractMaxConjunctionNoun {
    fn execute(&mut self, tokens: &Vec<Token>) {
        let mut nouns = vec![];
        // TODO 参照保持でどうにかしたいけどなぁ。
        tokens.iter().map(|token| token.clone()).for_each(|token| {
            if token.pos == "名詞" {
                nouns.push(token);
            } else {
                if nouns.len() > 1 {
                    self.buffer.push(nouns.clone());
                }
                nouns = vec![]
            }
        });
    }
}

名詞の場合に、nounsにバッファリングしつつ、違う品詞が来たら出力するという処理になっています。 cloneを呼び出していますが、これを参照を引き回す感じにできるといいのかもなぁ(結構めんどくさい)。

36. 頻度上位10語

頻度を数えるのにはBTreeMapを利用しています。数えながら、Top10を保持する方法がいい気がしたのですが、いい入れ物を見つけられなかったので、数え上げたあとにBTreeMapのIteratorを回しながら、キーバリューのVecをまず生成します。その生成したVecに値でソートし、その後Iteratorから最初の10件を取得して表示する方法にしました。

ソートして取り出すという処理がついでにかかっています。。。 BinaryHeapがなにか使えそうな気もしたのですが、いい方法が思いつきませんでした。

    fn print_top10(&mut self) {
        let mut key_values: Vec<(&String, &u32)> =
            self.terms_count.iter().collect::<Vec<(&String, &u32)>>();
        key_values.sort_by(|x, y| y.1.cmp(&x.1));
        key_values.iter().take(10).for_each(|(key, value)| {
            writeln!(&self.out, "{}, {}", key, value).expect("Error during writeln");
            println!("{}, {}", key, value);
        });
    }

まとめ

形態素解析結果をちゃんと眺めてはいないですが、処理としてはこんなところかなと。グラフはめんどくさいのでスキップしてしまいました。。。 Kibana/Esに食わせて見てみるのもありかなぁ?

次は係り受け解析です。Rustで使えるライブラリとかあるかなぁ?

第3章終了(言語処理100本ノック2020)

Fri, 04 Sep 2020 23:46:25 +0900

Rustで言語処理100本ノックの第3章です。

前回はこちら。

少し間が空きましたが、再開しました。間が空いた理由は。。。「正規表現」ですかね。。。苦手なんです、正規表現。なので、28はちょっとギブアップしてしまいました。

第3章の概要

個別に説明はせずに大きな流れのところだけ。それぞれの問題の解についてはリポジトリを御覧ください(興味ある人いるのかなぁ?)

第3章はNDJSON(new line delimited JSON)という、 1行に1JSONという形式のデータを格納したファイルがgzipで圧縮された状態で提供されます。まずは、このJSONファイルからJSONを読み込むのが主な処理になります。

読み込んだデータに「イギリス」のWikipediaの記事が入っているので、そこから正規表現で必要なデータを抽出します。

最後の問題が少し特殊で、抜き出した情報の「国旗」のファイル名を元に、MediaWikiのREST APIを叩いて、結果を取得し、その一部の情報を抜き出すというものです。

JSONの読み込み処理

gzipファイルを読み込んでから、1行ずつ抜き出してVecに入れる処理が次のようになります。今回のgzipファイルは大した量が入っていないので、全部先に抜き出す処理としてまとめました。もっと巨大なファイルの場合は個別のJSONに対する処理を buf.lines().map()のmapのなかで実行する形にすると思います。 gzipのファイルを開くのにflate2というクレート(ライブラリ)を利用しました。便利なのは、BufReaderにlines()というメソッドがあるところですかね。

// https://docs.rs/flate2/1.0.14/flate2/read/struct.GzDecoder.html
pub fn extract_ndjson_from_gzip(input_file_name: &str) -> Vec<String> {
    let f = File::open(input_file_name).expect("file not found?");
    let gz = GzDecoder::new(f);
    let buf = BufReader::new(gz);
    let lines: Vec<String> = buf.lines().map(|l| l.unwrap()).collect();
    return lines;
}

こちらは、上記のメソッドで抜き出したVecを元に、記事の情報を抜き出す処理をしています。 JSONをパースして構造体Articleにデシリアライズするために、serdeというライブラリを使用しています。 serde自体は様々なデータ形式(JSON、YAMLなど)をパースするためのフレームワークです。今回はJSONなので、serde_jsonの実装を利用しています。また、JSON文字列から構造体にデシリアライズするのを簡単にできるように構造体に#[derive(Deserialize)]をつけています。あとは、let article: Article = serde_json::from_str(json.as_str())という処理を実行すればserde_jsonがJSONをパースして構造体に変換してくれます。形式がわかっているJSONの扱いはこれが楽ですね。変数に型を明記してあるので、型の推論もしてくれてるようです。

#[derive(Deserialize)]
pub struct Article {
    title: String,
    text: String,
}

// ch03-20. JSONデータの読み込み
// https://serde.rs/
pub fn load_json(input_file_name: &str, target_title: &str) -> Vec<Article> {
    let mut results = vec![];
    let ndjson = extract_ndjson_from_gzip(input_file_name);
    for json in ndjson {
        let article: Article = serde_json::from_str(json.as_str()).expect("json parse error");
        if article.title == target_title {
            results.push(article);
        }
    }
    return results;
}

後続の処理ではパースしたArticleから記事情報を取得して色々と処理をしています。

正規表現

正規表現用のクレートregexがRustに用意されています。Regex::new(正規表現)で、正規表現をコンパイルし、あとは、この構造体のメソッドを利用して文字列を処理していきます。問題では、マッチするかどうか、マッチした一部の文字列を抜き出す、不要なタグを削除するといった処理を正規表現で行いました(Rust書くよりも正規表現の書き方とかを調べるのに大半の時間をもっていかれてます。。。)。


pub fn extract_category_lines(article: &Article) -> Vec<String> {
    let re = Regex::new(r"\[\[Category:(.*)\]\]").expect("syntax error in regex");
    let mut lines = vec![];
    article.lines_from_text().iter().for_each(|line| {
        if re.is_match(line) {
            lines.push(line.to_string());
        }
    });
    return lines;
}

MediaWiki APIリクエスト処理

最後の問題で国旗のファイル名を元にMediaWiki APIを叩いて、URLの文字列を取得しましょうという問題がありました。ファイル名をREST APIの引数に渡してHTTP経由でリクエストを送信し、返ってくるJSONレスポンスからURLを抜き出すという処理です。

HTTPのリクエストの送受信にreqwestというクレートを利用しました。ちょっと長いけど、APIコールしている箇所はこんな形です。

この関数にはasyncとついています。非同期処理の関数です。内部で2回ほど(リクエスト送信の結果待ちとレスポンスのパース待ち).awaitがあります。

clientに.get(URL)やquery(&[])といったメソッドが用意されているので、URLやクエリパラメータを用意してsend()でリクエスト送信します。


async fn call_api(file_name: &str) -> Result<String, String> {
    let client = reqwest::Client::new();
    let file_name2 = format!("File:{}", file_name);
    //let mut file_name2 = file_name.to_string().replace(" ", "_");
    let query = [
        ("action", "query"),
        ("format", "json"),
        ("prop", "imageinfo"),
        ("iiprop", "url"),
        ("titles", file_name2.as_str()),
    ];
    let result = client
        .get("https://en.wikipedia.org/w/api.php")
        .query(&query)
        .send()
        .await;

    match result {
        Ok(response) => match response.status() {
            StatusCode::OK => {
                let body = response.json::<MediaWikiResponse>().await;
                match body {
                    Ok(obj) => match obj.get_url() {
                        Some(url) => Ok(url),
                        None => Err(String::from("Cannot get url...")),
                    },
                    Err(error) => Err(error.to_string()),
                }
            }
            _ => Err(String::from(format!(
                "Status code is {}.",
                response.status()
            ))),
        },
        Err(error) => {
            let error_msg = format!("Error occurred... {:?}", error);
            println!("{}", error_msg.as_str());
            Err(error_msg)
        }
    }
}

あとは、呼び出し元で非同期の処理を実行するために、tokioというクレートを利用しています。 block_on()でcall_api()の実行をして、結果が返ってくるのを待ち受けています。結果が返ってきて、問題なければ、call_apiの戻り値Result<String, String>の左側のStringの値が取り出され、get_image_urlの戻り値となります。


fn get_image_url(file_name: &str) -> String {
    let mut _rt = tokio::runtime::Runtime::new().expect("Fail initializing runtime");
    let task = call_api(file_name);
    _rt.block_on(task).expect("Something wrong...")
}

一応、非同期に関して説明してみましたが、合っているのかどうか。。。クレートの関係などはまだちょっと自身がないです。。。あとは、エラーの処理の仕方とかももうちょっと勉強したいかな。

まとめ

一応、3章を終わらせました。だいぶ強引かつ1つスキップしましたが。。。次は第4章の形態素解析です。

TerraformでAzure Cognitive Searchのクラスターを起動

Tue, 18 Aug 2020 18:26:47 +0900

負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。これは、Terraformでやると楽できるのでは?と思ったので、やってみました。 1パーティションのクラスターなので、全然大したことはないのですが、メモを残しておくためにブログに書いておきます。

基本的にはTerraformの公式ドキュメントにあったものを自分用に変数を抽出しただけです。

ファイルたち

単にクラスターを起動するためだけなので、2種類のファイルだけ作成しました(1個でもいいかも)。

variables.tf - 変数用のファイル。いくつかの設定を変数として定義しました。
terraform.tf - Terraform本体のファイル。

`variables.tf`

まずはvariables.tfです(ファイル内の並びは異なりますが。。。)。terraform.tfで利用する5つの変数です。

resource_group - リソースグループ名。既存とは異なるリソースグループ名にしました(変に壊してもいいので)。
machine_type - 価格レベル(SKU)。公式ドキュメントに設定できる値の一覧があります。今回はWikipediaのデータを登録していたのでそれが入るサイズにしています。
region - 場所(リージョン)。リージョンの一覧はどこにあるんだろう?これを参考にしましたが。
partition_size - パーティションのサイズ(=Elasticsearchでのシャードかな?)です。今回は1つでの性能を計測したかったので1にしてあります。
search_cluster_name - Azure Cognitive Searchのサービス名。search.windows.net名前空間で一意である必要があったので、他の人が使わなそうな名前をつけています。

variable "machine_type" {
  default = "standard"
}

variable "region" {
  default = "East Asia"
}

variable "resource_group" {
  default = "johtani-wiki-test"
}

variable "search_cluster_name" {
  default = "johtani-wikipedia"
}

variable "partition_size" {
  default = 1
}

`terraform.tf`

terraform.tfは以下の通り。Terraformの公式ドキュメントにある例にproviderを追加しただけのものになります。

provider - プロバイダーの設定。Azureを利用するという宣言です。features {}がないとエラーになります。空でも必ず指定が必要です。認証周りについては、azure-cli経由で認証する方式を採用しました。azure-cliはHomebrewでインストールしています。
azurerm_resource_group - リソースグループの設定。variables.tfのresource_groupとregionを利用しています。必須項目はこの2種類だけです。
azurerm_search_service - Azure Cognitive Searchの設定。partition_count以外は必須項目です。variables.tfとazurerm_resource_groupの設定を利用しています。今回は利用していませんが、レプリカ数なども指定できるようになっています。

# Azureのproviderを指定。
provider "azurerm" {
  features {}
}

# リソースグループの設定
resource "azurerm_resource_group" "wiki-test" {
  name     = var.resource_group
  location = var.region
}

# Azure Cognitive Searchの設定
resource "azurerm_search_service" "search_service" {
  name                = var.search_cluster_name
  resource_group_name = azurerm_resource_group.wiki-test.name
  location            = azurerm_resource_group.wiki-test.location
  sku                 = var.machine_type
  partition_count     = var.partition_size
}

以上がファイルです。ほぼ公式ドキュメントのサンプル通りですねw

デプロイとか

ファイルの準備ができたら実際にデプロイします。 Azureの環境への認証にはAzure CLIを利用して、事前にログインした状態にします。実際にデプロイするまでの手順は次のようになります。

az login - Azureの認証。ブラウザが起動してログイン画面が表示されます。無事認証がOKなら、azコマンドでAzure Cloudの情報が取得できます。
terraform init - 初回だけです。Terraformのワーキングディレクトリの初期化処理を実行します。
terraform plan - Terraform < 0.12の場合は実行。最新版だともういらないみたいだ。
terraform apply - 実際にAzure上にクラスターを起動します。Terraformが隠蔽してくれているので、実際にどんなことをやっているかはわかってないですが。

以上で、Azure Cognitive Searchのクラスターが起動します。すごく簡単です。Webコンソールでチェックすれば、起動していることも確認できます。

この状態では、クラスターが起動しただけなので、あとは必要に応じてデータをロードしたり、アプリから検索したりと行ったことが可能になります。そのへんの話はまた機会があれば。

Destroy

今回は負荷テスト用にクラスターを起動していましたので、必要なくなれば、クラスターを削除します。Terraformを導入したもう一つの理由がこの簡略化です。 terraform destroyを実行するだけで、Azure Cognitive Searchのクラスターおよび、リソースグループが削除されます。

まとめ

ということで、ほぼ公式ドキュメントのままですが、TerraformでAzure Cognitive Searchのクラスターを起動する方法の紹介でした。ブログを書いていて、1点気になったのは、ロケーション(リージョン)の一覧はどこにあるんだろう?という点です。azコマンドとかで出てくるのかなぁ?

検索システムを構成するパーツ(検索システムに関する妄想その2)

Tue, 28 Jul 2020 12:34:42 +0900

先日は「システムの特徴と検索機能について」という感じでふんわり書きました。まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。他にもぼんやりしてるものはいくつかあるので今日も書いてみることに。検索システム?みたいなツイートも見かけたので、検索システムってこんなイメージですというブログを書いてみました。

検索システム(機能)を構成するパーツ

今回はシステムに組み込まれる検索機能を構成するパーツについて書き出してみようかなと思います。パーツといってもユーザー、UI、コンテンツなども入れています。

ユーザー
検索UI
- 検索窓
  - オートコンプリート
- 検索結果画面
  - ファセット
  - ソート
  - ハイライト
- 詳細画面
  - レコメンド
検索エンジン
コンテンツ
検索ログ
- クリックログとかも
サービス提供者

ざっくり書くとこんな感じです。システム構成だったり、機能だったり、アクターだったりといろいろなものが混ざってしまっていますが、登場するものはこんなものです。

ざっくりした繋がりの図はこんな感じです。

それぞれの役割について見ていきましょう。

ユーザー

サイト、システムのユーザーです。検索UIを経由して望んだコンテンツを探します。探す目的は、サイトによって異なります。「何かを購入(ECサイトやオークション)する」だったり、「情報(レシピや社内文書)を見つける」だったりします。図では「キーワード」と記載しましたが、最近では自然文(文章)を受け付ける検索もあります。

検索UI

サイト、システムが提供するUIです。ユーザーはこのUIにキーワード(質問)を入力し、検索結果を取得します。 UIにはいくつものパーツがさらに存在します。簡単に例を上げると以下のようなものです。

検索窓 - キーワードを入れるための入力ボックスです。
- オートコンプリート(自動補完) - サイトによっては、検索窓に何かを入力すると、キーワードを保管したりサジェストしたりしてくれます。
検索結果画面 - 質問にマッチしたコンテンツの一覧を表示する画面です。一覧以外にもいくつか情報が表示されます。
- 検索結果一覧 - コンテンツの一覧です。何かしらの基準(日付順や人気順など)によってソートされたものが表示されます。
- ファセット - 検索結果が持っている属性(価格帯、カテゴリ、メーカー名など)の一覧で、絞り込み検索のヒントです。
- ハイライト - 入力したキーワードがどこにマッチしたかがわかるように、強調表示されたスニペット(情報の一部)が出ます。

検索APIとUIに分かれている場合が多いでしょうか? 処理の流れとしては、検索窓に入力されたキーワードを検索エンジンに問い合わせができるクエリに書き換えてからリクエストを投げます。あとは、検索エンジンからのレスポンスにある検索結果を表示できる形に変換して表示するのが役割です。また、検索ログの出力もこの部分で担当することが多いです(もしくは、検索エンジン自体がログ出力の機能を持っている場合もあります)。

検索エンジン

検索に特化したデータ構造を内部に持っているサーバーもしくはサービスです。 ElasticsearchやApache Solr、Azure Cognitive Searchなどは転置インデックスと呼ばれるデータ構造になっています。検索エンジンの検索処理に対しての主な役割は次の2つです。

クエリにマッチするコンテンツの集合を決定する
マッチしたコンテンツを特定の条件で並び替える(ランキング)

クエリを受け取り、検索結果のリストを返すのが処理の大きな流れです。その他に、ファセット、ハイライトといった付加的な処理を実行することがあります。

また、データ登録(インデキシング/インデクシング)の処理もあります。

登録するコンテンツを検索に特化したデータ構造にして格納する

転置インデックスの場合は、入力されたデータ(文章)から単語列を作り出して、単語からコンテンツのIDが判別できる形にする処理になります。

AlgoliaやElastic App SearchのようなSaaSであったり、RDBの機能を利用するといった選択肢もあります。

データソース・コンテンツ

実際に提供したいコンテンツになります。コンテンツが保存されている場所は、サイトによって異なります。

Webの検索サイト - インターネット上のホームページ
ECサイト - データベースに格納されているアイテムのデータ
社内文書検索 - ファイルサーバーやWikiなどのファイル、文書

といった感じです。実際には、データソースからコンテンツを検索エンジンに登録する場合は、いくつかの処理(いわゆる前処理)が必要になります。社内文書検索やWebの検索サイトの場合は、データを収集するためのクローラーが必要ですし、収集したデータから、検索エンジンに登録するデータを加工したり(HTMLタグを除去したり、メタデータ(URL、収集日、タイトル)を付与したり)もします(ETL処理とか言われる)。

検索ログ

検索を提供するだけであれば、必要ありません。が、実際に検索がどのような使われ方をしているか?を知るために必要な機能になります。この検索ログがユーザーのニーズを読み解くための情報になります。検索ログには次のような情報が入ります。

検索窓に入力された文字列
入力された文字列でヒットした件数

検索結果を出したタイミングでのログです。他にも実際にヒットしたコンテンツのIDなどをログに残したり、他のユーザーと区別をつけるために、ユーザーのセッションごとにIDを発行してログに残したりもします。

また、検索に満足してもらえているかを見るために、実際に検索結果のどのコンテンツに興味をもったのか?という情報も検索ログとして残すことがあります。クリックログなどとも呼ばれます。検索結果のどのドキュメントが実際にクリックされたか(詳細画面に遷移したか)という情報です。1回の検索結果に対してクリックされるごとにログが残ります。もちろん、結果に満足しない場合は、クリックされずに、キーワードを変えたり、絞り込み条件がクリックされたりします。

ECサイトなどの場合は更に、実際に購入されたかどうかといった情報もユーザーのニーズを読み解くための情報となります。詳細画面へのクリックログや購入ログについては、検索以外からの流れ(広告やDMだったり、レコメンドだったり)なども考えられます。これらのログを元に、検索を改善していくことになります。

サービス提供者

サイト・システムの提供者です。コンテンツの準備、検索UIにはどんな物が必要なのか、サイト・システムにとって良い検索とはなにか?、検索ログからユーザーのニーズを分析して何を改善していくのか?といったことを考えます。例としては次のようなことです。

検索結果に表示するコンテンツとはなにか?
コンテンツの持っている項目・属性の何を検索対象とするか?
検索結果の並び順(ランキング)がどんなものがよいのか?
検索UIにはどんなものを表示するのか?

検索機能を作るときの流れ

検索機能を構成するパーツにどんなものがあるかを紹介しました。実際にシステムに検索機能を追加する場合は、最低限、次のものが必要になります。

検索UI
検索エンジン(RDB?SaaS?ミドルウェア?)
データソース・コンテンツ

とりあえずこれらがあれば、検索機能を作ることはできるかと。ただ、作っただけでは、いいか悪いかの判断がつかないので、どういった使われ方をしているかを知るために検索ログをとったりして、改善をしていく必要が出てきます。

まとめ

わかってるよそんなことはと言われそうな感じになったかもしれないですが、検索の機能を構成するパーツについて紹介してみました。細かなはなしは色々とありますが、大まかにはこのような役割のパーツがあります。

実際にはこれらのパーツを用意すればよいわけではなく、それぞれで検索を良くしていくためにどんなことを考えていくのか?などが出てきます。そのあたりの話はまた、別のブログで書いていく感じでしょうか。こんな感じで書いてくと、終わらない気がしてきたけど。。。次はどんなはなしを書くかなぁ。

システムの特徴と検索機能について(検索システムに関する妄想その1)

Mon, 27 Jul 2020 18:28:54 +0900

今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。検索の仕組みを知れば知るほど面白くなってきたからという理由になるのかな? LuceneやSolr、Elasticsearchなどを長く触っているというのもあるかと思います。

ということで、検索についていつも考えています。頭の中でまとまっていない状況ですが、システムにおける検索機能についていくつか頭の中にあることを書き出して、いろんな方にダメ出しやコメントをもらいたいなと思ったので、色々と書いてみようかと。思いつきのままに書いているので、はなしがあちこち飛ぶ可能性もありますが、あしからず。

検索って難しい

「「検索」とは、データの集合から目的のデータを探し出すこと」By Wikipedia

一言で「検索」といっても、使う人、ユースケースによっていろいろな「検索」があります。例えば、新しいスマホを買ったときに、スクリーンロックの時間を設定する機能を「検索」したりします。また、PCで仕事をしているときに、ファイルの中身をある文字列で「検索」したりもします。 TSUTAYAに行って、欲しかった本がおいてあるかどうか店内の端末で「検索」もします。 Rustを書いていて、こんなことをやるライブラリありそうだよな?と思ってGoogleでウェブの検索をしたりもします。

私が特にそうだと思いますが、なにかあったらまず検索をするという生活をしています。ただ、このとき、「検索」といっても望んでいる挙動が違ったりするものです。以下は自分が「検索」しているときに想定していることになります。

ファイル内の検索をしているときはgrep的な検索を想定していることが多い。
書籍の検索をしているときは、特定の項目(著者など)に対してgrep的な検索を想定しているが、名前の読みなどでも検索されることを想定している(漢字覚えてなかったりする。。。)。
Rustを書いているときに機能をGoogleで検索するときは、いい感じに検索してくれることを望んでいる(入力するキーワードが曖昧なことが多々ある。例えば、そのものズバリの名前をしらないときとか)

あくまでも私が想像している挙動です。他の人とは違う可能性もあります。なので、「検索」といってもさまざまな要素があるし、想定しているシーンも異なるので「難しい」なと思っています。また、そんな「検索」ですが、世の中的にはあって当たり前だと思われていたり、お金や時間がかかるものと思われてなかったりもします。ま、けどそういったことも含めてやればやるほど面白いなと感じている今日このごろです。

前置きはこのくらいにして、今回はシステムの特徴と検索機能について感じていることを書いてみようと思います。

システムの特徴と検索機能

先ほども書きましたが、検索は今やシステムに欠かせない機能となっています。が、あればいいというものでもないのではないかなと。とりあえず検索できるべきだということで検索機能を追加しても使いにくいものや、想定している動きをしない場合は使われないものになってしまいます。

システムでの検索機能は特に、「情報検索」(Wikipediaはこちら)と呼ばれたりもします。Wikipediaによるとこんな説明です。

情報検索（じょうほうけんさく）とは、コンピュータを用いて大量のデータ群から目的に合致したものを取り出すこと。検索の対象となるデータには文書や画像、音声、映像、その他さまざまなメディアやその組み合わせとして記録されたデータなどが含まれる。

「目的」と呼ばれるものは「ユーザーのニーズ」と呼ばれたりもします。「合致したもの」というのがシステムが返す「検索結果」になります。検索結果は大体の場合、何かしらの順序でソートされていることが多いです。ざっくり話をすると、「ユーザーのニーズ」を元に「(何かしらの順序でソートされている)検索結果」を返すという処理です。

ただ、この「ユーザーのニーズ」や「何かしらの順序でソートされている検索結果」はシステムの特性、特徴によってぜんぜん違うものになります。検索エンジンを入れただけで解決するものではありません。

また、システムは提供する側のニーズもあります。 ECサイトであればより多くのユーザーに購買してもらったり、コミュニティサイトの場合は利用ユーザーを増やしてコンテンツや広告の収入を増やしたりといったニーズがあります。

これらの両方のニーズが検索機能に影響を与えたりもします。

いくつか例を上げてみましょう。

書籍の検索の場合

ユーザーのニーズは、「ある本を探す」ことです。そのためにユーザーがクエリを入力します。クエリは、例にも出しましたがタイトルや著者名の読みだったりします。検索窓が1つしかないというよりは、著者やタイトル、出版社などそれぞれの項目ごとに検索できるほうが便利だったりしますよね。検索結果については、完全一致したものが一番最初に出てきてほしいこともあれば、出版年月日の降順で並べたいことなど、その時々でやりたいことが変わったりもします。

場合によっては、説明文などでも検索できると嬉しいこともあります。また、システムからは離れますが、図書館や書店で時々、「〇〇について書かれている本ありますか?」といった聞き方をしたりもします。

また、書店としては、探している本を見つけてもらうために検索端末などを用意しますが、それ以外の本も買ってもらえるといいですよね。オンラインの書店などでは、検索結果や書籍詳細の画面に関連書籍が出ていることもあります。

検索とは少し異なり、探索(なにか面白い本とかないかな?というようなニーズ)をしに、書店に行くこともあります。書店で平積みされた本やポップなどを見て新しい本に興味を持つこともあります。

オークションサイトやECサイトでの検索の場合

ユーザーのニーズは、「欲しい物を探す」ことです。ユーザーが入力するクエリは、幅広いものになると思います。製品の型番を入力する人もいれば、メーカー名や製品名だったり、ジャンルで絞り込んで検索することもあります。

探されるもの(コンテンツ、アイテム)も多数に渡ります。検索窓は1つかもしれませんが、検索結果には、絞り込み条件(ファセット)がいくつか並んで、絞り込んでいける仕組みが用意されていることが多いです。

検索結果のソートは、価格順だったり人気順だったりします。ただ、オークションサイトの場合は新しいもの順や、終了日時の早い物順だったりします。

サイト提供者のニーズとしては、より多くのアイテムを購入してもらうこと(売上)です。また、オークションサイトの場合は、アイテムを提供している人のニーズも影響してくるでしょう。売りたい人はより多くの人の目に留まってほしいと思うはずなので、様々な情報を付与していかに目にとまるか?といったことを考えてくると思います。

また、様々な商品を扱うECサイトの場合は、さらに色々と大変になってきます。たとえば、「iPhone」で検索されたときに、 iPhoneそのものが上位に来るべきなのか、ケースなどの周辺商品なのかだったりといった問題が出てきます。商品の提供者が多数に渡る場合は、同一商品でもさまざまなお店から提供されてしまうために、検索結果一覧に多数同じ商品が並んだりもしますよね。

レシピサイトでの検索の場合

ユーザーのニーズは「レシピを探す」です。が、探し方はユーザーによって様々です。冷蔵庫にある材料を入力して検索することもあれば、食べたいものが決まっていてそのレシピを検索することもあります。このとき、重要なのは類義語だったりするでしょう。食材やレシピは同じものでも様々な名前(例:パクチー、コリアンダー、シャンツァイ(香菜)など)を持っていたりします。また、部位や形によっても名前が変わったりもします。

検索結果は人気順で並ぶことが多いでしょうか? ただ、レシピの提供がユーザーによるものなのか、サイト運営者が提供しているものかによっても変わってくるでしょう。

サイト提供者のニーズとしては、レシピコミュニティサイトの場合は、ユーザー数の増加や広告の売上などがあるでしょう。調味料などのメーカーがレシピサイトをやっている場合は、調味料の売上だったりします。この場合は、検索がどの程度売上に寄与しているのか?などを測ることが難しかったりしそうです。

社内文書検索の場合

ユーザーのニーズは「文書を探す」です。探し方はファイル名であったり、ファイルのなかに出てくる単語だったりします。社内用語・略語のような特殊な単語で検索されることもあるでしょう。ユーザーによっては、ぼんやりとした「こんな資料を探している」といったふんわりとした検索をしたくなることもあります。

検索結果の表示順は「それっぽいもの」が上位に出てくることが望まれそうです。ただ、古い文書が出てきても役に立たないこともあります。新しい文書のほうが役に立つことが多いので、最近作られたものというのも重要な情報になります。ただし、権限によっては見ることができなかったり、そもそも探すこともNGだったりもします。

社内文書検索の提供者は、素早く検索できるものを提供することで仕事の効率を上げてもらったり、無駄を省くことができることを期待しているでしょう。

昔からですが、社内の文書は様々な場所に散らばっていることが多いです。顧客管理システム、ファイルサーバー、Wiki、ウェブサイトなどこれらをまとめて検索できるシステムなどが望まれていることも多いです(使われるかはまた別ですが。。。)。

スマートスピーカーの場合

ちょっと特殊な面白い例かなと思ってます。音声で検索(というかお願い?)します。システムとしては、ユーザーのニーズを理解するのに2段階あるのかなと。

音声認識
認識した文章・キーワードで検索(場合によってはコマンド発行)

これだけでも難易度が増します。

さらに、画面のないスピーカーの場合は、結果は1件だけになります。これって結構難しいことだと思うんです。画面があれば、検索結果を上位10件などのリストで表示して、あとはユーザーに選んでもらうことができますが、音声の場合は1件だけしか返せません。また、レスポンスタイムもシビアなものだと想定されます。ずっとスピーカーに黙っていられると困りますよね? きっと大変なんだろうなぁ(妄想)。

このように、検索と言っても、システムごとに要求・想定されるものは変わってきます。

まとめ

例をいくつか上げましたが、ざっくりしすぎて発散してますかね。。。想像している部分もあるので、この通りではないと思います。ただ、システムによって、「検索」といってもシステムの特性上、さまざまな物事、思惑が絡んでくるというのは想像してもらえたと思います?(思いたい)。

システムに検索機能を追加すると言っても、探したいものが何なのか?、探してもらうものはどういったものなのか?、検索機能を追加することで何を達成したいのか?など考えることは色々あります。どうやって、検索機能を実装するのか、その検索機能を実装するためにはどんな情報が必要なのか?などの検索機能のコアな部分を考えるだけでなく、提供しているシステム、コンテンツがどんなものかなど、システム全体を考えながら検索機能を考えていく事が検索をより良いものとして行くことだと思います。

また、検索されるものも検索する人もシステムが成長するのに合わせて変化していきいます。システム同様、一度作ればおしまいというものではないので、やることはいっぱいあるのかなと。

次は、検索のパーツについてなにか書こうかなぁ。

ボヤキ

もう少しまとめてから書いたほうがいいのかもなぁ。もしくは、出てくる要素を整理するとか。ユーザー、コンテンツ、コンテンツ提供者とかで。ふんわりとしたブログになってしまった。個別のシステムごとにもっと書けることもありそう。

Rust the book - 第15章

Thu, 09 Jul 2020 18:59:38 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

14章は飛ばして、15章です(Cargoはまた別途調べればいいかな?と思って)。

第15章スマートポインタ

たぶん、これを理解すれば、参照とベクタや構造体とかの組み合わせがもう少し効率よく使えるようになるのかなぁ?

ポインタの強い版?
- 参照カウント方式のスマートポインタ型 - Luceneとかで実装されてた気がするなぁ
  - 複数の所有者!?
DerefとDropトレイトを実装している構造体

ヒープのデータを指すBoxを使用する

これはコンパイルエラー。let yのタイミングで借用してるので、書き換えでエラーになる。

fn main() {
    let mut x = 5;
    let y = &x;

    assert_eq!(5, x);
    assert_eq!(5, *y);
    x = 6;
    assert_eq!(6, x);
    assert_eq!(6, *y);
}

こっちはOK。

fn main() {
    let mut x = 5; // in stack
    let y = Box::new(x); // in heap

    assert_eq!(5, x);
    assert_eq!(5, *y);
    x = 6;
    assert_eq!(6, x);
    assert_eq!(6, *y);
}

余談:コンパイラが変なワーニングを出してくれた。

use std::ops::Deref;

impl<T, Z> Deref for MyBox<T, Z> {
    type Target = T;

    fn deref(&self) -> &T {
        &self.0
    }
}

struct MyBox<T, Z>(T, Z);

impl<T, Z> MyBox<T, Z> {
    fn new(x: T, y: Z) -> MyBox<T, Z> {
        MyBox(x, y)
    }
}

fn main() {
    let x = 5;
    let z = "10";
    let y = MyBox::new(x, z);

    assert_eq!(5, x);
    assert_eq!(5, *y);
}

Derefトレイトでスマートポインタを普通の参照のように扱う

参照外し型強制 : 日本語ムズカシイネ
Derefを自分で実装しないといけない場面がちょっと想像できてない。たぶん、Boxとかの説明に必要なので出てきたって感じなんだろうけど。

Dropトレイトで片付け時にコードを走らせる

こっちは、リソース開放とかでいい感じにできそうだってのはわかった。
Dropはどんなときに実装するんだろう?Tantivyだとオブジェクトプールとかで使ってた。

Rcは、参照カウント方式のスマートポインタ

これ、ここで作ったConsのリストを追っかけるためのサンプルも書いてほしい。

#[derive(Debug)]
enum List {
    Cons(i32, Rc<List>),
    Nil,
}

fn print_typename<T>(_: T) {
    println!("{}", std::any::type_name::<T>());
}

use List::{Cons, Nil};
use std::rc::Rc;
use std::borrow::Borrow;

fn main() {
    let z = Cons(5, Rc::new(Cons(10, Rc::new(Nil))));
    let a = Rc::new(z);
    let _b = Cons(3, Rc::clone(&a));
    let _c = Cons(4, Rc::clone(&a));
    match &(*a) {
        Cons(v1, v2) => {
            print_typename(v2);
            println!("{}, {:?}", v1, v2);
        },
        Nil => println!("Nil!!")
    };
}

RefCellと内部可変性パターン

循環参照は、メモリをリークすることもある

Berlin Buzzwordsにオンライン出張してた

Mon, 06 Jul 2020 12:12:44 +0900

6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。

Berlin Buzzwordsとは?

ベルリンで開催されている、Big Data、Scarability、Storage and Searchabilityに関するカンファレンスです。今年はコロナウイルスの影響で、オンラインで開催されました。また、同時期に検索に関する他のカンファレンス(以下の2つ)もベルリンで毎年開催されているのですが、今年はこれら3つのカンファレンスが1つのチケットで参加できる形で開催されました。

MICES - MIX-CAMP E-COMMERCE SEARCH
HAYSTACK - The Search Relevance Conference! sponsored by OpenSource Connections

MICES、HAYSTACKは初参加ですが、検索に関するいくつかのトピックが聞けたので楽しかったです。

6/7から6/12まで(がんばって)参加したので、その感想などをブログにとどめておきます。

オンラインってどんな感じで開催されてた?

まずは、オンライン開催がどのような感じだったのかをメモしておきます。

有料のオンラインカンファレンス(事前にチケット購入が必要)
参加者用Slack
- カンファレンス数日前まではここで連絡とか質問が可能だった(もちろん、メールも来ましたけど)。
基本的なプラットフォームはBrellaのバーチャルイベントプラットフォーム
- 参加者同士のSNS機能 - 参加者同士の興味によって参加登録時に似たような人ですよとマッチングしたり。ビデオチャット機能もあり。
- カンファレンスのスケジュール確認 - セッションのスケジュールの他に、参加者同士でのチャットのスケジュールも可能。一番便利だったのは自分のタイムゾーンも表示してくれること。
- ストリームチャネル - セッションが行われている場所への誘導
- スピーカー・スポンサーのリスト - スピーカーやスポンサーを探せる機能。スポンサー企業からは参加者も見ることができる
セッションはYouTubeライブ
- ストリーム中だったらちょっと戻ったり、ポーズもできるので、便利だった
セッション後の質疑応答にはJitsiというオープンソース!?のビデオカンファレンスの部屋が用意されてた(GitHubで公開されてるのか。https://github.com/jitsi)。
2日目、3日目はLTとかが終わったあとに、オンライン飲み会やってたっぽい(不参加)

主催者側も初めてだとは思うのですが、目立ったトラブルはなかったです。ちょっとだけ遅れたりしてましたが、それほど影響はなかったです。オンラインでの開催の一番のネックは、日本だと時差が辛いということです。ベルリンが開催地なのですが、スピーカーや参加者はアメリカからの方が結構います。そのため、開始時間が日本の23時といった具合になりました。

面白かった&気になったセッション

いくつか面白かった&もう一度見ないとなと思ったセッションと感想を。

Natural Language queries at Salesforce scale

セッションのページはこちら(2020年7月現在)

Salesforceでどのような自然言語のようなクエリに対して書き換え、サジェストのようなことをやっているか?という話です。 Salesforceはテナント(企業)ごとに、データ構造などがカスタマイズ可能なため、それぞれ個別に入力クエリ(例: new leads in sf)に対して、どういったパーツ(時間?場所?状態?)なのか?、どのフィールドへの条件なのか?といったものをNERのディープラーニングモデルとして捉えて解析しているという話でした。企業毎にパーソナライズもされていると。実際にはパイプラインの一部でこの処理をやっており、それ以外にも処理はされているという話もありました。評価の話もされています。

AMA - AI-Powered Search

セッションのページはこちら(2020年7月現在)

ManningでMEAP(絶賛書いているところ)のAI-Powered Searchの著者2名がAMA形式でいろんな質問に答えていく感じのやつです。最初は近況報告(Treyさんがカンファレンス直前に転職してた)と、書籍がどんなものかを簡単に紹介したあと、質問に答えていく形式で2時間あります。ディープラーニングのモデルに関する話なども出てきています。もう一度見たいと思ってたやつなので見ないとな。。。 (パネルっぽいセッションは、ヒントがなにもないので結構辛い)

Ask Me Anything: Lucene 9

セッションのページはこちら(2020年7月現在)

LuceneのPMCメンバーのUweさんが今後のLucene/Solrのいくつかの質問に答える感じのAMAです。出てきた話(質問の前の)としては、Lucene 8の現状(Bloc-Max WANDとか)や、Java 11対応になるよとかです。 QAでは、SIMDの話、Approximate Nearest Neighborがどんな感じか?などの話でした。

From commercial search to owned search

セッションのページはこちら(2020年7月現在)

カルフールスペインがECの検索をどのように導入したかという概要レベルの話でした。モノリシックなものをマイクロサービスでk8s上に載せ替えたという大きなアーキテクチャ以降の話です。 Empathy.coが提供しているものを最終的には使用したみたいだけど、どんな検索がされているのかといったニーズの調査ができるようになり、検索に絡んだKPIが改善した話でした。 COVID-19に絡んだクエリの変化についてもちょっと話が出てました。

Neural Search in Practice

セッションのページはこちら(2020年7月現在)

Zalandoの検索の一部でNIR(Neural IRモデル)を利用してクエリの改善をやって、それをどうやってトレーニングして、テストしたかなどの話。 NIRを利用することで、複数の言語に対して改善が見られたという話だった。今までは、クエリをいくつかの処理を元に翻訳して、入力された単語がカテゴリーに対するものなのか、スタイルに関するものなのか?などを判別して、クエリの補強?を行っている手法だった。これに対して、ディープラーニングでクエリに対するクリックデータを元にトレーニングして、どういうクエリに対してどんなアイテムを出すのか?というモデルで検索を改善していた。ヒット件数が0件だったり少ないものを対象にして上記の処理を入れているらしい。 (ということで、ディープラーニングをしっかり勉強しないといけないみたいなので、どうにかしたい。。。)

Top 10 Lessons learned in search projects the past 10 years

セッションのページはこちら(2020年7月現在)

10年検索プロジェクトをやってきた10個の気づきという感じのセッション。ごく当たり前のことなんだけど、検索の導入・改善に関して、こういう事あって、何も考えないとこうなっちゃうよね。だから、こんなことをやるべきだよね?という話です。たとえば、検索窓はあるけど分析すらしていない状況(レッスン1)だとまずはこういうのやらないとね。とか、検索クエリの分析・改善ばかりして、コンテンツの分析・改善を怠っていないか?という当たり前の話です。当たり前なんだけどまとめてくれてるのは、やはりいいなぁと。

Click logs and insights: Putting the search experts in your audience to work

セッションのページはこちら(2020年7月現在)

検索ログとクリックログがあったときに、どういったことに使えるのかを料理のレシピに見立ててデモをするセッションで説明が面白かったです。「こんなログがあったときに、ログのこの項目とこの項目を材料にすると、こんなのができますね」というのを、Elasticsearchにログを取り込んで、JupyterNotebookでデモをしていました。やはり動くものがあるとわかりやすいですねぇ。

Mixing and Matching: Diversifying Search Results

セッションのページはこちら(2020年7月現在)

これまたパネルセッションです。検索結果の多様性に関するディスカッションでした。これは、ECだからこその課題でもあるのかなと。検索自体は「何かを見つける」ための手段です。普通に考えた場合は、ピンポイントで探していたものが見つかるのが嬉しいです。が、例えば、ユーザーが検索した単語そのものが入っているだけのものが見つかるよりも、似たような商品も一緒に出てきてほしいことありますよね?また、ECサイトだと、回遊してほしいというのもあります。ということで、それぞれの方がどんな観点で多様性を考えているのかという話をするディスカッションになっていました。

Thought Vectors, Knowledge Graphs, and Curious Death(?) of Keyword Search

セッションのページはこちら(2020年7月現在)

AI-Powered Searchの著者の一人、Treyさんのセッション。ベクトルを検索にどうやって使うのか、ベクトルで表現できるものはどんなものがあるのか?どんな検索エンジンで使えるのか?という話でした。歴史的な話も交えつつ、検索だとこのへんで使えるんじゃないか?というような話でした。

録画は?

気になったセッションをいくつか書き出してみました。ちなみに、全セッションのビデオが公開されています。興味がある方は、ご覧いただければと。

The recordings from this year's Berlin Buzzwords / MICES / Haystack joint event are now online. You can watch them all on our YouTube channel. Thank you once again to all of our wonderful speakers. https://t.co/hTRDmKNdpd
— @berlinbuzzwords@floss.social (@berlinbuzzwords) July 6, 2020

感想そして来年は?

楽しかったです。検索に関する話が色々聞けるのはやっぱ楽しいですね。サイトの特性(ECなのか、Wikipediaなのかなど)によっても「良い検索」の定義も変わるので、サービスなどがどんなものか、そしてそれを良くするためには検索はどんなことができるのか?といった話や、技術的な濃い話までいろいろな話を聞けました。ただ、パネルは英語の聞き取りが辛いですね。。。あと、時差が。日本にいながらにして時差ボケは辛い。。。オンライン飲み会には流石に参加できませんでした(4時とか5時から始まるし)。

来年もオンラインで開催されたら間違いなく参加します。オフラインのみだった場合はどうなるかなぁ。。。

luceneutil - Analyzer性能テストへのkuromojiの追加

Thu, 25 Jun 2020 11:01:58 +0900

luceneutil - マニアックなツールのセットアップの続きです。今回も誰得?なブログなので興味ない場合は飛ばしましょう。

一応、luceneutilのREADMEにあるlocalrun.pyを動かせるところまでいったんですが、そこで一旦本題を思い返してみました。

Kuromojiの性能が落ちてるらしいし、Analyzer系のベンチマーク測ってるグラフに載せたほうがいいよね。

これが、そもそも動かしてみようと思った本題です。 READMEに書いてある手順で動いたんですが、よくよく調べてみると、Analyzer系の性能テストをやってるのは、別物っぽいぞと。なんとなく、「ソフトウェア考古学」っぽくなってきましたね。

Analyzerの性能テストやってるのは?

Analyzerのパフォーマンステストのグラフに出てきたTokenizerの名前を元にluceneutilのリポジトリを検索してみました。 EgdeNGrams当たりで検索するとヒットしたのが以下のファイルです。

本命はsrc/main/perf/TestAnalyzerPerf.javaっぽいですね。これを動かしている人はどれかな?ということで、今度はこのファイル名で検索します。

src/python/runAnalyzerPerf.py

どうやら、このPythonのファイルが先程のJavaファイルを実行して、性能を計測しているみたいです。最初に出てきた、sumAnalyzerPerf.pyはrunAnalyzerPerf.pyの実行結果をAnalyzerの計測結果のグラフに追加する処理をしているようだということまでがわかりました。

KuromojiをTestAnalyzerPerfに追加してみる

動かす対象がわかったので、あとは、やることを追加しましょうと。

Kuromojiの実行をTestAnalyzerPerfに追加
- 引数を追加して日本語版のWikipediaのファイルも読み込むようにする
runAnalyzerPerf.pyに引数の追加とクラスパスの追加
- JapaneseAnalyzerはlucene/analysis/kuromojiにビルドされるのでクラスパスを追加
- 引数に日本語版のWikipediaのファイルを追加
日本語版のWikipediaのデータの用意

こんなものかな?と。

1と2はそれほど大変ではないので、3をまずはというところから始めてみました。

WikipediaのXMLから1行1データのTSVファイルに

まずは、どんなファイルを想定して動いているのかな?ということで、英語版のファイルがどんなものかを探してみることに。

TestAnalyzerPerf.java (77行目)では入力ファイルから1行ずつ文字列を読み込んでAnalyzerに処理させているだけというのがわかっています。なので、とりあえず、1行ずつ読めるような形式だと。次に、runAnalyzerPerf.pyの55行目でenwiki-20130102-lines.txtというものを読み込んでいます。が、これがよくわからないw

前回とりあえず動いたときに、src/python/constants.pyにいろんなファイルへのパスとかが記載されていたのを覚えていたので、その当たりから調べてみます。 52行目に約665万件のドキュメントだというような記載があります。前回のlocalrun.pyのファイルと似たような構造(1行に1記事が埋め込まれたTSVファイル)だろうと判断して、それを作りそうなプログラムを探してみました。 Wikiとかで検索して見つけたのがこのソースたちでした。

src/python/wikiXMLToText.py - それっぽい名前ですよね?
- 中身を見ると、第1引数のファイル(XML)からpageタグごとにデータを抜き出し、処理をしてからタブ区切りで第2引数のファイルに書き出してます。
src/python/WikipediaExtractor.py - これもそれっぽいですね。
- WikipediaExtractory.pyは界隈では有名なhttps://github.com/attardi/wikiextractorみたいです。こっちはなんとなく使い方はわかっています。
src/python/combineWikiFiles.py - これまたそれっぽい。
- 中身を見ると、1番目のコードで出力したデータに、2番めのコードで出力されたデータを元になにかしら処理をして、引数で与えられたファイルに出力する感じになってます。

ということで、完全に憶測ですが、日本語のWikipediaのXMLファイルを元に次のような流れでファイル作ってみればいいのかな?と。

jawiki-20200620-pages-articles.xml.bz2をwikimediaからダウンロードして、unbzip2で展開
python src/python/wikiXMLToText.py jawiki-20200620-pages-articles.xml jawiki-lines.txtで、1行ごとのデータを作る
- ちなみに、このプログラムは2箇所ほど修正しました。usernameタグが存在しないpageが出力されなさそうなので、デフォルトでusername: ""みたいなデータをattrってディクショナリに設定しました。
cat jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extractedで別途XMLからデータを抽出
python src/python/combineWikiFiles.py jawiki-lines.txt extracted/AA/wiki_00 jawiki-20200620-lines.txtで2と3の出力をかけ合わせる

で、まぁ、一応ファイルはできたんですが。。。前回のブログ記事でセットアップしたときにダウンロードされたファイルはtitle、日付、本文の3つのカラムしかないんですが、上記の手順で作り出したファイルにはいろんなカラムが存在するんですよね(2が出力する項目が結構ある)。。。

性能テスト用プログラムの書き換え

入力ファイルは出来上がったので、あとは、性能テストを走らせる部分の修正です。修正部分はプルリク見たほうが明確なので省略で。

実行してみた

で、実行してみました。せっかくなので、ブランチをbranch_8_5とmasterを対象にしてやってみました。実際にはsrc/python/runAnalyzerPerf.pyにディレクトリ名やブランチ名が直書きされてたので書き換えつつ実施した結果はこちら。

他の英語系のAnalyzerと同じグラフに載せてみたのですが、遅いので、下の方に表示されてます。で、下に凹んだ部分(23 Juneのところ)がbranch_8_5で実行したときの性能値でした。実際に遅くなってますね。ただ、他のAnalyzerの振れ幅も大きいので、別のグラフにしたほうがわかりやすくなるのかもなぁと思った次第です。

ということで、一応動いたんでプルリク出してみました。採用されるかなぁ?

一応誰得ブログはこれでおしまい。 Noriとかもこの感じで対応できるんじゃないかな?

luceneutil - マニアックなツールのセットアップ

Tue, 23 Jun 2020 21:58:29 +0900

LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。この問題自体はLucene 8.6.0以降で直る予定のようなのです(Elasticsearchへの影響範囲についてはこれが参考になるかな?)。で、これに関連して、ベンチマーク計らないとねという話が出ていて、昔から、LuceneのMikeさんがやっているベンチマークのグラフに載せるのがいいよねという話になっていました。どうも、これについては、Luceneの中にあるbenchmarkというプロジェクトではなく、MikeさんのGitHubリポジトリにあるプログラムで計測しているようです。

じゃあ、手元でこれどうやって動かすんだろう?ということでやってみたブログになります。おそらく、99.99%の人は興味ないと思うのでスルーしていただくのがいいと思います。備忘録のために書いてます。

とりあえずgit clone

公開されているリポジトリはこちらです。

手順通りに?

とりあえず、READMEにセットアップなどのやり方があったんで追っていくことに。とりあえず動くまでの手順は以下のとおりです。

ディレクトリを決める
- $LUCENE_BENCH_HOMEが起点になります。名前は何でもいいみたいです。
- cd $LUCENE_BENCH_HOME
リポジトリをクローン - git clone https://github.com/mikemccand/luceneutil.git utilです。
- コレ自体は問題なし。
- cd util
セットアップスクリプトを実行 - python src/python/setup.py -download
- ここがすごく時間かかります。6GBのファイルをゆっくりダウンロードしてきますので、一晩置いておきましょう(起きたら終わってた)
- $LUCENE_BENCH_HOME/dataにenwiki-20120502-lines-1k.txt.lzmaとwikimedium500.tasksいうファイルがダウンロードされている。
ダウンロードした圧縮ファイルを展開 - unlzma enwiki-20120502-lines-1k.txt.lzma
- macOSにlzmaのコマンド入ってるんですね。知らなかった。
- 終わったらcd ../で$LUCENE_BENCH_HOMEに戻っておく
ベンチマーク対象となるLuceneを用意 - git clone https://github.com/apache/lucene-solr.git
- READMEにはlucene_candidateとlucene_baselineって名前でって書いてあったのですが、これだと、この後の実行フェーズでエラーになりました。
- trunkとpatchというディレクトリにそれぞれ変更しました。localrun.pyを実行したらこのディレクトリ名だったので(相変わらず、自分、行きあたりばったりな対応してるなぁ。。。)
- とりあえず動くかどうかを確認したかったので、trunkとpatchはどちらもリポジトリをcloneしたものになってます。動いたのを確認したら、タグを指定して比較したいブランチをチェックアウトする予定。
trunkとpatchをビルド - ant jar *
localrun.pyを実行 - cd utilそして。。。
- 5.で記述したディレクトリ以外に1箇所Pythonのコードを書き換えた。
- src/python/benchUtil.py内部にhppc-0.8.1.jarのファイルの存在チェックをしているのだが、2020/06/23時点でのLuceneのリポジトリの依存関係だとhppc-0.8.2.jarになっており、ファイルが見つからないエラーが出たため、0.8.2に書き換えた。970行目付近。
- 改めて実行したら成功した。

まだ途中

とりあえず、実行するところまではできましたが、結果の見方とかちゃんと調べないとなぁ。いくつかローカルで対応したものについてはあとでGitHubにIssue立てとくべきだな。

と、動くのを確認したので、日本語周りの準備をしてみてるところです。

終わったこと
- 日本語のWikipediaのデータjawiki-20200620-pages-articles.xml.bz2をダウンロードして展開
試している途中
- WikipediaExtractorでXMLからデータを抽出 - cat ~/tmp/wiki/jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extracted
  - これは手順が違うかも????
- python src/python/wikiXMLToText.py ~/tmp/wiki/20200620-pages-articles.xml ./hoge.txt
  - これで、title、日付、本文が抜き出せそう?
  - この後にcombineWikiFiles.pyの実行かな?

って感じです。誰得だろうこれ???

KuromojiとSynonymとパッチ(LUCENE-9123)

Thu, 18 Jun 2020 00:00:00 +0000

Azure Cognitive Searchでの日本語向けAnalyzerの違い

Tue, 09 Jun 2020 17:44:00 +0900

Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものかを見ていくことにします。

Analyzerとは?

まずは、その前にAnalyzerとは何者か?というのを少しだけ。 Azure Cognitive Searchは転置インデックスを内部で作成して、検索を行っています。この、転置インデックスは、「単語」がどのドキュメントに入っているか?を素早く見つけることができるデータ構造となっています。

Azure Cognitive Searchは、この「単語」を入力された文章から生成するときに、Analyzerというものを利用します。 Analyzerは入力された文章をある規則に則って単語に分割する機能です。この「ある規則」が、各種言語や用途によって様々に用意されています。今回はこの中のja.luceneとja.microsoftという2種類のAnalyzerについて違いを見ていきます。

2種類のAnalyzerの違いはどんなもの?

このAnalyzerの挙動を見るためのエンドポイントとしてanalyzeというAPIがあります(詳細は昔のブログを参照)。

このAPIを利用して、Wikipediaのいくつかの文章を単語に区切って見て、 ja.microsoftがどんな動きをしているのか想像してみます(残念ながらja.microsoftの仕様?や挙動についてはページが見つからないため)。

もとの文章と解析結果(一部抜粋)

文章は、手元のElasticsearchに登録したjawikiのデータからランダムに抽出しています。また、自前のツールで生成したWikipediaのデータなので、まだ一部、見苦しい文字列になっています(そっちもなおさないと)。

1. 砂川（熊本県）

thumb|250px|right|上砂川橋より上流方砂川（すながわ）は、熊本県宇城市・八代郡氷川町を流れる二級河川。

この文字列から抽出された単語で特徴的なものを一部抜粋しました。

`ja.microsoft`	`ja.lucene`
250px	250
	px
上砂	上, 上砂川
川橋	砂川
	橋
宇城	宇
市	城市
二級	二
^	級

まず、最初の250pxですが、ja.microsoftでは、pxが単位であると判定しているのか、数値と合わせた単語として抽出されています。この場合、250で検索しても、この文字列はヒットしない形になるので、ノイズが減ることが考えられるかと。

上砂川橋という文字は、分割の仕方が別れました。 ja.luceneでは、上砂川という単語が地名として辞書に存在するために、このような分割になっています。ja.microsoftのデータは品詞の情報が取れないのですが、上砂、川橋ともに、名詞として辞書に存在しているのではないかなと。ja.luceneには川橋という単語は存在していないようでした。

宇城市(うきし)については、2005年に合併でできた市のようで、ja.luceneが利用している辞書には存在しない可能性があり、宇城という文字が抽出できてないと思われます。

最後は二級です。ja.luceneでは、数字と助数詞として分割されています。こちらも何かしらのロジックにより、二級という1単語でヒットできるように数字と単位?が合わせた単語で出てくる仕組みがja.microsoftなのかなと。

2. UEFA U-18女子選手権2000

UEFA U-18女子選手権2000は第3回目のUEFA U-18女子選手権である。決勝トーナメントは2000年7月27日から8月4日までフランスで行われ、ドイツが初優勝を果たした。

この文字列から抽出された単語で特徴的なものを一部抜粋しました。

`ja.microsoft`	`ja.lucene`
u-18, u	u
18, nn18	18
第3回目	第
	3
	回
	目
トーナメント, トナメント	トーナメント
2000年	2000
	年
7月	7
	月
27日	27
	日

数字を含む単語第3回目や2000年、7月などは、ja.microsoftは先程と同様、数字と単位の組み合わせを1単語として出力しています。

また、トーナメントという単語をトナメントという形で、長音を除去した形で出力しています。今回の文字列ではないですが、この他に、センターをセンターとセンタの2パターンの単語で出力するといったことを行っています。 ja.luceneの場合、単語の最後に長音がある場合だけセンタとして、長音を除去した単語が出力されます。これは、長音の表記ゆれに対応するためではないかなと。たとえば、インターフェースとインタフェース、インターフェイスのように、人や文章によって、間にでてくる長音を使ったり使わなかったりという表記ゆれに対応するためだと思われます。その他にも、イプロゥヴェトをイプロゥベトに、ネクストをネキストに、バラエティをバラエチにも変換するなどといった処理をしてくれるようです。カタカナの表記ゆれには強そうですね(これどうやってるんだろう?)。

ja.microsoftでは、nn18というちょっと変わった単語も出てきていました。純粋な数字の場合はnnと入力してくれるようで、数字だけで検索したい場合に利用できるのかな?これはドキュメントに書いておいてほしいかも?

共通点

ja.lucene、ja.microsoftともに、共通している動作として、「てにをは」といった単語は除去されていました。違いがあるものとしては、「より」(助詞-格助詞-一般)、「されている」(動詞-自立、動詞-接尾、助詞-接続助詞、動詞-非自立)、「ある」(助動詞)といったものはja.microsoftでは除去されずに出てきていました。ストップワード的に「てにをは」あたりを除去をしている感じでしょうか?

アルファベットで構成されている単語についても、基本はそのまま出力される挙動のようでした。

じゃあどっちがいいの?

残念ながらどちらがいいかは、一長一短かなぁと。 ja.luceneに関しては、Luceneの仕組みを利用しているので、Elasticsearchなどを使えば、個別の単語についてより詳細の情報を取得することが可能です(品詞、読みなど)。ja.microsoftについては、残念ながら手の入れようがないので、そういう動きのものだという割り切った使い方になるでしょうか? ただ、長音の除去による表記ゆれなどについては、便利な機能なので、そのあたりの問題に対応したい場合は、ja.microsoftを活用するのも良いかと思います。

個人的には、より細かい単語としてインデックスに登録できるもののほうが、柔軟な検索には対応できるのではないかなぁと考えています(Kuromojiの辞書をUniDicにするとか?も考えますが、これはAzure Searchではできないですが)。

まとめ

Wikipediaのデータをいくつか使って、ja.microsoftとja.luceneの違いについて、考察してみました。何かの役に立てばと。他に、これはどんな感じになるの?などありましたら、コメントいただければと。

Rust the book - 第13章

Thu, 04 Jun 2020 17:37:29 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

11章、12章はちょっと飛ばして、13章です。

第13章

イテレータ、クロージャです。 12章の話もちょっと出てくるのか。

クロージャ

基本的に、「変数には値が束縛されている」という固定観念がずっと頭にこびりついたままなので、クロージャに慣れないんだろうなぁ。そろそろこの固定観念をどうにかしないと。

匿名関数で、変数に保存したり引数に渡せる
ちょっと面白い話(ワークアウト)で実際に考えられる手法の説明がいくつか行われる

関数でリファクタリング
- これが自分がよくやるパターンかなぁ。クロージャになれてないので。。。
クロージャーを変数に束縛
- 呼び出しは関数みたいな感じ(ここで少し混乱)
- これだと、結局呼び出されたタイミングが複数回あるよね? -> あはりそうだった

ここで、閑話休題で、クロージャの型推論とか注釈の話。クロージャは狭い文脈だし、外に公開しているものでもないので、戻り値なども定義してなくてもいいよねとのこと。書くことも可能?なので、書いてわかりやすくするのもありなんだろうな。

推論についてはこれまで通りで、2回異なる型の変数で呼び出すと、2回目で怒られていた。

遅延評価(クロージャを保持する構造体!?)
- Fnトレイト
- トレイトとMatchの組み合わせだからこのへんで説明する形になるのか。
- これを真似すれば、いくつか処理を簡素化できるかもしれないなぁ、たしかに。
- なければ実行するみたいな処理を書きたいことがよくあるし。Javaだとnullで定義しといて、nullだったらみたいなのがあるから。

Cacherはサンプルだからこの名前でいいけど、自分だと、どんな名前にするかなぁ?
振る舞いは難しくなるのか。Cacher実装の限界を読むと。
関数にするとスコープが変わるのでアクセスできなくなると。。。コンパイラが教えてくれるのは便利だな。
環境から値をキャプチャする3つの方法
- 多分この話が一番クロージャに意味がある話なんだと思う。

イテレータ

回しましょう。

便利。ただ、こういう書き方に自分が慣れてないので、そっちを補正しないとなぁ。
どれがイテレータ?っていうのを判別するのがちょっとむずかしい(慣れの問題かなぁ)
イテレータアダプタ便利。どんなのがあるのか?とかがやっとわかってきた。
パフォーマンスに関しては、うーん、どうなんだろう?という感想だった。

Rust the book - 第10章

Thu, 28 May 2020 18:06:55 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

第10章

ジェネリック、トレイト、ライフタイムです。手強そう。

いきなり関数の切り出し方みたいな話が始まって面食らいました。

ジェネリックなデータ型

ジェネリックはJavaにもあるので、それほど理解に苦しむことはなかったです。また、OptionやResultですでに経験済みでしたし。

ただ、impl<T> Point<T>{、このメソッド定義は少し最初は戸惑いました。言われてみれば、なるほどなんですけど。

コンパイル時にコンパイラが単相化を行うことにより、必要最低限なコードを生成してくるというのは理にかなっているなぁと。

トレイト: 共通の振る舞いを定義する

出だしにもありますが、「インターフェイス」という機能に類似していると考えると割とすんなりと理解が進みました。ただ、Javaだと、インターフェースはクラスとセットなため、トレイとの実装に関する記述方法は少し戸惑いが。

デフォルト実装との組み合わせはAbstractに似た処理になるなと考えながら読みすすめました。

「トレイト境界」という日本語には少し違和感を覚えましたが、線引をして、制限をかけるという理解でいいのかな?

実際には#[derive()]などで、トレイトを自分で実装する必要がないなどの、便利機能も用意されており、このあたりのコードの追い方がまだ少し慣れていないかもなぁと。便利なんですけど。。。

少しだけ気になったので、動作確認したのは次の実装です。

トレイトで宣言されている関数と構造体が独自に実装する関数の名前がかぶるとどうなるのかという実験です。構造体独自のメソッドが優先される感じになりそう。

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}
pub trait Summary {
    fn summarize_author(&self) -> String;
    fn summarize(&self) -> String {
        // {}さんからもっと読む
        format!("(Read more from {}...)", self.summarize_author())
    }
}
impl Tweet {
    fn summarize_author(&self) -> String {
        format!("hoge {}", self.username)
    }
    fn to_string(&self) -> String {
        format!("fuga")
    }
}
impl Summary for Tweet {
    fn summarize_author(&self) -> String {
        format!("@{}", self.username)
    }
}
pub fn summary<T: Summary>(hoge: &T) {
    println!("{}", hoge.summarize_author());
}
pub fn main() {
    let tweet = Tweet {
        username: String::from("horse_ebooks"),
        content: String::from("of course, as you probably already know, people"),
        reply: false,
        retweet: false,
    };
    println!("{}", tweet.summarize_author());
    summary(&tweet);
    println!("{}", Summary::summarize_author(&tweet));
}

ライフタイムで参照を有効化する

言われてみればそうですが、プログラマが色々考えないとまぁ、行けないんですねという感想。

ただ、借用チェッカーが賢くやってくれるおかげで、全てにライフタイム注釈をつけなくて良くなっているというのがわかりました。逆に言うと、なんとなくRustを書き始めてしまったので、それを知らずに書いたせいで、コンパイラに怒られてても「?」となっていたのかと。。。

疑問点がいくつかあって、

通常はどんなライフタイム注釈をみんな書いてるんだろう?'aとかざっくりしすぎてる?
1つのメソッド、関数にライフタイム注釈が大量に出てくるような書き方をした場合は設計がおかしいのでは?って考えたほうがいいのかも?
ジェネリックな型とライフタイム引数の順序を入れ替えてみても動くだろ?とおもって入れ替えてみたら怒られた。

あとは、構造体+ジェネリックが絡んできたら少しこんがらがってきそうっという感じです。まぁ、これから先は実際に書いてみないことにはわからないんだろうなと。

まとめ

読みました。実際にはプログラムを書きながら慣れていく感じだろうなぁと。まだまだ、あれ?ジェネリックってどう書くんだっけ?とか、ライフタイム注釈どうやって付けて、使うときはどうすんだ?みたいになりながら、出てくるサンプルを少し変えてみてはどうやって動くんだろうこの場合?みたいなことをやってました。次は、11章、12章を少しだけ自習しつつ、13章に入る予定です(知り合いと一緒に読みすすめてる)。

Azure Cognitive Searchのリクエストのロギング

Tue, 26 May 2020 17:22:47 +0900

今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータとボディをログに保存する方法について紹介します。

動機

アプリケーションでリクエストを組み立てて、SDK経由で送信していると、最終的にAzure Cognitive Searchに対して送信されているリクエストのパラメータや検索条件などをひと目で見たいことがあります。アプリケーションでは、ソート条件や、クエリ文字列の組み立てなどの処理は異なる場所で行われたりしますので。

また、公式リファレンスでは、機能の説明はRest APIの使い方と組み合わせで説明されることが多いです。

ということで、SDKを利用しているアプリからAzure Searchへ送信されているリクエストをログに保存する方法を調べてみました。

方法

調べてみるといくつかの手段を取ることができそうだとわかりました。実際に調べて実装する方法を4種類ほど試してみたのでブログに残しておきます。なお、2020年4月時点でのSDKとAzureの仕組みに基づいたブログになります。最新版ではお手軽な方法があるかもしれません。

DelegatingHandlerを利用する
ServiceClientTracingの機能を利用する
Azure Application Insightsを活用する
Azure Cognitive Searchのコンソールにある診断情報の機能を利用する

1、2はAzure Cognitive SearchのSDKのリファレンスから当たりを付けて見つけた方法です。 3はApplication Insights、4はAzure Cognitive Searchの機能になります。これらの方法について個別に説明していきます。

1. DelegatingHandleを利用する

まずは、SDKでロギングの機能がないかを調べて見つけた機能がこちらです。 SDKのSearchServiceClientのコンストラクタの引数にDelegatingHandlerというものが渡せることを発見しました。

これは、.NET FrameworkのHttpのAPIに存在するクラスで、HTTPのクライアントがHTTPの送受信時に、処理を挟むことができる機能です。フレームワーク側で、LoggingHttpMessaggeHandlerというクラスを用意してくれていましたが、残念ながらこちらは、リクエストとレスポンスのヘッダのみをロギングするクラスでした。ということで、リクエストボディをログに出力したい場合は独自に拡張してやる必要があります。なお、ロギングにはMicrosoft.Extensions.LoggingのILoggerを使用します。

また、Azure Cognitive SearchのSDK側に違う問題点もありました。チュートリアルにあるように、検索するときには、SDKは次のような使い方を想定しています。

        // Create a service and index client.
        _serviceClient = new SearchServiceClient(searchServiceName, new SearchCredentials(queryApiKey));
        _indexClient = _serviceClient.Indexes.GetClient("hotels");

インデックス用のクライアントを取得するために、GetClient(インデックス名)というメソッドを使用します。このGetClientメソッドのバリエーションとして、DelegatingHandlerを受け取るメソッドがないのです。。。

ということで、DelegationHandlerを活用する方法としては、以下の2つを実装する必要があります。

CustomなLoggingHttpMessageHandlerクラスを実装
GetClientと同等の処理をDelegatingHandlerを引数にしたものを実装する

以上の2つを実装し、アプリケーション側から2で作成したGetClientを呼び出すことで、リクエストをボディも含めてログ出力することが可能になります。以下は実装例です。

CustomHttpMessageHandlerクラス。

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

namespace AzureSearchSample
{
    public class CustomLoggingHttpMessageHandler : DelegatingHandler
    {
        private readonly ILogger _logger;
        private readonly bool _logContent = false;

        public CustomLoggingHttpMessageHandler(ILogger logger, bool logContent)
        {
            if (logger == null)
            {
                throw new ArgumentNullException(nameof(logger));
            }

            this._logger = logger;
            this._logContent = logContent;
        }


        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            if (request == null)
            {
                throw new ArgumentNullException(nameof(request));
            } 
            await Log.RequestStart(this._logger, request, this._logContent);
            var stopwatch = new Stopwatch();
            HttpResponseMessage response = await base.SendAsync(request, cancellationToken).ConfigureAwait(false);
            stopwatch.Stop();
            await Log.RequestEnd(this._logger, response, stopwatch.Elapsed);

            return response;
        }

        private static class Log
        {
            private static class EventIds
            {
                public static readonly EventId RequestStart = new EventId(100, "RequestStart");
                public static readonly EventId RequestEnd = new EventId(101, "RequestEnd");
            }

            public static async Task RequestStart(ILogger logger, HttpRequestMessage request, bool logContent)
            {
                StringBuilder message = new StringBuilder();
                message.AppendLine($"Sending HTTP request {request.Method} {request.RequestUri}");
                if (logger.IsEnabled(LogLevel.Trace))
                {
                    LogHttpHeaders(message, request.Headers);
                    await LogHttpContent(message, request.Content, logContent);
                    logger.Log(
                        LogLevel.Trace,
                        EventIds.RequestStart,
                        message,
                        null,
                        (state, ex) => state.ToString());
                }
            }

            public static async Task RequestEnd(ILogger logger, HttpResponseMessage response, TimeSpan duration)
            {
                StringBuilder message = new StringBuilder();
                message.AppendLine(
                    $"Recieving HTTP response after {duration.TotalMilliseconds}ms - {response.StatusCode}");
                if (logger.IsEnabled(LogLevel.Trace))
                {
                    LogHttpHeaders(message, response.Headers);
                    await LogHttpContent(message, response.Content, false);
                    logger.Log(
                        LogLevel.Trace,
                        EventIds.RequestEnd,
                        message,
                        null,
                        (state, ex) => state.ToString()
                        );
                }
            }

            private static void LogHttpHeaders(StringBuilder message, HttpHeaders headers)
            {
                if (headers == null) throw new ArgumentNullException(nameof(headers));
                foreach (KeyValuePair<string, IEnumerable<string>> header in headers)
                {
                    foreach (string value in header.Value)
                    {
                        message.AppendLine($"{header.Key}: {value}");
                    }
                }
            }

            private static async Task LogHttpContent(StringBuilder message, HttpContent content,
                bool logContent)
            {
                if (content != null)
                {
                    foreach (KeyValuePair<string,IEnumerable<string>> header in content.Headers)
                    {
                        foreach (string value in header.Value)
                        {
                            message.AppendLine($"{header.Key}: {value}");
                        }
                    }

                    if (logContent)
                    {
                        string contentBody = await content.ReadAsStringAsync();
                        message.AppendLine(contentBody);
                    }
                }
            }
        }
    }
}

GetClientの実装


        private ISearchIndexClient GetClient(string indexName, params DelegatingHandler[] handlers)
        {
            var rootHandler = _searchServiceClient.HttpMessageHandlers.OfType<HttpClientHandler>().SingleOrDefault();
            var indexClient =
                new SearchIndexClient(_searchServiceClient.SearchServiceName, indexName,
                    _searchServiceClient.SearchCredentials, rootHandler, handlers)
                {
                    SearchDnsSuffix = _searchServiceClient.SearchDnsSuffix
                };

            indexClient.HttpClient.Timeout = _searchServiceClient.HttpClient.Timeout;
            return indexClient;
        }

出力されるログ例

2020/04/14 19:17:53.591|TRACE|Sending HTTP request POST https://サービス名.search.windows.net/indexes('インデックス名')/docs/search.post.search?api-version=2019-05-06
client-request-id: be02140f-3a07-48cc-b018-d8aa5e819bc3
Accept-Language: en-US
Accept: application/json; odata.metadata=none
api-key: APIキー
User-Agent: FxVersion/4.700.20.11803
User-Agent: OSName/MacOs
User-Agent: OSVersion/Darwin.19.4.0.Darwin.Kernel.Version.19.4.0.Wed.Mar.4.22.28.40.PST.2020.root.xnu.6153.101.6.15RELEASE.X86.64
User-Agent: Microsoft.Azure.Search.SearchIndexClient/10.100.19.52907
Content-Type: application/json; charset=utf-8
{
  "count": false,
  "facets": [],
  "queryType": "simple",
  "scoringParameters": [],
  "search": "azure",
  "searchMode": "any"
}
 |AzureSearchSample.SearchService|EventId_Id=100, EventId_Name=RequestStart, EventId=RequestStart

メリット、デメリット

Azure Cognitive Searchの検索の処理だけを対象にリクエストのログを出力することが可能です。また、影響範囲はアプリケーションだけに閉じていますので、デバッグ目的などでログ出力したい場合に、自分だけの手元でログの確認が可能になります。

デメリットとしては、独自に実装しなければいけない範囲が広いことです。

2. ServiceClientTracingの機能を利用する

Microsoft.Rest.ClientRuntimeというライブラリをAzure Cognitive Searchは利用しています。このライブラリにServiceClientTracingというクラスが存在します。なにやら、クライアントの処理のトレースができそうです。

Azure Cognitive SearchのSDKの実装がGitHubに公開されており、検索リクエストの処理を投げる直前に、このトレースの仕組がONになっていると、ServiceClientTracing.SendRequestメソッドを呼び出していました。

実際にSendRequestメソッドに送られたものに対して何かしらの処理を行うのは、IServiceClientTracingIntercepterインターフェースを実装したクラスになります。このインターフェースの実装がLog4Netに存在します。Log4Netを利用している場合は、これを活用すれば楽ができます。

実際にServiceClientTracingを有効にするには、以下の2行を呼び出すだけです。

ServiceClientTracing.IsEnabled = true;
ServiceClientTracing.AddTracingInterceptor(new Log4NetTracingInterceptor());

あとは、Rest.ClientRuntimeがよしなにやってくれます。 1とは異なり、トレースログなので、リクエストのボディについても出力してくれます。

2020-05-26 19:09:04,058 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1
instance: Microsoft.Azure.Search.DocumentsProxyOperations
method: SearchPost
parameters: {searchRequest=Microsoft.Azure.Search.Models.SearchRequest,clientRequestId=,cancellationToken=System.Threading.CancellationToken}
2020-05-26 19:09:04,164 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1
request: Method: POST, RequestUri: 'https://サービス名.search.windows.net/indexes('インデックス名')/docs/search.post.search?api-version=2019-05-06', Version: 2.0, Content: System.Net.Http.StringContent, Headers:
{
  client-request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc
  Accept-Language: en-US
  Accept: application/json; odata.metadata=none
  api-key: APIキー
  Content-Type: application/json; charset=utf-8
}

Body:
{
{
  "count": false,
  "facets": [],
  "queryType": "simple",
  "scoringParameters": [],
  "search": "azure",
  "searchMode": "any"
}
}

2020-05-26 19:09:04,459 [Thread Pool Worker] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1
response: StatusCode: 200, ReasonPhrase: 'OK', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
  Cache-Control: no-cache
  Pragma: no-cache
  request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc
  elapsed-time: 72
  OData-Version: 4.0
  Preference-Applied: odata.include-annotations="*"
  Strict-Transport-Security: max-age=15724800; includeSubDomains
  Date: Tue, 26 May 2020 10:09:04 GMT
  Content-Type: application/json; odata.metadata=none
  Expires: -1
  Content-Length: 376
}

メリット、デメリット

Log4Netを利用しているアプリの場合、2行だけを追加することで実装が完了するのがお手軽な点です。

難点としては、Rest Client全てにたいしてトレース処理が入ってしまうので、Azure Cognitive Search以外にもRestクライアントを利用しているものが存在した場合、ログの量が増えてしまいます。また、検索以外の処理でもトレースされてしまうのもデメリットになります。

Log4Net以外のログ機構を使用している場合は、自分でIServiceClientTracingInterceptorを実装する必要も出てきます(参考:StackOverflow)。

3. Azure Application Insightsを活用する

ここから紹介する3と4については、ログの出力先がAzure上になります。

AzureのApplication Insightsを利用する方法です。 Azure?.NET?のアプリケーションパフォーマンスモニタリングのサービスです。

Application Insightsを自分のアプリケーションに設定することで、アプリケーションのパフォーマンス監視に関する情報がAzure上のApplication Insightsリソースに送信されるようになります。

ただ、Application Insightsのデフォルトの機能では、URL程度の情報だけが送信されます(参考:しばやんさんのブログ)

こちらも拡張機能が用意されており、ITelemetryInitializerのインターフェースを実装したクラスを用意することで、独自の情報をApplication Insightsに出力することが可能となります。詳細についてはしばやんさんのブログを参考にしてもらうのが良いかと。

Httpリクエストを出力する実装例は次のとおりです。ただ、ちょっとうまく行かないパターンがあったので、コメントアウトとして残してあったりします(なんでだろう?)

using System.Collections.Generic;
using System.Net.Http;
using System.Net.Http.Headers;
using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;

namespace AzureSearchWebSample.ApplicationInsights
{
    public class HttpRequestInitializer : ITelemetryInitializer
    {
        public void Initialize(ITelemetry telemetry)
        {

            if (!(telemetry is DependencyTelemetry dependency))
            {
                return;
            }

            HttpRequestMessage requestMessage = null;
            HttpRequestHeaders requestHeaders;
            if (dependency.TryGetOperationDetail("HttpRequest", out var details) &&
                details is HttpRequestMessage request)
            {
                requestMessage = request;
                requestHeaders = request.Headers;            
                if (requestMessage.Method == HttpMethod.Post)
                {
                    string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult();
                    dependency.Properties.Add("RequestBody",contentBody);
                }
            }
            else if (dependency.TryGetOperationDetail("HttpRequestHeaders", out details) &&
                     details is HttpRequestHeaders headers)
            {
                requestHeaders = headers;
            }
            else
            {
                return;
            }

            foreach (KeyValuePair<string,IEnumerable<string>> header in requestHeaders)
            {
                foreach (string value in header.Value)
                {
                    dependency.Properties.Add(header.Key, value);
                }
            }
            //この実装の場合は出力されなかった。なぜ?
            // if (requestMessage != null && requestMessage.Method == HttpMethod.Post)
            // {
            //     string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult();
            //     dependency.Properties.Add("RequestBody",contentBody);
            // }
        }
    }
}

メリット、デメリット

すでにApplication Insightsを利用している場合はついでに情報が出力されるので便利です。かつ、常にリクエストログを見れるようにしておく場合はとても便利だと思います。

Application Insightsを利用していない場合は、そこから導入しなければならなくなるので、手間が増えるかもしれないです。

4. Azure Cognitive Searchのコンソールにある診断情報の機能を利用する。

最後はAzure Cognitive Searchの診断ログを有効にする方法です。ここまで説明してきた方法の中で、一番お手軽な方法です。。。

これまでは、リクエストボディを出力する方法を考えていましたが、Azure Cognitive Search側の診断ログを有効にすると、リクエストボディで送信したものが、Azure Cognitive Search側で、クエリパラーメータとして、診断ログに出力されます(診断ログのQuery_s)。

あとは、Azureのコンソールで当該時間のログを見ればよいだけです。以下は出力されたログの一部です。Description_sにはURLのパスが記載されています。

診断ログ例(一部)

Description_s      POST /indexes('multi-field-test')/docs/search.post.search
Query_s            ?api-version=2019-05-06&searchMode=Any&search=azure&queryType=Simple&$count=false

メリット、デメリット

アプリケーション側に手を入れる必要がなのでお手軽です。一度設定しておけばコンソール側でログをいつでも見れるので便利です。

リクエスト量が多くなってしまうと、ログの量も多くなり、費用がかさむ恐れがあります。また、複数の人が触る環境の場合は自分で送信したリクエストがどれだったのか?といった状況に陥る可能性はあります。

その他は?

Azureに対してではないですが、昔似たようなことをやるときにやっていた方法として、ローカルにプロキシサーバーを起動し、そのプロキシサーバー経由でアプリケーションから、Azureに接続することで、リクエストを保存する方法もあります。ざんねんながら、未調査ですがアプリなどにはそれほど手を入れる必要はないかと思います。

まとめ

ちょっと送信リクエストの内容が見てみたいという話でしたが、いろいろな手段が存在しました。自分の状況、環境に合わせて手段を選択肢てみるのがいいかと思います。まずは、簡単な診断ログあたりからでしょうか?

Microsoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ

Fri, 22 May 2020 12:10:41 +0900

Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。

そこで、Azure Cognitive Searchのセッション(MyBuild - Cognitive Search： The pocket-knife for knowledge mining)があったので、見てみました。内容がどんなものかをメモっておきます。最初はCognitive Searchがどんなものよという説明でした。

ビルトインスキルの拡充の話

データソースからデータを取り出し、エンリッチし、検索エンジンに保存するという、パイプラインが組めるようになっています。

このパイプラインで利用できる処理のことがスキルと呼ばれています。ここで利用できるビルトインスキルが拡充されますよという話でした。ちょっとだけ抜き出すと以下のとおりです。

Azure Machine Learning
Text translation
Brand detection
Object detection

スキルのリファレンスには載ってるものと載ってないものがあるので、今後追加されてくのかな? Brand detectionがどんなものなんだろう?ってのがちょっと気になりました。どっかにデモとかあるかなぁ?

スキルセットのための新機能 : Debug Sessionのデモ

上記のスキルを組み合わせてパイプラインを組んで、データソースから取り出したデータをエンリッチしてから、検索エンジンに入れる処理をかけるのですが、その処理のデバッグ用に新しいGUIの機能が追加されてますよという紹介とデモでした。

Tutorial： Use Debug sessions to diagnose, fix, and commit changes to your skillset - Azure Cognitive Search | Microsoft Docs

Manage Identityの話

Azure Cognitive Searchにデータを登録するパイプランの最初の段階で、各種データソースにアクセスが必要です。このアクセス時にコネクションの設定にアカウントキーなども含めてましたが、これをコネクション設定ではなく、専用の管理機能が用意されましたよという話でした。

Set up a connection to a data source using a managed identity (preview) - Azure Cognitive Search | Microsoft Docs

QA

Similarityとかの話
- BM25になってるよとか
SDKの話とか
ほかにRelevancyの話
- Analyzerをデフォルトのままじゃなくてちゃんと考えて使いましょう(例:各言語用のAnalyzerがいっぱいあるよとか)

こんな感じでした。

Elastic Stack 7.7がリリースされた

Fri, 15 May 2020 11:17:17 +0900

ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてしまいました。

簡単ですが、リリースブログを見ながら気になった点をメモしとこうかと。

本家のリリースブログ

いっぱいあるんですよ、これが。まぁ、内容かぶってるのもあるんですが。

Elastic Stack

Enterprise Search系

Observability系

個人的に気になったもの

で、全部読んだわけではないのですが、個人的に気になった機能についてメモを残しておきます。多分に検索によっている可能性がありますが、お気になさらず。また、ブログとドキュメントを元に気になるところをピックアップしてます。実際の実装とか動作に関してはまだ未調査の段階です。

Async Search - Elasticsearch

ElasticsearchのAPIとして非同期に検索できるAPIが実装されました (公式リファレンス)。大量データを検索が終了してから検索結果を返すのではなく、クエリは実行しつつわかったところまでは都度取得したいという要望だったり、Coldインデックスのように遅いストレージ上にあるデータへの検索でも少しずつ取得できるようにという具合だと思います。ログとか大量に扱う場合にまぁ、ほしいですよね。今回はEsのリリースがメインで、今後はKibanaなどとの連携だったり色々改善していくよという話みたいです(Kibanaの一部の機能は利用しているみたい)。

ライセンスとサブスクリプションのレベル

Elastic License
Basic

気になるところ(と、予想とか)

仕組みがどうなっているか?
- Search APIと同等のリクエストパラメータが使える。が、いくつか制約はありそう
- おそらくTask Manageerで検索してる処理が管理され、レスポンスにはIDが発行されて、そのIDで処理の進み具合を取得する感じ。
Shard単位?Segment単位?
- 内部的にはShard単位で検索処理を扱ってるので、Shard単位がとりあえず楽そう?
Aggsとかも?
- 対象の模様
Sortは?
- 有効。ソートのフィールドがインデックス対象だった場合は、そのデータの統計値を使ってShardをソートするっぽい(公式リファレンスのNOTE参照)

Reduced consumption of heap - Elasticsearch

ヒープの使用量が7.7で減ってるよというブログも別途ありました。

元になっているLuceneの実装に関するIssueが「［LUCENE-8635］ Lazy loading Lucene FST offheap using mmap - ASF JIRA」です。ヒープ上に展開していたデータをmmapで扱えるようにすることで、ヒープのメモリを削減してる。

で関連して、これがLuceneで操作できるようになって(「Use reader attributes to control term dict memory useage by s1monw · Pull Request #42838 · elastic/elasticsearch」)、そこからEsに取り込まれたと。

_idをoff-heapにする話はここ(Move the terms index of _id off-heap. by jpountz · Pull Request #52405 · elastic/elasticsearch)にあった。

これに関連して、ヒープサイズの推奨について再考が必要かも?というIssue(Reconsider our recommendations for heap size? · Issue #52561 · elastic/elasticsearch)も上がってる。

Painless Lab - Kibana

ほんとにPainless?と言う話はさておき、_script APIでexecuteはできていましたが、やはりもう少し楽に実行したいですよね?ということで画面ができたみたいです。

シンタックスハイライトとかもできるので、より簡単に使えるようになってますね。まだ、ベータなので足りないContextとかもあるっぽいけど。

ライセンスとサブスクリプションのレベル

Elastic License
Basic?

まだベータだからか、サブスクリプションのページにはなかった。公式ドキュメントとGitHubのリポジトリから、Elastic Licenseであることは判明。

気になるところ(と、予想とか?)

制限事項がどんなものか?
- 使えるContextがまだ少ない?まだGAではない
サジェストがどのくらい効くのか?
- シンタックスハイライトはあるけど。まだかなぁ?

その他Elasticsearch関連

7.7リリースのハイライトが別途用意されています。

7.7.0 release highlights | Elasticsearch Reference ［7.7］ | Elastic

こっちで気になるのは、ClassificationとかTransformsあたりかなぁ。ML関連の機能で。

Workplace Search GA

これは別のブログに書くかな。

気になるところ

Betaと何が変わったのか?
APIとかどういう形で提供されるのか?そもそも提供されるのか?

どんな機能?みたいなのも書く予定です。

Data VisualizerでFilebeatのConfigをサジェスト - Kibana and Filebeat

Kibanaの画面からデータをちょっと?(100MB)だけアップロードして、Elasticsearchにサクッとデータ登録できる機能が実はあります。この機能の拡張として、Filebeatの設定だとこんな感じに作れるよ?というのを提示してくれるようになったみたいです。手元にあるファイルを定期的に読み込むときに、設定を書く下地ができるのは便利じゃないかな?

ライセンスとサブスクリプションのレベル

Elastic License
Basic

Data Visualizerってどんなもの?というのはここにブログがあります。残念ながらKibanaとかの公式リファレンスには使い方のページがないんだよなぁ。

APMのサービスマップ - APM and Kibana

アプリケーションアーキテクチャのどこでAPMが動作しているか、どこと通信しているかという、APMのエージェントが入っているアプリ間のつながりをKibana上で可視化できる機能っぽいです。まだ、ベータみたいですが、面白そう。Azure Application Insightのアプリケーションマップに似てる気がします。

ライセンスとサブスクリプションのレベル

Elastic License
Platinum

気になるところ

どうやって作ってる(つながりをどうやて判断してる)のか?
- 分散トレーシングのデータを元に誰がどこと通信してるってのは取れるんじゃなかろうか?

Log categorization and contextual examples - Kibana and Elasticsearch

7.6から入ってたっぽいですが、ログの分類をMLの機能を使ってできるものが、LogsのUIとかでさらに使いやすくなった模様。

ライセンスとサブスクリプションのレベル

Elastic License
Platinum

気になるところ

7.6の機能から追いかけないとなぁ。。。
- 似たようなログをカテゴリーごとに分析できるようになるので、プラスMLの仕組みでこれまでとは異なる種類のログが出始めたみたいなことが分析できそう。

まとめ

眺めるだけで時間かかりましたが、まぁ、相変わらずいっぱいありますね。興味のあるところの濃淡が出た感じになりましたが、気になる点をピックアップしてみました。おかしなところとか、ここはどういう意味?などあればツッコミお願いします。

Rust the book - 第9章

Thu, 14 May 2020 18:43:26 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

第9章

エラー処理です。 NLP100とか、いくつかのプログラムを書いていて、なんとなくは扱っていますが、きちんと勉強しないと。

とりあえず、「Rustには例外は存在しません。」が一番知っておくことかな。

panic!で回復不能なエラー

panic!マクロでスタックを巻き戻して掃除をして終了。
- 異常終了(panic = 'abort')にもできる。
「RUST_BACKTRACEを0以外の変数にセットして実行」 *

Resultで回復可能なエラー

expect()は気持ち悪い名前じゃないかなぁ?
ここでio::Errorではないものもエラーが発生する場合には

panic!すべきかするまいか

まとめ

「Rustには例外は存在しない」ので、回復不能か可能かを考えつつ処理を書こうと。

第2章の12から19まで(言語処理100本ノック2020)

Tue, 12 May 2020 12:23:29 +0900

Rustで言語処理100本ノックの第2章の残りです。

前回はこちら。

ちなみに、標準入力から受け取る処理は書いてないです。出力に関してはファイル分割、保存と支持があるもの以外は文字列として取り出すところで終わっています。

12. 1列目をcol1.txtに，2列目をcol2.txtに保存

pub fn extract_column(input_file_name: &str, num: usize, output_file_name: &str) {
    let input_f = File::open(input_file_name).expect("file not found");
    let read_buf = BufReader::new(input_f);
    let mut output_f = OpenOptions::new()
        .write(true)
        .create(true)
        .open(output_file_name)
        .expect(format!("can't open file[{}] with write option", output_file_name).as_str());
    read_buf.lines().for_each(|line| match line {
        Ok(line) => {
            let columns: Vec<_> = line.split('\t').collect();
            writeln!(output_f, "{}", columns[num]);
            output_f.flush().expect("Error during flush");
        }
        Err(_) => panic!("parse error "),
    });
}

13で出力結果を利用するので入力として出力ファイル名も受け取るようにしました。問題としては、1列目と2列目を別々に出力すればいいので、1回の処理で書いても良かったのですが、1回1ファイルの出力という形で実装しました(効率は悪い)。

改行コードあたりを考えるのがめんどくさかったのでwriteln!マクロでファイルに書き出しています。が、普通にwriteメソッドで改行コードを追加しても良かったのかなと。

あとは、出力先ファイルが存在しない場合だけopenするようにOpenOptionsを利用してみています。

flushを呼び出すべきなのかどうか?を調べないとな。。。

13. col1.txtとcol2.txtをマージ

pub fn merge_files(col1_file: &str, col2_file: &str, output_file_name: &str) {
    let col1_buf = BufReader::new(File::open(col1_file).expect("file not found"));
    let col2_buf = BufReader::new(File::open(col2_file).expect("file not found"));
    let mut output_f = OpenOptions::new()
        .write(true)
        .create(true)
        .open(output_file_name)
        .expect(format!("can't open file[{}] with write option", output_file_name).as_str());
    col1_buf
        .lines()
        .zip(col2_buf.lines())
        .for_each(|(col1, col2)| {
            let col1 = col1.expect("parse error col1");
            let col2 = col2.expect("parse error col2");
            writeln!(output_f, "{}\t{}", col1, col2);
            output_f.flush().expect("Error during flush");
        });
}

2つのファイル名を入力として受け取り、タブでくっつけて出力します。 zipを利用することで、2つのイテレーターを同時に回しています。

14. 先頭からN行を出力

pub fn head(input_file_name: &str, lines: usize) -> String {
    let buf = BufReader::new(File::open(input_file_name).expect("file not found"));
    let mut head = String::new();
    buf.lines().take(lines).for_each(|line| {
        head.push_str(format!("{}\n", line.expect("parse error")).as_str());
    });
    return head;
}

イテレーターのメソッドにtakeがあります。これを利用することで、引数に指定した数のエレメントが取得できるので、これでheadが実現できます。

15. 末尾のN行を出力

pub fn tail(input_file_name: &str, lines: usize) -> String {
    let buf = BufReader::new(File::open(input_file_name).expect("file not found"));
    let mut tail = String::new();
    let line_count = word_count(input_file_name);
    buf.lines().skip(line_count - lines).for_each(|line| {
        tail.push_str(format!("{}\n", line.expect("parse error")).as_str());
    });
    return tail;
}

tailの場合は少し複雑で、11で作成した行数をカウントするメソッドで総行数を取り出し、そこから引数で指定された行数を引き算した数(=出力しない行数)を、イテレーターのskipメソッドの引数に渡しています。これにより、指定された数のエレメントをスキップしたあとの処理がかけます。

16. ファイルをN分割する

pub fn split_files(
    input_file_name: &str,
    num: usize,
    output_file_prefix: &str,
    output_file_suffix: &str,
) {
    let total = word_count(input_file_name) as f64;
    let lines_in_file = total / num as f64;
    let lines_in_file = lines_in_file.ceil() as usize; //
    let buf = BufReader::new(File::open(input_file_name).expect("file not found"));

    let output_files: Vec<File> = create_file_vec(output_file_prefix, num, output_file_suffix);

    println!("split file each {} lines.", lines_in_file);
    let mut lines = buf.lines();

    for mut output_f in output_files {
        let mut current = 1;
        while current < lines_in_file + 1 {
            let line = lines.next();
            if let Some(line_rs) = line {
                if let Ok(line_str) = line_rs {
                    writeln!(output_f, "{}", line_str);
                }
            }
            current = current + 1;
        }
        output_f.flush().expect("error during flush");
    }
}

fn create_file_vec(output_file_prefix: &str, num: usize, output_file_suffix: &str) -> Vec<File> {
    let mut files = Vec::with_capacity(num);
    for i in 0..num {
        let output_file_name = format!("{}{}{}", output_file_prefix, i + 1, output_file_suffix);
        let output_f = OpenOptions::new()
            .write(true)
            .create(true)
            .open(output_file_name.as_str())
            .expect(format!("can't open file[{}] with write option", output_file_name).as_str());
        files.push(output_f);
    }
    return files;
}

ちょっと長いですね。

入力としては、分割するファイル数Nが指定されます。まずは、総行数/Nで各ファイルに保存されるべき行数を計算します。次に、2つ目の関数をつかって、必要な数のファイルオブジェクトをベクトルとして生成します。

ファイルオブジェクトのベクトルの要素を元にしたfor文を回しつつ、それぞれのファイルに必要な行数を出力している処理になっています。

総行数がNで割り切れない場合にceilで切り上げした行数にするというちょっとした処理を入れてあります。

17. １列目の文字列の異なり

pub fn count_uniq_words(input_file_name: &str, col: usize) -> usize {
    let mut words = HashSet::new();
    let buf = BufReader::new(File::open(input_file_name).expect("file not found"));
    buf.lines().for_each(|line| match line {
        Ok(line_str) => {
            let columns: Vec<_> = line_str.split('\t').collect();
            words.insert(columns[col].to_string());
        }
        Err(_) => panic!("parse error "),
    });
    return words.len();
}

HashSetを利用することでユニーク性を担保して、最後はHashSetの数を数え上げれば終了です。

18. 各行を3コラム目の数値の降順にソート

pub fn sort_on_col3(input_file_name: &str) -> String {
    let mut lines: BTreeSet<Line> = BTreeSet::new();
    let buf = BufReader::new(File::open(input_file_name).expect("file not found"));
    buf.lines().for_each(|line| match line {
        Ok(line_str) => {
            let columns: Vec<_> = line_str.split('\t').collect();
            let num: u32 = columns[2].parse().expect("parse error");
            let line = Line {
                line: line_str,
                num,
            };
            lines.insert(line);
        }
        Err(_) => panic!("parse error"),
    });
    let mut sorted = String::new();
    lines.iter().for_each(|line| {
        sorted.push_str(format!("{}\n", line.line).as_str());
    });

    return sorted;
}

#[derive(Eq)]
struct Line {
    line: String,
    num: u32,
}

impl Ord for Line {
    fn cmp(&self, other: &Self) -> Ordering {
        let ord = other.num.cmp(&self.num);
        if let Ordering::Equal = ord {
            other.line.cmp(&self.line)
        } else {
            ord
        }
    }
}

impl PartialOrd for Line {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

impl PartialEq for Line {
    fn eq(&self, other: &Self) -> bool {
        self.eq(other)
    }
}

Lineという、行の文章と第3カラム目の値をもった構造体を作成しました。そこにEq、Ord、PartialOrd、PartialEqを実装し、3カラム目での大小比較できるようにしました。この構造体をBTeeSetに格納していき、イテレーターで回すことで、ソートされた状態にしてあります。同一数値の場合は行の降順でソートできるようにOrdを実装してあります。

19. 各行の1コラム目の文字列の出現頻度を求め，出現頻度の高い順に並べる

pub fn sort_on_frequency(input_file_name: &str) -> String {
    let mut names: HashMap<String, u32> = HashMap::new();
    let buf = BufReader::new(File::open(input_file_name).expect("file not found"));
    buf.lines().for_each(|line| match line {
        Ok(line_str) => {
            let columns: Vec<_> = line_str.split('\t').collect();
            let name_str = columns[0].to_string();
            let count = names.entry(name_str).or_insert(0);
            *count += 1;
        }
        Err(_) => panic!("parse error"),
    });
    let mut sorted = String::new();
    let mut sorted_names: Vec<(&String, &u32)> = names.iter().collect();
    sorted_names.sort_by(|(aname, acount), (bname, bcount)| {
        let ord = bcount.cmp(acount);
        if let Ordering::Equal = ord {
            bname.cmp(aname)
        } else {
            ord
        }
    });
    sorted_names.iter().for_each(|(name, count)| {
        sorted.push_str(format!("{} {}\n", count, name).as_str());
    });
    return sorted;
}

もうすこしうまくできる気がしますが、いったんこれで。数え上げのためにまずはHashMapに第1カラムの文字列, 個数という組み合わせでデータを入れていきます。出来上がったHashMapをタプルのベクターに変換し、変換したベクターのsort_byメソッドに比較用の関数を渡すことで個数の降順に並べています。同一個数の場合は文字列の降順になっています。で、最後に並びかわったベクターのイテレーターを使って出力しておしまいです。内部的には最悪3回回る感じでしょうか? 最初からベクトルに入れつつソートできる仕組みにするようなのがいいのかなぁ?

まとめ

Unixコマンドの勉強になりましたw あとは、HashMapなどの勉強にもなりました。最後の方は効率がいまいち良くない気もしてはいますが、とりあえず第3章に進もうかと思います。

第2章の10から11まで(言語処理100本ノック2020)

Fri, 08 May 2020 23:37:20 +0900

気づいたら1ヶ月サボってました、ごめんなさい。。。

Rustで言語処理100本ノックの第2章をはじめました。

前回はこちら。

確認用のUnixコマンド

確認用のファイルを先に生成して置きました。これで、Rustでコードを書いて、作成済みの確認ファイルを元にassert_eq!でチェックするという方式を取ろうかと。

で、コマンド群はこちらです。

Unix/Linuxコマンド、昔から使っています。が、なにかちょっとした文字列処理やファイル処理をやるときは、Javaのプログラム(最近だとPython)を書くというのが基本になってるので、結構、使ったことの無いコマンドが今回ありました。使ったことがなかったのはこちらです。

sed
tr
expand
paste
cut
split

sedとかは普通さわってるだろ?って思われそうですね。。。

で、コマンドをmanで調べつつやりました、macOS上で。これがまたいくつか罠があったので書き残しておきます(自分が知らないだけかもしれないので、おかしいところがあったらツッコミお願いします。)。

`sed`コマンドでのタブの扱い

## sed command for macOS. If using Linux, use "\t" for tab character
cat $INPUT_FILE_NAME | sed -e 's/	/ /g' > $OUTPUT_DIR/11_sed.txt

\tで行けると思ったのですが、うまく動きませんでした。<tab>みたいな書き方もあると思うのですが、これも駄目で、結局タブ文字をそのまま打ち込みました。。。これ、めんどくさくないですか??? ちなみに、ターミナルで動作確認して、GitHubにあげてあるシェルファイルにコピペしてたのですが、CLionに貼り付けたらタブ文字がスペースに変換されてしまってて20分くらい悩みました。。。

`split`コマンドに`-n`オプションがない


LINES=`cat $OUTPUT_DIR/10.txt`
SPLIT_LINES=`echo $LINES/$N | bc`
split -a 1 -l $SPLIT_LINES $INPUT_FILE_NAME $OUTPUT_DIR/16_

splitコマンドについてググると、-nで指定した数のファイルに分割できるという記事がいくつも出てくるのですが、man splitをターミナル上でやるとそんなオプションがないと。。。 macOSがBSD系だからっぽいです。ということで、行数を元に、指定した数(N)で行数を割ってから、指定行数ごとにファイルを分割する方式にしました。

これらのコマンドの違いはHomebrewとかでインストールするとなくなるのかなぁ?(めんどくさいので確認してないですが。。。)

ってことで、2章のそれぞれの課題の正解ファイルの生成はこれでできたはずです。

10. 行数のカウント

wc -lですね。

// ch02-10 行数のカウント
pub fn word_count(file_name: &str) -> usize {
    let f = File::open(file_name).expect("file not found");
    let buf = BufReader::new(f);
    return buf.lines().count();
}

ファイルを読み込んで行数を数えます。文字列として読み込んで改行コードの数を数えるというのもありかな?と思いましたが、RustのBufReaderにlines()という行のイテレータ?が取れることがわかったので、それでカウントを取りました。

11. タブをスペースに置換

// ch02-11 タブをスペースに置換
pub fn tab_2_space(file_name: &str) -> String {
    let mut f = File::open(file_name).expect("file not found");
    let mut contents= String::new();
    f.read_to_string(&mut contents).expect("read error");
    return contents.replace("\t", " ");
}

こっちはファイル全体を文字列に読み込んでしまってから、文字列のreplaceで置換するという方式です。ファイルが大きい場合にこれでいいのか?という問題がある気がしますが、まずはこの実装にしました。やるとしたら、readメソッドとbufferを用意して、少しずつ読みながら、置換して吐き出す感じでしょうか? ちゃんとした文字コードの区切りで取れるかどうかを気にしないと行けないと思うので、思ったよりはめんどくさくなりそう。

BufReaderをつかってread_lineのほうがましかも?

まとめ

ということで、サボっていたのを再開しました。 Rustのコードを書く前に、Unixコマンドの処理に結構悩みましたw

Rustのコードとしてはファイル処理なので、今後も役立つ気がしてます。ということで、頑張っていくぞと。

第1章の08から09まで(言語処理100本ノック2020)

Fri, 08 May 2020 16:40:57 +0900

Rustで言語処理100本ノックのリファクタリングの続き。

前回はこちら。

とっくに終わってたのに、ブログ書いてなかった。。。

08. 暗号文

pub fn cipher(text: &str) -> String {
    return String::from_iter(text.chars().map(|x| {
        if x.is_ascii_alphanumeric() && x.is_lowercase() {
            let mut b = [0; 4];
            x.encode_utf8(&mut b);
            b[0] = 219 - b[0];
            char::from(b[0])
        } else {
            x
        }
    }));
}

Rustの文字列はUTF-8でエンコードされたテキストを保持しているので、文字コード自体は意識していないです。 chars()でUnicodeスカラー値のイテレータが返ってくるので、1文字ずつ扱えるようになります。

ただ、1文字をバイトとして扱うのに手こずりました。 encode_utf8というメソッドを利用して1バイトだけ取り出して、計算するというのをやっています。文字種の判別のメソッドが用意されているのは便利ですね。

なんかもうちょっとスマートにできないのかな?と思いつつ動いたのでこれになってます。

09. Typoglycemia

pub fn typoglycemia(text: &str) -> String {
    return text
        .split_whitespace()
        .map(|word| {
            if word.len() <= 4 {
                word.to_string()
            } else {
                let original = word.chars().collect::<Vec<char>>();
                let first = original.get(0).unwrap();
                let last = original.last().unwrap();
                let mut typo = original[1..original.len() - 1]
                    .iter()
                    .map(|x| x.clone())
                    .collect::<Vec<char>>();
                let mut rng = thread_rng();
                typo.shuffle(&mut rng);
                let mut typo = String::from_iter(typo.iter());
                typo.insert(0, first.clone());
                typo.push(last.clone());
                typo
            }
        })
        .collect::<Vec<String>>()
        .join(" ");
}

一応、1行で記述できたかな? まずは、スペースで単語ごとに区切った後に、word(単語)の長さによって、処理を分岐し、単語が5文字以上の場合にランダムに並び替えを行うというのをやっています。文字単位で処理を行うために、chars()で1文字ずつ取り出しています。最初と最後の文字だけはそのままに、間の文字をランダムにシャッフルするというのをやるのに、もとのwordのスライスからコピーした文字列を作り出してから組み立て直すということをやっています。

コピーしないでゴニョゴニョする方法ってあるのかなぁ? 思いつかなかったので、結構泥臭い感じの実装になってしまいました。

まとめ

めんどくさいので、コードをGitHubのソースコードからではなく、ブログにコードスニペットとしてコピペしました。Hugoでいい感じにGitHubのコードスニペット表示するのないかなぁ?

ということで、2年越しで1章が終了しました。 2章もやらないとなぁ。

ElasticのWorkplace Searchを触ってみる - その2 - インストールと起動

Thu, 07 May 2020 11:32:50 +0900

前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点での情報を元に本記事は書いていますのでご注意ください。基本的にはインストールと起動方法についての手順を元に書いています。所々に考察を挟んだ形の記事になっていますので、気になるところだけ呼んでいただければと。

記事一覧

ElasticのWorkplace Searchを触ってみる - その1

インストール

インストール方法は公式リファレンスもしくはダウンロードページに記載があります。現時点ではMacもしくはLinuxが対象でWindowsはまだサポート対象外となっています。

必要なもの

インストールに必要なものは以下になります。

Elasticsearch 7.6.x + Platinum license
- Elastic CloudのElasticsearch Service もしくは
- ダウンロードしてローカルで起動
enterprise-search-7.6.0.tar.gz
- ダウンロードページはこちら
Java 8もしくは11
- Long Term Supportの対象であるJavaです。2020/5/7時点では8か11

今回はローカルにElasticsearchの7.6.2をインストールしてから試してみます。30日間のトライアルライセンスが有効になっているので、Platinumの機能を試すことができます。

Javaの8か11が必要になります。Elasticsearchには7.xからJDKが同梱されるようになりましたが、Workplace SearchがJettyを元に動作しているからです(enterprise-search-7.6.0.tar.gzにjettyというフォルダあり)。

インストール手順

大まかには以下の3つです。

Java 8もしくは11のインストール
- 14でも大丈夫でした(ローカルにはSDKMANでインストールした14.0.1が利用された)。
Elasticsearchのインストール(Elastic Cloudの場合はクラスタの起動)
- 今回はローカルにインストール
Workplace Searchのインストール

Javaはもともとインストールされていたので、今回は2と3をインストールしました。どちらもローカルで起動するので、2つをダウンロードしてtar.gzファイルを展開するだけになります。

起動方法と設定

起動方法に起動前の設定の手順も記載があります。設定しながら起動していきます。

Elasticsearchの起動

既存のElasticsearchのクラスターがあり、Platinumのライセンスが有効になっている場合はこの手順は必要ありません。

Elasticsearchの設定ファイルでSecurity機能をオンに
- 7.1から基本的なセキュリティ機能はベーシックの機能に含まれています。
Elasticsearchを起動
- まずは起動(パスワードなどを設定するために必要)
Elasticsearchのパスワードの設定
- Elasticsearchでデフォルトで用意されているユーザーのパスワードを設定してします。手順では自動で生成させる方法ですが、独自に設定することも可能です。

Workplace Searchの起動

Elasticsearchが起動したらWorkplace Searchの設定をして起動します。

Esへの接続設定をconfig/enterprise-search.ymlに指定
- Esのパスワード設定時に生成されたelasticというユーザーのパスワードをここで指定。
- yamlファイルに記載があるが、${ELASTICSEARCH_PASSWORD:changeme}という記述をした場合に環境変数を読み込める
allow_es_settings_modification: trueをconfig/enterprise-search.yml
- ここに記載があるような変更をWorkplace SearchがEsのクラスターに対して実行する模様。Workplace Search以外でも使用しているElasticsearchクラスターの場合はallow_es_settings_modificationを有効にする代わりに、リンク先にあるような設定を自分で追加する。
secret_management.encryption_keysを複数設定
- Encryption Keysのガイドに少し詳しい説明がある。
- opensslコマンドとかで作ればいいかな??
- 1.と同じような設定をしようとしたがうまくいかなかったので、ファイルにキーを設定する方式にしました(バグ?)
起動するときにデフォルトユーザーパスワードを指定
- 指定しなければ勝手に生成してコンソールに出力してくれるので、そちらの方がいいかと。
- 今回は手順通りに指定した。
起動確認のためhttp://localhost:3002にアクセス

起動するとログが流れ、問題がなければ次のようにデフォルトユーザーの情報が出力されます。

#########################################################

*** Default user credentials have been setup. These are only printed once, so please ensure they are recorded. ***
      username: enterprise_search
      password: pas...ple

#########################################################

そして無事起動に成功したことも出力されます。

#########################################################

Success! Elastic Workplace Search is starting successfully.

In a few moments, you'll be able to login at the following address:

* URL: http://localhost:3002
  * If this is your first time starting Workplace Search, check the console output above for your user authentication credentials.
  * Visit the documentation: https://swiftype.com/documentation/enterprise-search

Secret session key has been generated.

Set the key in your config file to persist user sessions through process restarts:

secret_session_key: c23...3


#########################################################

ブラウザで画面にアクセスすると、次のような画面が表示されました。

起動時のエラー

いくつかのパターンも試してどんなエラーが出るのかを見てみました。おまけですね。

Elasticsearchが見つからないエラー

Esを起動しないでWorkplace Searchを起動してみました。

200秒間アクセスしようと試みて駄目だったらエラーで終了みたいです。


[2020-05-07T03:48:33.645+00:00][13709][2002][app-server][INFO]: Failed to connect to Elasticsearch backend. Make sure it is running.
...
[2020-05-07T03:51:54.038+00:00][13709][2002][app-server][INFO]: Could not connect to Elasticsearch backend after 200s. Terminating...
[2020-05-07T03:51:54.039+00:00][13709][2002][app-server][ERROR]: 
--------------------------------------------------------------------------------

Error: Workplace Search is unable to connect to Elasticsearch. Ensure a healthy Elasticsearch cluster is running at http://127.0.0.1:9200 for user elastic.

--------------------------------------------------------------------------------

ElasticsearchのSecurityがオフのときのエラー

ちなみにSecurityをオフにしたままWorkplace Searchを起動した場合は以下のようなエラーが出ました。

[2020-05-07T03:46:53.474+00:00][13567][2002][app-server][ERROR]: 
--------------------------------------------------------------------------------

Elastic Workplace Search requires Elasticsearch security features to be enabled.
Please enable Elasticsearch security features as outlined here:
  https://www.elastic.co/guide/en/workplace-search/current/workplace-search-install.html

--------------------------------------------------------------------------------

構成要素

ここまでインストールして起動してきました。では、Workplace Searchがどういったコンポーネントから構成されているかを予測してみましょう(あくまで外から見た予想となります。そのうちElastic社のウェビナーとかイベントで内部の発表とかあるかも?)。

インストールページの記載から

インストールページに最小ハードウェアという記載があり、そこで何が動く可能性があるかというのがわかります。

起動するものはこんな感じみたいです。

Elasticsearch - 外部でもOK
App Server - Workplace SearchのWeb機能
Worker - クローラーとかかな?
Filebeat - Workplace Searchのログ収集用
その他プロセス - なんだろ?

という具合です。

設定などからの予想

次は設定項目や起動時のログなどからの予想です。

Worklpace Search配下のセキュアなデータストア - アクセストークンなどの管理のため
JRubyアプリケーション - App ServerはJRuby上で動いているRailsアプリ
Filebeatも起動している - Workplace Searchのログ収集のため?
- Filebeatの接続設定はWorkplace Searchの設定値を利用

では構成要素は?

ということで、現時点でわかった構成要素は以下のとおりです。

Elasticsearch
Workplace Search App Server - Railsアプリ on JRuby
- Webアプリとは別に(内部?で)、いくつかのワーカーが存在する
- 管理画面と検索画面の2種類が存在
Filebeat - ログ収集

といった感じです。まだ起動したばかりなのでこのくらいでしょうか。ログを見るともう少しわかりそうな気がします。

基本的には、EsをバックエンドにしたRailsのミドルウェアになります。コネクターや検索画面はすべてWorkplace Searchのミドルウェア経由でアクセスする形になりますので、普通に検索で利用するユーザーにはElasticsearchの存在は見えない作りになっています。

次は?

Getting Startedを元に、どんなアクターがいて、どんな機能が提供されているのか、どんな利用方法なのか?というのを見ていこうと思います。

ElasticのWorkplace Searchを触ってみる - その1

Fri, 01 May 2020 16:29:04 +0900

2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に変更し、App Searchなどを含む製品群をEnterprise Searchという名前に変更しました(ちょっとややこしい)。 Workplace Search自体はまだβ版という位置づけですが、ダウンロードして試すことが可能です。

きちんと触ったことがないので、ちょっと触って見ようかなと思い、何回かに分けてブログを書いてみます。まずは概要とかから。

Workplace Searchとは?

Elasticsearchをバックエンドに利用するElastic社が提供するアプリケーション(ミドルウェア?)の1つです。

もともとはSwiftypeという会社が作っていた、Site Search、App Searchと同じような系列で開発されている統合検索の検索エンジンミドルウェアという感じです。製品ページを見るとわかりますが、様々なデータソースから、データをクロールしてElasticsearchに保存することで、統合された検索を提供することができるようになる製品です。最近は会社のドキュメントがさまざまな場所(Google Drive、Saleseforce、GitHub、Dropboxなど)に保存されています。それぞれで検索窓などはありますが、1箇所で検索することで横断的に検索でき、仕事の効率があがりますよね?ということで作られている製品です。

提供(利用)方法は?

今後の提供方法としては、Elastic Cloudで利用できるSaaS形式のものと、独自に(クラウドのコンピューティングエンジンやオンプレのサーバーなどで)Workplace Searchのアプリを起動する方法(オンプレ版)があります。後者の場合は、Elasticsearchのクラスターを用意する必要があります。なお、後者の場合、Elasticsearchのサブスクリプションのプラチナライセンスが必要になるようです(ダウンロードページに記載あり)

まだ、β版という位置づけなので、今後どのように変更されるかはわかりませんが、今回は2020年5月1日時点でのベータ版(7.6.0)を元にどんなものかを紹介します。現時点で利用できるのはβ版のオンプレ版で、MacやLinuxで利用可能です。

ダウンロードとインストール

ダウンロードページにインストール方法などの記載があります。

インストールして触って見るところはまた後日。

ライセンス、価格は?

まだ不明です。SaaS版の提供はまだです。オンプレ版については少なくとも、Elasticのサブスクリプションのプラチナが必要になります。こちらは、価格は公開されていません。Elastich社もしくはパートナー企業での問い合わせが必要になります。 (たぶん、ドキュメントレベルのセキュリティとかSSOとかの仕組みがプラチナで提供されているのでそのあたりを使っているのでは?と想像してます。)

想定できそうな用途は?

社内の文書検索でしょうか。ただ、いわゆる昔ながらのエンタープライズサーチと呼ばれている、社内のファイルサーバーなどの文書検索ではなく、クラウドサービスを複数利用している会社が利用する想定になっています。

例えば、開発者は社内Wiki(Confluence)で社内文書を書き、Issue管理にはJIRAやGitHubを活用しており、ただ、社内での説明にはGoogle Driveを利用しているといった場合です。こういう場合、あの機能についての説明や資料ってどこだっけ?というので、あちこち探し回ったりしないといけないです。また、営業部門やサポート、マーケティングなどが絡んでくると更に、SalesforceやZendeskといったデータソースも出てきます。情報が散らばっていて、それらを探し出したりまとめるだけで時間を取られている場合などに便利かもしれません。

次は?

実際にインストールしてから起動して、どんな感じで使えるのかといったところを見て、どんな機能が提供されているのかを見ていこうと思います。

辞書の更新についての注意点

Mon, 27 Apr 2020 10:44:15 +0900

先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。

辞書の設定方法について記載しましたが、今回は辞書の更新について書いていなかったので、書いてみようと思います。ここで「辞書」としているのは、Kuromojiのユーザー辞書、Synonym Graph Token FilterのSynonym辞書(いわゆる類義語辞書)のことになります。サードパーティのAnalyzer等に関する話ではありません。

辞書更新に関する制限事項

辞書の更新について、大原則と制限事項が存在します。

大原則(辞書の更新=データも更新)

ElasticsearchはAnalyzerが切り出した単語を元に転置インデックスを作成して、検索を行っています(この仕組みに関するスライドはこちらを参照のこと)。 Analyzerが辞書を持っている場合、その辞書を元に単語を切り出して転置インデックスに利用します。また、検索クエリの単語に対してもこのAnalyzerの辞書が利用されます。

辞書に新しい単語を追加するということは、その単語に関連するドキュメントも更新しないと行けないということになります。

例えば、Kuromojiを利用していて、「グランベリーパーク」という単語「グランベリー」「パーク」という単語に分割できるような新しい単語として辞書に追加する場合を考えてみましょう。ユーザーが「グランベリー」で検索しても検索結果として出てきてほしいという場合です。

辞書に「グランベリーパーク」を登録していない頃に登録されたドキュメントは「グランベリーパーク」という1単語として転置インデックスの見出し語を切り出します(Kuromojiはカタカナの連続している文字列については未知語として1単語にし、「名詞-一般」の品詞を付与)。

更新前でのドキュメントのAnalyze結果

「グランベリーパーク」「で」「ショッピング」

もし、辞書に「グランベリーパーク」を「グランベリー」「パーク」から構成される新規の単語として登録しそれを使用した場合、辞書を更新したあとから、「グランベリーパーク」という単語がAnalyzerからは出てこなくなります。

更新後でのドキュメントのAnalyze結果

「グランベリー」「パーク」「で」「ショッピング」

ということは、辞書更新以前のドキュメントは「グランベリーパーク」という見出し語に対して登録されているので、辞書更新以前に登録されているドキュメントは検索にヒットしなくなります。

このように転置インデックスを利用している検索エンジンでは、単語の区切りが変更されるような辞書の更新があった場合、最低でも影響があるドキュメントについては再登録が必要となるわけです。

これが大原則(辞書更新=データも更新)となります。基本的には辞書の更新を行った場合は、ドキュメントの再インデックス(再登録)が必要となります。

Elasticsearchでの制限事項

Elasticsearchでは、辞書の更新に関して実装上の制限事項が存在しています。内部的な実装として、ElasticsearchではAnalyzerのインスタンス(正確にはAnalyzerのFactoryのインスタンス)の生成がインデックスに関する内部のインスタンスが生成されたタイミングの1回のみとなっています。

このインスタンスの生成時に設定ファイル(辞書を含む)を読み込んでいます。

言い換えると、辞書(ファイル、インデックス設定に関わらず)の読み込みは、インデックスが作られたタイミングのみということになります。なおここで言う「インデックスが作られたタイミング」というのは、以下の2パターンです。

インデックス新規作成時
インデックスオープン時

では、ここから辞書を更新してそれを既存のインデックスに適用する方法について説明しましょう。

辞書の更新方法(ファイル編)

前回のブログで説明しましたが、Elasticsearch 7.4よりも古いバージョンでは、ファイルでKuromojiのユーザー辞書を設定していました。まずはこちらの方法について説明します。前提として、すでにユーザー辞書を設定したKuromoji Tokenizerがインデックスに設定されているものとします(ユーザー辞書の設定方法については公式リファレンスを御覧ください)。

辞書ファイルに新規にエントリーを追加しただけでは、設定は読み込まれていません。新規辞書を反映させるためには以下の手順が必要となります。

更新した辞書ファイルの配布
- 複数ノードでElasticsearchのクラスターを構成している場合はすべてのノードに更新した辞書ファイルを配布する必要があります。
インデックスのクローズ(公式リファレンス)
- 設定ファイルを再読込させるために一度インデックスをクローズします。
- クローズするので、書き込み、検索などの処理を停止する必要があります。もし停止していない場合はクライアント側ではインデックスがクローズされているという旨のエラーを受け取ります(400で、index_closed_exception)。
インデックスのオープン(公式リファレンス)
- 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。
再インデックス
- _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。
- _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。

Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。

辞書の更新方法(インデックス設定編)

ファイルの場合とは少し手順が異なります。インデックスの設定としてユーザー辞書を登録しているため、ファイルをElasticsearchのクラスターにあるノードに配布する必要がありません。また、辞書の設定はインデックスの設定に指定してありますが、こちらは動的に設定変更できる項目ではないため、インデックスを先にクローズする必要があります。

インデックスのクローズ(公式リファレンス)
- 辞書の設定を更新するにはインデックスをクローズする必要があります。辞書の設定は動的に更新できる項目にはなっていないためです。
- オープンしているインデックスで更新しようとした場合はillegal_argument_exceptionでCan't update non dynamic settings...というメッセージが返ってきます。
辞書の更新(公式リファレンス:インデックス設定の更新)
- user_dictionary_rulesに単語と追加します。
インデックスのオープン(公式リファレンス)
- 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。
再インデックス
- _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。
- _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。

Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。

第3の方法(新規インデックス作成)

ここまで、インデックスのクローズ、オープンで既存のインデックスに対して辞書を更新する方法について説明しました。ただ、残念なことにAmazon Elasticsearch ServiceではElasticsearchが提供しているすべてのAPIが利用できるわけではありません(Amazon ESの利用可能なAPIの一覧はこちら)。 (_closeは駄目だけど_openは呼べるのかな???)

ということで、新規にインデックスを作成して、新しい辞書の設定を反映したインデックスを用意し、そこにデータをコピーもしくは登録するという方法になります(Amazon ESのカスタム辞書のドキュメントに手順がありますね)。

手順としては以下のとおりです。

辞書の更新(用意)
- 新しい単語などを登録した辞書を用意します。
- ファイル、インデックス設定どちらでもOKです。
- ファイルの場合は、既存のファイル名とは異なるファイル名にしたほうが混乱がなくなります。
新規インデックス作成
- 1.で作成した辞書を元に新規インデックスを作成します。
新規インデックスにデータコピー
- _reindex APIを利用するとデータコピーが簡単です。sourceとdestを指定するだけです。
- _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。
アプリケーション側で新規インデックスを利用するように変更
- _aliasを使用しておくと切り替えが簡単です(公式リファレンスはこのあたり)。

考慮すべき点としては、サービスを提供しながら行う場合は、3.の_reindexを実行し始めたタイミング以降の登録・更新データの扱いについてでしょうか。

まとめ

辞書の更新に関する大原則、制限事項、手順などについて説明しました。辞書の変更は検索に大きく影響がでます。そのあたりをきちんと考慮しながら更新しましょう。ユーザー辞書、カスタム辞書を扱う際の参考にしていただければと。他にもユーザー辞書で気をつけないといけないこともありますが、今日はこのあたりで。

Kuromojiのカスタム辞書をインデックスの設定で指定

Wed, 22 Apr 2020 10:30:56 +0900

Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Serviceでカスタム辞書ファイルを読み込める機能が発表されたようです。

実は、Elasticsearchの7.4からファイルを使用しなくても日本語のTokenizerでカスタム辞書を利用することができるようになっています。

カスタム辞書をインデックスの設定で指定

やり方はドキュメントに記載があります。

トークナイザーの設定をインデックスの設定に記述しますが、このときに user_dictionary_rulesという設定を利用することでカスタム辞書を指定できます。

PUT custom_dic_sample
{
  "settings": {
    "index": {
      "analysis": {
        "tokenizer": {
          "kuromoji_user_dict": {
            "type": "kuromoji_tokenizer",
            "mode": "extended",
            "user_dictionary_rules": [
              "グランベリーパーク,グランベリー パーク,グランベリー パーク,カスタム名詞",
              "高輪ゲートウェイ,高輪 ゲートウェイ,タカナワ ゲートウェイ,カスタム名詞"]
          }
        },
        "analyzer": {
          "my_analyzer": {
            "type": "custom",
            "tokenizer": "kuromoji_user_dict"
          }
        }
      }
    }
  }
}

辞書の内部は"単語,出てきてほしい単語列(スペース区切り),読みの単語列(スペース区切り),品詞名"になります。配列で設定可能で、複数の単語を登録したい場合は、カンマ区切りで登録していきます(上記例では2つの単語を登録しています)。

_analyzeを利用して設定の確認

実際に上記の設定がうまく動作するかは_analyzeのエンドポイントを利用します。

GET custom_dic_sample/_analyze
{
  "text": "グランベリーパークがオープンしました。",
  "analyzer": "my_analyzer"
}

出力は以下のようになります。

{
  "tokens" : [
    {
      "token" : "グランベリー",
      "start_offset" : 0,
      "end_offset" : 6,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "パーク",
      "start_offset" : 6,
      "end_offset" : 9,
      "type" : "word",
      "position" : 1
    },
    {
      "token" : "が",
      "start_offset" : 9,
      "end_offset" : 10,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "オープン",
      "start_offset" : 10,
      "end_offset" : 14,
      "type" : "word",
      "position" : 3
    },
    ...(省略)
  ]
}

ちなみに、デフォルトのkuromojiを利用した場合は、グランベリーパークが1単語として出力されます。

GET _analyze
{
  "text": "グランベリーパークがオープンしました。",
  "analyzer": "kuromoji"
}

## レスポンス
{
  "tokens" : [
    {
      "token" : "グランベリーパーク",
      "start_offset" : 0,
      "end_offset" : 9,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "オープン",
      "start_offset" : 10,
      "end_offset" : 14,
      "type" : "word",
      "position" : 2
    }
  ]
}

これで、カスタム辞書を使用することでグランベリーで検索された場合に、グランベリーパークもヒットするという仕組みです。

_analyzeはexplainというパラメータも持っており、こちらを利用することで、単語の品詞情報なども取得できます。これを使うことで、実際に設定がきちんと動作しているかの確認に利用できます。

GET custom_dic_sample/_analyze
{
  "text": "グランベリーパークがオープンしました。",
  "analyzer": "my_analyzer",
  "explain": true
}
## レスポンス(一部のみ)
{
  "detail" : {
    "custom_analyzer" : true,
    "charfilters" : [ ],
    "tokenizer" : {
      "name" : "kuromoji_user_dict",
      "tokens" : [
        {
          "token" : "グランベリー",
          "start_offset" : 0,
          "end_offset" : 6,
          "type" : "word",
          "position" : 0,
          "baseForm" : null,
          "bytes" : "[e3 82 b0 e3 83 a9 e3 83 b3 e3 83 99 e3 83 aa e3 83 bc]",
          "inflectionForm" : null,
          "inflectionForm (en)" : null,
          "inflectionType" : null,
          "inflectionType (en)" : null,
          "partOfSpeech" : "カスタム名詞",
          "partOfSpeech (en)" : null,
          "positionLength" : 1,
          "pronunciation" : null,
          "pronunciation (en)" : null,
          "reading" : "グランベリー",
          "reading (en)" : "guramberi",
          "termFrequency" : 1
        },
        {

partOfSpeechにカスタム辞書で設定したカスタム名詞が出力されていますね。 _analyzeのAPIはこのように、アナライザーの挙動の確認に非常に便利なので是非活用してみてください。

KibanaでこのAPIを使うためのプラグインも開発していますので、こちらも合わせて利用してみてください。

注意点

ちなみに、user_dictionaryとuser_dictionary_rulesを両方指定した場合はエラーとなります。ファイルをベースにしつつ、追加の設定をするという使い方はできないので、注意しましょう。

インデックスの設定で書くことにより、バックアップ・リストアは楽になるかな。ただ、クラスターステートに取り込まれるから、あまりにも巨大なカスタム辞書だと心配かなぁ。ファイルの場合はクラスターステートには取り込まれないので、そこは圧迫しない。
— Jun Ohtani (@johtani) April 22, 2020

それ以外の注意点については、別途ブログを書きました。「辞書の更新についての注意点」、こちらも合わせてご覧ください。

まとめ

カスタム辞書をファイルではなくインデックスの設定値として設定する方法を紹介しました。こちらは、Elasticsearch 7.4で導入された機能になります。7.4以降を利用している場合はこちらを利用することも検討してはいかがでしょうか? また、_analyze APIも便利なので合わせて活用してみてください。

Rust the book - 第8章

Thu, 16 Apr 2020 18:17:30 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

第8章

7章はパッケージなので後回しにして、8章に入ります。 8章はコレクションです。

ベクタ型

ベクタは同じ型の値だけ保持可能。
- ジェネリクスで型を指定可能 - Vec<i32>とか。
vec!マクロで初期値とか設定すると便利。
ベクタに値を追加するのはpush。もちろん値が変わるので元のベクタにはmutが必要
ベクタのスコープ(ライフサイクル)は要素に対する参照があるのとないので話が変わってくる
- メモリの確保などの影響で、ベクタ全体に対して借用の規則が矯正されると。
ベクタの値を読むのはいくつか方法あり
- getメソッドはOptionを返す
- &v[2]の添字記法の場合はパニックの可能性あり
走査(唐突に参照外しが出てきた)
- 単純に値を取り出す場合はfor - in &v
Enumをベクタにいれることで、異なる型も保持可能(まぁ、Enumの型では固定されるけど)。
- これだけのためにEnumを使うことってあるのかな?
- トレイとオブジェクトに関する文章はちょっとわかりにくい。。。

説明以外のメソッドなどについてはAPIドキュメント見ましょうと(リンクも張ってくれてると嬉しいなぁと思ったり。まぁ、バージョンとかの絡みがあるから難しいか)。

文字列型

文字列はUTF-8でエンコードされた文字を扱うための型。
strは文字列データへの参照。
String型は言語のコアではなく、標準ライブラリに入っている文字列型。
- 他にもあるのか。。。OsStringとか。。。
文字リテラルはDisplayトレイトを実装していると。
.to_string() = String::from
Stringはコレクションだから追加とかが可能なのか、なるほど。
push_strとpush
+演算子での参照。
- &Stringは&strに型強制(キャスト?)してくれる。してくれる場合としてくれない場合もあるのかな?s2の所有権は奪わない形で扱うのでs2はこのあとも使えていると。
- ここでは、s1を変更したあとに所有権がs3に持っていかれてる?
- format!を使うとどの所有権も奪わないので、これを使うほうが考え方は簡単そう。ただし、効率がいいかはわからん。
添字記法でのアクセスをStringは許容していない
- 文字の境界が必ずしも1バイトとは限らないから。
- スライスも同様。
基本的には.chars()で文字としてアクセスするのが良い。
逆にバイト表現を得る方法はどうするんだろう?
- NLP100本ノックではencode_utf8メソッド使ったけど。

ハッシュマップ

いろんな呼び方あるよね。Rustではハッシュマップだよ。
ハッシュマップはuseしないと使えない
キーは1つの型、値も1つの型
タプルのベクタからcollectで生成。なるほど。
- タプルのベクタだと、タプルの中身は同じものであることが言える?
  - -> 言える。エレメント数が異なるとコンパイルエラーになった
所有権周りの話。
- これ、ベクタのときに話してほしい感じがした。
- 値を渡すか参照を渡すかによって話が変わってくる。詳しくは10章
- このあたりが自分が混乱していた元だ。
entryとinsertの違い
- entryの戻り値はEntryというenumでor_insertというメソッドがありそれを使うと存在しない場合だけinsertが呼ばれる。
  - これ便利だ。毎回existあたりで存在チェックしてた気がする。
or_insertは可変参照&mut Vを返す。
- これをlet countで束縛するときに、中身が可変かどうかをcountには指定しないのか。。。

まとめ

一応、大学などで習ってた(はず)ですが、スタックとヒープを意識して考えないといけないなぁというのを何度か意識させられた感じです。

あと、これはRustに限らずですが、それぞれがどんな関数を持っているか、どんなメソッドを持っているか、どんなマクロが存在するかなどを探すときにみんなどうしてるんだろう? 人に教えてもらっているのか、APIリファレンスを探すのか、そういったところをみんながどういう感じにプログラミング言語を勉強しているか、業務で書いているのかと言うのが気になりました。

第1章の03から06まで(言語処理100本ノック2020)

Thu, 09 Apr 2020 18:14:55 +0900

Rustで言語処理100本ノックのリファクタリングの続き。

前回はこちら。

コードも載せたほうが見やすいかなぁ?

03. 円周率

2年前はこちら。どちらかというとJavaっぽい書き方かな? 入れ物を用意して、入力を整形して、それからループを回す感じで書いてました。

今回は1行で収めてみました。 Rustっぽく、returnを省略してみました。あとは、Iteratorを組み合わせる感じでやってます。アルファベットの文字数ということで、is_alphabetic()メソッドでfilterしてます。

04. 元素記号

2年前はこちら。エラー処理が多いのと、文字の扱いがちょっと

ここまで同様に極力イテレータを利用するという方針でリファクタリングしました。あとは、エラー処理を除去してます。正常系だけのテストなのでスッキリさせました。

こういった、ストリーム系?の書き方の場合にエラー処理をどう入れるかってところはちょっと悩みどころになるんじゃないかなぁ?と思いつつ、イレギュラーなものは後回しで(あとにやるのかなぁ?)

05. n-gram

2年前はこちら。これまでと同じく、入れ物を作ってから処理をしてます。

同じく、極力イテレータを利用する形で実装しました。いくつか型の変換が必要なので、.map()を呼び出して詰め替えたりしています。

06. 集合

2年前はこちら。独自に実装しています。

せっかく05で文字n-gramの配列を返す処理を実装しているので、そちらを呼び出して、Setに入れるという処理に書き換えました。その後の集合に対する処理については特にリファクタリングしてないです。

まとめ

2年前にやってたところまでは追いつきました。 07は特にリファクタリングする必要がないので、次は08からの予定です。

リファクタリングしているときになるのは、速度とかでしょうか。実装の違いでなにか差が出るのかどうかはちょっと気になるところですが、今回の目的ではないので、目をつぶって進める予定です。

言語処理100本ノック、再び

Wed, 08 Apr 2020 18:33:45 +0900

今回もツイートから。

言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関する問題を追加しました。留学生も一緒に取り組めるように多言語化を進め、その第１弾として英訳を部分公開しています（40番以降は順次公開予定）。 https://t.co/52h362PIQQ
— Naoaki Okazaki (@chokkanorg) April 6, 2020

言語処理100本ノックが2020年版になったそうです。そうです、2年前に初めて、準備運動で止まっていたんです!(衝撃的な続かなさ。。。)

ということで、Rust the bookも読んでいることだし、過去のプログラムをチェックしつつ再開しようかなと。ということで、いくつかリファクタリングしてみました。

ソースはリポジトリを御覧ください。

00. 文字列の逆順

2年前の実装では、chars()メソッドで取り出したあとに、collect()でVecにしていたのですが、RustのIteratorトレイトにrev()という便利なメソッドが存在していました。

ということで、これを取り出すと、最初の文字列の逆順で文字を取り出すIteratorが取得できます。あとは、Stringが実装してくれているfrom_iterに渡せば文字列が出来上がります。

01. 「パタトクカシーー」

ストリーム処理っぽい書き方に変更しました。 2年前はIteratorを取り出して、詰替していましたが、 enumerate()で添字と文字のタプルのイテレータに変換し、 filterで添字が偶数のときだけフィルタリングして、 mapで対象の文字をまとめたイテレータにします。で、最後はそれを元に文字列を生成することにしました。 iterを使わないでそのままString::from_iterの引数に渡すことも可能ですね。

02. 「パトカー」＋「タクシー」＝「パタトクカシーー」

2年前は2つのIteratorをloopで回して頑張って結合してました。ではなく、zip()を使って、2つのイテレータを組み合わせる方法に替えてみました。このとき、2つの文字列が違う文字数の場合の処理として、長い方から取り出した文字をあとに結合する処理を追加で記述しました。ちょっとスマートな感じになりましたかね?

zipしたあとに出てきたタプルの文字列を結合するのにformat!マクロを使いましたが、他にいい方法有るかなぁ?

まとめ

とりあえず最初の3つをリファクタリングしてみました。残りもやりつつ、準備運動以降もがんばるぞと。

Rust the book - 第6章

Tue, 07 Apr 2020 19:27:11 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

第6章

Enumです。match式に大活躍

Enumを定義する

列挙型は取りうる値をすべて列挙できる。これが名前の由来
列挙型と列挙子
- 2連コロン(::)で列挙子を指定可能
列挙子にデータ(構造体も)が格納可能。
- 標準ライブラリに実装例あり。
疑問:Write(String)とかはタプルの表現になるのかな?
- と思ったが、タプルでは1つだけの変数を持つものは定義(正確には定義できるが、内部で普通の変数にもどされてるっぽい)できなかった。
メソッド定義も可能
- 関連関数もできる? -> できる

Optionの紹介

Rustにnullはない。代わりにOptionがある
Noneを指定する場合に型が必要。Someの場合はすでに値が入るから推測可能なため。

match制御フロー演算子

アーム -> matchしたときの処理のこと
- 短い場合は波括弧は不要
returnなしでmatchが書いてあるだけだと、慣れない場合に値を返していることに気づかないかも(実際気づけてないかも)
Enumが値を持っているときに、値の束縛がmatch式で可能
すべての列挙子を網羅していないことをコンパイラが検知してくれるのはすごく助かる。
- ただし、_を利用していなければだけど

if letで簡潔な制御フロー

enumで1つのパターンのときに処理をしたい場合に使えるmatchの糖衣構文
elseもかけるよ。

まとめ

enumに慣れていないので、値や構造体を持つenumを利用するという想像ができないことがありそうだなぁと読みながら思いました。それになれると、色々とプログラムがシンプルに書ける部分が多くなりそうかな。

KuromojiのCLIコマンドにJSON出力とラティス出力を追加

Mon, 06 Apr 2020 12:26:40 +0900

Kuromoji-CLIの使い方などについては過去のブログを御覧ください。

Issueだけ上げていたJSON出力対応をしました。また、ラティス(後述)の出力対応もしました。

JSON出力

LinderaがJSON出力に対応してるのでそれを真似しました。 -o jsonで指定していただくと、次のようなJSONが出力されます。

% echo "春眠暁を覚えず" | build/graal/kuromoji -o json

[
  {
    "text": "春眠",
    "detail": [
      "名詞",
      "一般",
      "*",
      "*",
      "*",
      "*",
      "春眠",
      "シュンミン",
      "シュンミン"
    ]
  },
  {
    "text": "暁",
    "detail": [
      "名詞",
      "一般",
      "*",
      "*",
      "*",
      "*",
      "暁",
      "アカツキ",
      "アカツキ"
    ]
  },
  {
    "text": "を",
    "detail": [
      "助詞",
      "格助詞",
      "一般",
      "*",
      "*",
      "*",
      "を",
      "ヲ",
      "ヲ"
    ]
  },
  {
    "text": "覚え",
    "detail": [
      "動詞",
      "自立",
      "*",
      "*",
      "一段",
      "未然形",
      "覚える",
      "オボエ",
      "オボエ"
    ]
  },
  {
    "text": "ず",
    "detail": [
      "助動詞",
      "*",
      "*",
      "*",
      "特殊・ヌ",
      "連用ニ接続",
      "ぬ",
      "ズ",
      "ズ"
    ]
  }
]

Viterbiラティス出力

Kuromojiが内部でトークンをどのように切り出すかを計算するためのViterbiのラティスです。これをGraphvizというツールのDOTフォーマットのファイルとして出力できるメソッドがデバッグ用ですが、Kuromojiに用意されています。こちらを呼び出して出力するオプション-v(もしくは--viterbi)を追加しました。 注意点として、このオプションを指定すると、DOTファイルが標準出力に出力され、トークンの結果は標準エラーに出力されます。

echo "春眠暁を覚えず" | build/graal/kuromoji -v > viterbi.dot

.dotファイル自体は画像ではないので、Graphvizのdotコマンドにて画像ファイルに変換する必要があります。

dot -Tpng viterbi.dot -oviterbi.png

これで、PNGファイルが出来上がります。出来上がったファイルはこんな感じです。

画像を見ていただくと、緑色のパスがあるのがわかります。こちらが、Kuromojiが実際に採用した形態素のリストです。それ以外のパスは不採用だったパスとなります。

ちなみに、macOSで1行で画像表示まで行うにはこんな感じで実行します。 openコマンドでpreviewアプリを指定することで画像が表示できます。 Windowsは。。。わかりません、すみません。

% echo "春眠暁を覚えず" | build/graal/kuromoji -v -o json | dot -Tpng | open -f -a preview.app

まとめ

これ以前に複数辞書対応などもしていました。今回は2つの出力形式を追加してみました。特にViterbiラティス出力については、内部的にどのようなコスト計算で最終的な結果が出てきているかという理解に役立ちます。想定していない切れ方の場合は、そもそも想定している形態素になっていないか、コスト計算で不採用だったかなどを確認できますので、使ってみると面白いかもです。

Rust the book - 第5章

Thu, 02 Apr 2020 15:09:18 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

第5章

構造体です。勝手知ったるなんとやら?オブジェクト指向的な部分は問題ないかなぁと。

定義とインスタンス化

structで定義
インスタンスの生成は引数は順不同でOK
構造体のインスタンスを可変にするとフィールドの値も変更可能
- 特定のフィールドのみ可変にすることは不可能
インスタンス化する関数の最後でreturnなしでインスタンスの返却を暗黙にできる(return書いてほしいな。。。)
インスタンス化時にフィールド初期化省略記法が可能(これはちょっと便利?)
構造体更新記法..user1のように、明示的に設定されていない他のフィールドをコピーしてくれる機能あり

タプル構造体

タプル構造体!? struct Color(i32, i32, i32);
- いつ使うんだろう?

ユニット様構造体

ユニット様構造体 = フィールドのない構造体。トレイトを実装したいけどインスタンスで持つ値はない場合に利用

ライフタイム

構造体が参照を持つときにライフタイムという話が出てくる。なるほど。
- ライフタイム指定子が必要になる -> 10章での話

プログラム例

タプルを引数かぁ。タプルは慣れないので構造体作りそう
Debugトレイトと{:?}という書き方
- derive(Debug)でデバッグ用のトレイトを自動で実装=継承してくれる
- {:#?}だとpretty printになる(改行とか入る)

この辺の便利なトレイとは付録Cにあるらしい。この辺はやりながら覚えるしかないか。

メソッド記法

最初の引数は必ずself
implは構造体とは別の場所に書く = Javaのクラスとは違う

struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

参照じゃないselfも使えるらしい。どういうときに使うんだろう?

その他

implブロックがあちこちにかける。これはつらいな。。。
2つにわかれたimplブロックに同じメソッドを書いてみたら、CLionのプラグインではエラーを検知してもらえなかった。
- cargo buildではきちんとエラーが表示された。
複数のimplブロックが有用になるケースは第10章で見ますが、そこではジェネリック型と、トレイトについて議論します。
- 人の構造体に自分のトレイトを適用したりもできる。

実験

スコープとかどうなりそう?って実験もしてみた。

fn main() {
    trait Hoge {
        fn trim(&self);
    }

    impl Hoge for String {
        fn trim(&self) {
            println!("hogehoge {}", &self);
        }
    }
    let c = String::from("hoge");
    c.trim();
    println!("{}", fuga(&c));
}

fn fuga(d: &String) -> &str {
    d.trim()
}

出力はこんな感じ

hogehoge hoge
hoge

まとめ

気になったのは以下の点。そのうち分かるようになってくるのかな。

構造体更新記法はどういったときに使うのを想定して作ったんだろう?とか
可変長引数はマクロじゃないとだめ

自宅の作業環境(2020)

Thu, 26 Mar 2020 19:11:51 +0900

すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。

私自身は昨今の新型コロナウイルスの影響というのではなく、もう10年以上自宅でも作業ができる環境を整えています。前前職の頃から家でも仕事をすることがよくあったので。今は、お客さんに恵まれていてリモートができる形で働かせていただいてます。

机周りはこんな感じです。机はこれも15年以上前から使用しているエレクターの机です。椅子も15年以上前から使っているアーロンチェア(購入時は高いと思ったけど、これだけ使えているので大満足)です。

メインのPCはMac Book Pro16インチを使っています。それとは別にMac miniがMac bookの後ろに隠れています。こっちはブラウジングや音楽を聞いたりするために使っています。

まずはディスプレイ周りから。

ディスプレイ周り

ディスプレイ

Acerの31インチディスプレイです。昨年の夏に購入しました。28インチの4Kディスプレイを探していたのですが、セールか何かで2-3000円の違いでこのサイズが買えたので、このサイズになっちゃいました。Mac Book ProはDisplay port-USB-Cケーブルで接続し、PS4をHDMIで接続しています。

【Amazon.co.jp 限定】Acer モニターディスプレイ ET322QKwmiipx 31.5インチ

マイクの左側に写っているのはAppleのサンダーボルトディスプレイです。縦にしてブラウザやミュージックプレイヤーなどで音楽かけながら仕事をしています。サブディスプレイって感じです。 Mac Book ProとMac miniの両方を操作するのですが、できれば同じキーボード+トラックパッドがいいなということで、Synergyというソフトを使って、Mac Book Proのキーボードとマウスでネットワーク越しにMac miniを操作しています。ただ、マシンの再起動後などにこのソフトが起動していない場合もあるので、Mac Book Proの右側にMac miniのためのトラックパッドがおいてあります。

ディスプレイアーム

ディスプレイはそれぞれディスプレイアームを使っています。写真のようにMac Book Proを下に、外部ディスプレイを上にという上下で作業をしています。 16インチの画面だと普通のディスプレイの足だとメインディスプレイにかぶってしまうので、アームに切り替えました。最初はグリーンハウスの激安を使っていたのですが、31インチのディスプレイだとアームの高さが足りなかったので、2つ目のガススプリング式のアームを追加で購入しました。ガススプリング式なのに5千円しないので、かなりお得感があります。ただ、ディスプレイは基本的に動かさないので、どちらかというとディスプレイの足の部分を効率良く使うことが目的です。

Amazon | グリーンハウス液晶ディスプレイアーム 4軸クランプ式

Amazon | HUANUO PC モニターアーム液晶ディスプレイアームガススプリング式

サウンド関連

スピーカー

基本、音楽を聞きながら作業をするので、小型だけどしっかりと音がでるスピーカーを買いました。スタイルもいいし気に入ってます。入力が2系統あるので、31インチディスプレイのヘッドフォン出力とMac miniのからの出力の2つをつないでいます。仕事中はMac miniで音楽流しつつ、テレカンやゲームのときはメインディスプレイからの音が出る形です。

Amazon | ヤマハパワードスピーカー NX-50

マイク

前職がDeveloper Advocateということで、インタビューなどに行くこともあるかも?ということで小さめのも運びができるコンデンサマイクを購入してました。結局それほど持ち運びはしてないのですが、値段の割には音がいいんじゃないかな?一応、無指向と単一指向の2種類を切り替えることが可能です。

Amazon | SAMSON マイクポータブル USB コンデンサ Go Mic | コンデンサ | 楽器

マイクスタンド

マイクはあったのですが、クリップ式でした。PCのディスプレイにクリップしていると、打鍵音を拾ってしまうので、マイクスタンドを最近導入しました。やすかったです。前まではヘッドフォンのケーブルに付いているマイクで喋っていたのですが、服によってはマイクに擦れてしまい、ノイズが載っていました。マイクスタンド+スピーカーでもスピーカーの音をマイクが拾わないので、最近はヘッドフォンを使用しないで気楽に話ができるようになっています。

Amazon | Luling Arts マイクスタンドアーム

その他

モニタスタンド

Mac Book Proの後ろで見えにくいですが、Mac miniが下に入っていて、上にMac mini用のキーボード、スピーカー、Qiの充電パッドが載せてあります。 Mac miniのキーボードをじゃまにならないように置きたいという目的で購入しました。3次元で空間が利用できるので結構重宝してます。

Amazon | サンワサプライ机上液晶モニタスタンド(D200・黒) MR-LC303BK

充電関連

スマホ充電用にスピーカーの横においてあります。ただ、スイートスポットを探すのがちょっと大変で、時々充電できてないことがあったりします。。。

Amazon | DesertWest Qi 急速充電ワイヤレス充電器【Qi認証済み/PSEマーク付き】15W

USBでの様々な充電用にはMercariさんのカンファレンスでいただいたAnkerの充電器をおいてあります。Mi Band 4、キーボードなどの充電向けです。

Amazon | Anker PowerPort 6(60W 6ポート USB急速充電器)

まとめ

簡単ですが作業環境でした。だいたい満足しています。もうちょっと改善したいなと思っているのは次の点です。

USB-Cドック?ハブ?みたいなものがほしい
- 充電ケーブル、マイク、ディスプレイケーブル、有線LANの4つのケーブルがMac Book Proに刺さっており、ポートが全滅です。出先から帰ったときにつなぐのも少し面倒なので、1つか2つのポートでまとめられるといいなぁと思っています。が、ドック系はいい値段するのでまだ置き換わっていない感じです。
スタンディングデスクが気になる
- 自宅でずっと座っているのはやはり気になるもので。スタンディングデスクにして時々たって作業したいなぁと思うことがあります。ただ、使ったことがないので、どれがいいのかわからず手を出せない状況です。
ウェブカメラいる?
- Mac Book Proのカメラでオンラインミーティングなどしています。気にするほどのことではないとは思いますが、メインディスプレイを見ながらしゃべると下からカメラで撮影されている形になります。。。

今のところはこんな形です。なにかの参考になればと。あと、なにかおすすめのもの(特にスタンディングデスク)があれば教えて下さい!

Rust the book - 第4章

Thu, 26 Mar 2020 17:12:11 +0900

前回の記事はこちら。自分用のメモなので、読みにくいかもです。

Rust the Bookを読み始めた

第4章

第4章です。たぶん、これがいちばん大事な概念だと思います、Rustの。そして、つまみ食いしながらRust書いてましたが、ここがきちんと理解できないまま書いてたってのもあります。。。

所有権とは?

drop関数ってのがあって、明示的に呼ぶことも可能。次のような感じで。2つ目のprintln!はエラーになる。sがもう無いのに借用しようとしてるから。

fn main() {
    let mut s = String::from("hello");
    s.push_str(", world!");
    println!("{}", s);
    drop(s);
    println!("{}", s);
}

ムーブ - shallow copyではない。以下の2行目がムーブ。

let s1 = String::from("hello");
let s2 = s1;

println!("{}, world!", s1);

スタックとヒープの話が絡んでくる。あんまり意識すること無いよなぁ。スタック = 固定長のデータを入れる場所。ポインタ、数値などヒープ = 可変長のデータが入る場所。可変の文字列とか。

クローン - ヒープのデータをコピーすること。
コピー - スタックに収まるデータの場合はクローンが必要なくコピーで事足りる。
- CopyトレイトとDropトレイトは同居できない。
- タプルのコピーはややこしそう
所有権と関数でまた、スタックに入れられるような変数と可変のオブジェクトの違いが出てくる。
- takes_ownership(s: String)が参照を受け取れば問題なく、このあとも使える。
- 戻り値でもムーブが発生

参照と借用

借用 - 関数の引数に参照を取ること
可変な参照&mutは1つ(不変な参照も含めて1つ)しか許さない
- データの競合を防ぐため。
- 不変な参照を複数用いるのはOK
- 実際に変更が実行されるタイミングでエラーと判定される場合もある。

let mut s = String::from("hello");

{
    let r1 = &mut s;

} // r1はここでスコープを抜けるので、問題なく新しい参照を作ることができる

let r2 = &mut s;

ダングリング参照はテスト書くときとかにやってるかも。。。

fn dangle() -> &String { // dangleはStringへの参照を返す

    let s = String::from("hello"); // sは新しいString

    &s // String sへの参照を返す
} // ここで、sはスコープを抜け、ドロップされる。そのメモリは消される。
  // 危険だ

スライス型

部分的な参照。開始位置+長さで構成されているっぽい
&strの説明がよくわからなかった。

引数としての文字列スライスのテクニックは色々と使いまわせそう。

まとめ

所有権、これまで特に難しいと思ってたのは、固定長の変数と、可変長の変数の違いを意識してなかったのが原因っぽい。まぁ、Vecとかがどうなるのかとか、他にもいくつか気になるところはあるので、もうちょっとやらないといけないなと思いました。

ElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン

Wed, 25 Mar 2020 11:10:05 +0900

先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。このプラグインを作ってたタイミングで、Elasticの河村さん経由で、Microsoft Open Tech Night #9 w/ ElasticでなにかLTしませんか?という打診がありました。

仕組み的には似たようなものだし、Elasticsearch用の拡張機能も作れるし、発表のネタにもなるし一石二鳥では?ということで、LTを快諾し、昨日発表してきました。

資料とか

発表資料やGitHubのリポジトリなどは、以下のとおりです。

発表資料 : Analyze APIのVS Codeプラグインを作ってみた
GitHub Repository : https://github.com/johtani/vs-code-es-analyze-client
Visual Studio Code Marketplaceページ

機能

まだ、必要最低限の機能を実装した感じです。

Analyze APIのパラメータ入力用のエディタ起動(Elasticsearch Analyze Client: Create Elasticsearch Analyze Request)
Esにリクエストを送信して結果の表示

インストールからリクエスト送信して結果が出てくるまでのデモです。

1点LTのデモのときに話すのを忘れていましたが、.esanalyzeという拡張子のファイルであれば、このプラグインが入力値を見つけ出して、「Analyze text with analyzers」というコマンド送信用のリンクをエディタ画面に表示する機能があります。ですので、パラメータ入力用のエディタを起動し、値を設定したあとにファイルをhoge.esanalyzeというような名前で保存してもらえれば、後日そのファイルを開くことでリクエストが再送できます。

Azure Search版との機能の違い

先日のAzure Search向けのクライアントとの違いがいくつかあります。 ElasticsearchのAnalyze APIの方が多機能であるため、プラグインとしても違いがあったほうがいいかなと。

入力がJSON形式
結果画面に詳細表示切り替えボタンを追加

現時点では対応していませんが、Analyze APIはカスタムのtokenizer、filter、char_filterの設定を入力として受け付けることが可能です。そのときに指定するのはJSON形式でtokenizerなどの設定を記述します。今後、これらの対応をすることを考えると、入力全体をJSON形式で読み込めるほうがわかりやすいかなということで、入力はJSON形式で入力してもらうことを想定しました。

結果画面に詳細表示切り替えボタンを追加したのは、2つの理由があります。1つはAzure SearchのAnalyze APIよりもTokenの情報としていくつか他の情報も存在するためです。複数のAnalyzerとの比較をする場合は、単語列だけを比較したいですが、Analyzer個別の詳細情報を見たい場合もあるので、切り替えができたほうがよいかなと。 2つ目の理由はまだ実装していませんが、explainパラメータの出力への対応のためです。 explainパラメータを指定すると、カスタムAnalyzerの場合に、Analyzerの設定にあるchar_filter、tokenizer、token_filterのそれぞれのステップでの単語列の出力が結果として返ってきます。この結果には標準の出力よりもさらに多くのtokenの情報(例えば、kuromojiだと品詞情報、読み、原型など)が追加されてきます。これらの表示を切り替えることができたほうがよいかと。

これらは、実はKibanaのプラグインとしてすでに実装済みになっています。同等の機能は実装できるかなという目論見もあり、そちらに合わせた感じにしてあります。

今後の対応

現時点では、Analyzer名の指定のみが可能となっています。Kibanaのプラグインと同程度の機能はGitHubのIssueとして登録してみました。

その他に、インデックス名やアナライザ名の自動補完みたいな機能があると便利かも?と妄想していたりします(実装が大変かもですが。。。)。Kibanaのプラグインの場合は、Mappingやインデックス名を調べるときに、KibanaのConsoleからチェックすればよかったのですが、このプラグイン単体だとそのあたりの情報の取得に他のツール(Kibanaだったり、REST API Clientだったり)を使わないといけないという問題点はあるかなぁと。

あとは、結果画面がこのままで本当に見やすいかどうか?なども気になってはいます。

まとめ

まだまだ、作ってみたというレベルのプラグインです。どのくらいの人に使ってもらえるかもわかりませんが、こんな機能あるといい?など要望があればリクエストいただければと。 Twitterで聞いていただいてもいいですし、GitHubのIssueとして登録していただいても構いません。そもそもいらないなぁなんて意見でももちろん大歓迎です。フィードバックお待ちしてます!

Analyze APIのVS Codeプラグインを作ってみた

Tue, 24 Mar 2020 00:00:00 +0000

Rust the Bookを読み始めた

Mon, 23 Mar 2020 10:57:22 +0900

自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読み始めてます。コツコツ読むってのが苦手なので、知り合いと小規模オンライン読書会しながら読むことになりました(基本的になにか書きながら、使い方を調べるので、存在そのものを知らない記述や使用法などがあったりする)。

基本は日本語版を読んでいます。まずは1章から3章あたり。

気になった点などを。自分用のメモなので、読みやすさとかは考えてないです(あとで自分が死ぬパターン?)。

1章

rustfmt便利。
- CLionのRustプラグインでは、保存時にrustfmtするというオプションがある。デフォルトはオフ。“Run rustfmt on Save”
cargoの--binオプション。意識してつけたことなかった=デフォルトだった。
- ライブラリにするときは--lib

2章

「変数を値に束縛」という言い回しにまだ慣れない。
- 「代入」という言い方に慣れているから?
- ただ、エラーにはassignってあるな。“error[E0384]: cannot assign twice to immutable variable x”
preludeというのがデフォルトで読み込まれる型が存在する場所。
.expect()により、Resultが評価済みになる
マクロがまだ慣れない
extern crate rand;が最新版だと要らなくなっている。
rand::Rngはgen_rangeのためにuseしている。CLionだとかってにuseを推測して追加してくれた。
matchはswitch文みたいな感じ。けど、defaultが必ず実行されるって感じではないな。
- ただし、全て網羅しないと怒られるのが便利。
- アームという呼び方が新鮮
- 単一の式のときは{}が省略できる
- ブロック{}のときは、終わりにカンマを入力するとrustfmtが除去する(最後の条件かどうかは関係ない)。
シャドーイングは面白い。
- よく、hoge_strやhoge_intのような変数を書くので、ありがたい。
- ただし、コードを読むときに少し混乱しそう?
let ... matchで変数への束縛でmatchが使えるのは便利(これまで知らなかったので、変数宣言して条件つけて束縛する処理書いてた)。

シャドーイング?

fn main() {
    let x = 5;

    let x = x + 1;

    let x = x * 2;

    println!("The value of x is: {}", x);
}

とか

let spaces = "   ";
let spaces = spaces.len();

みたいに、同一変数名を使い回せること。再代入ではない

3章

constは型注釈が必須
100_000のような記述が便利(Javaもできるって言われてびっくりしたw)
タプルの中身を一部だけ書き換え可能。(mutを指定すれば)
- tup.0 = 20;のような感じで。
配列は固定長でかつ、同一の型のものだけが入る
文末にセミコロンがない場合に四季になるというのはちょっと射にくいので辛いのでは。。。
- 自分は明示的にreturnを書きたくなる。が、returnだと動かない場合もある。。。
let ... ifのような記述もできる。
(1..4)はRange型

おまけ

フィボナッチ数列計算してみろというのがまとめにあったので。こんな感じでいいのかな?

fn calc_fibonacci(n: usize) -> usize {
    if n == 0 {
        return 0;
    } else if n==1 {
        return 1;
    } else {
        return calc_fibonacci(n-1) + calc_fibonacci(n-2);
    }
}

その他

知り合いと読みすすめると、人が不思議に思ったところが、自分が理解が曖昧だったことなどに気づけて便利です。

Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)

Thu, 19 Mar 2020 10:50:15 +0900

動機

Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。そこで、検索の基本的な話をさせていただきました(もともとJJUGナイトセミナーでしゃべる予定だったスライドがベース)。

で、Elasticsearchなどの転置インデックスを利用している検索エンジンで検索の基本的な動作がどうなっているかを理解するのに、個人的には一番重要だと思っているのがAnalysis(Analyze)の機能です。転置インデックスの単語の切り出し方がどうなっているかによって、望んだ単語でうまく検索できているかいないかなどがわかります。

Azure Cognitive SearchもAnalyze TextというAPIを提供してくれています(内部的にはElasticsearchだし)。 APIはあるのですが、返ってくる結果はJSONです。また、他のAnalyzerの設定との違いなどをみたくなったりもします。やはり、普段使っているツールなどで簡単にどういう単語が出てくるかがわかるとうれしんじゃないかなぁ?と。

ということで、最初はPythonでちょっとAPI呼び出して、カンマ区切りで出力するものを作ってみたのですが、GUIとかあると便利かなぁという話になりました。最近、ブログ書いたりするのにVisual Studio Codeを使い始めているので、これなら使いやすいかなと。ということで、Visual Studio Codeの拡張機能(プラグイン?)としてインストールできるツールを作ってみました。 Azure Cognitive Searchを使っている人向けなので、ニッチなツールですが。。。

余談

Elastic Stack(Elasticsearch)向けにはKibanaのプラグインでAnalyze APIを可視化するツールを作ってます。 analyze-api-ui-pluginです。Elastic Stack、特にKibanaを必ず利用する方はこちらを使うと便利かもです。

概要と機能

Marketplaceに公開しているので、johtaniやAzure Search Analyze Clientなどで検索してもらえれば出てきてインストールができます。

機能としては、以下の2つです。

テンプレートから入力値設定用のドキュメントを作成(Untitled-1というドキュメントをエディタに新しく開く)
Azure Cognitive SearchのAnalyze Text APIを呼び出して、結果をHTMLのテーブル形式で表示

入力値設定用のドキュメント作成

APIの呼び出しに必要な情報を記入してもらうのに、いくつか案を考えました。

プラグインの設定に記入してもらう
環境変数とかを読み出す
テキストとして保存したファイルを使う

設定や環境変数だと、異なる環境に接続したりするときに、わざわざ設定し直すのがめんどくさいかもと。で、愛用していたREST API Clientを真似するのが良いかもという結論になり、.analyzeという拡張子のファイルから必要な項目を読み出して、APIを呼び出す形にしてあります。

Command Palette(左下の歯車マークもしくは、メニューのViewから開ける)からAzure Search Analyze Client: Create Azure Search Analyze Requestというコマンドを選びます。

すると、以下のようなファイルがエディタに開きます。

これらの項目をまずは埋めていきます。それぞれの値がどういったものかはGitHubのREADMEを御覧ください。

入力値エラー(存在チェックしかしていない)がある場合は、ダイアログが表示されます。

結果表示

値を入力したら、設定値と###の間に表示されているAnalyze text with analyzersというグレーの文字をクリックします。すると、APIにリクエストを送信し、結果が返ってきて、別のパネルとして表示されます。

複数のAnalyzerを入力値に設定すると、それぞれがどのような区切り方をするかがわかります。文字の下にある[0:2]は、その単語がもとの文章の何文字目から何文字目までに出現しているかというオフセットの表示になります。

もし、Analyzer名の設定ミスなどで指定されたAnalyzerがない場合は、結果画面にエラーが表示されるようにしています。

以上が簡単な機能の説明です。簡単なと言いつつ、これだけしか機能がありませんが。

Visual Studio Codeのプラグインの作り方

プラグイン自体の作り方に関してはVisual Studio CodeのGetting Startedがわかりやすかったです。 APIや機能が豊富なので、最初はちょっと戸惑いましたが、サンプルもGitHubで多数公開されています。

あとは、REST API Clientを参考にさせていただきました。

Getting Startedを一通り読むことで、なんとなくプラグインの作成からMarketplaceへのリリースまでが完了できました。 (TypeScriptに慣れていないのがあるので、プログラミング自体は手間取りましたが。。。)

今後の対応?

いまのところ、こんなところを考えていますが、こんな機能がほしい、バグが有るなどあれば、GitHubにIssueを上げていただければと(使う人すくないだろうけど)。

いろいろなエラーに関する対応
Readmeに画像をアップ
アイコン作成?
自動補完機能?

まとめ

Visual Studio Codeの拡張機能を作ってみました。 Yeomanによるプロジェクトテンプレートが用意されているので、とりあえず、Hello worldを作るのは簡単でした。試行錯誤しつつTypeScriptを書いたので、TypeScriptっぽくないところなどもあるかもですが、誰かの役に立つツールになってくれれば良いなぁと。

本当にその検索は自分が想像している検索になってますか？

Thu, 05 Mar 2020 00:00:00 +0000

実践Rust入門の3章を読み終わった

Mon, 02 Mar 2020 18:20:13 +0900

これまで

3章終了

3章の終わりまで読み終えた。

いきなり実践的なプログラムで少し面食らっていたが、ステップを追って所有権周りの話まで来たので、なんとなくRustのいいところが理解できたような気がする。

ただ、最後のsplit_at_mutが実際には内部でどういう形に変換することによって、コンパイルエラーにならずに、借用がうまく行っているのかあたりは、まだきちんと理解できていない。

これは、どの言語にも言えるんだけど、リファレンスをうまく読み解きながら、自分がやりたい処理ができるかどうかを考えるのって結構むずかしいなぁと思う。

benchmark.rsはコピペして実行しただけなので、またあとで読み返してみるかな。

ということで、ここから先は、基本を勉強する感じで4章から読みつつ、なんかプログラムをまた書いてみるか。

KuromojiのCLIコマンドとpicocliとGraalVM

Fri, 28 Feb 2020 11:49:39 +0900

Kuromoji-CLI

Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解析が出てきました。KuromojiのRustクローンみたいなものです。で、作者の人とのチャットの中で、「MeCabみたいなKuromojiのCLIないですかね？誰か知りませんか？」という話になりました。

自分は普段はKuromojiの確認をするのは、Elasticsearch関連もしくは、Azure Searchなどだったりするので、当たり前のようにKibanaを立ち上げたり、REST APIを叩いてましたが、たしかにコマンドラインインタフェースあると便利かも? と思い、作ってみるかということに。

picocli

いま、JavaでかんたんなCLI作るとなったら何がおすすめ？
— Jun Ohtani (@johtani) February 26, 2020

で、いつものツイートです。で、picocliという返信がありました。 JavaでCLIのプログラムを書くのが簡単になりそうだと。ドキュメントもしっかりしてます。サンプルも載ってるし。

Annotationで、コマンドの説明などパラメータ、オプションなどが記述でき、必須チェックなども可能です。

また、オプションの説明文に関しては、テンプレートを用いることで、取りうる値をEnumの値で出力してくれたりといった便利機能まで備わっていました。

GraalVM

また、GRAALVMとPICOCLIでJAVAのネイティブコマンドラインアプリを作ろうというスライドも教えてもらい、ネイティブコマンドまで作れるらしいと。なんて便利なんでしょう!ってことで、こちらもチャレンジしてみました。 GraalVMがどんなものかはなんとなくは知ってたのですが、何者だろう?とツイートしたところ、これまた返信が。

っ資料はかなり古いので現行版と乖離はあるけど概念は変わってないので..https://t.co/KRQjhNdD9f
— たむたむ🏫 (@tamtam180) February 26, 2020

本当に、Twitter便利ですね。

GraalVMがどんなものかもいただいた資料でサクッと理解できました。ただ、picocliが実はものすごく良くできており、自分でインストールする必要も実はありませんでした。

gradle-graalというGradleのプラグインと、 Picocli Code Generationを利用することで、以下のコマンドを実行することで、ネイティブコマンドアプリが作成できました。

gradle nativeImage

build.gradleファイルに記述したのは、以下のような項目です。

辞書が読み込めなかった

で、native imageを作って実行しましたが、Kuromojiが内包している辞書ファイルが読み込めませんでした。どうやら、picocli-codegenの自動生成では対応できない、リソース関連設定が必要らしいと。

picocli-godegenの設定を見ていて見つけたのが、other.resource.patternsというオプションでした。

kuromoji-cliのbuild.gradleに、その設定を加えたら辞書が読み込めるようになりました。

この設定をどうやって書くのか?というのを探すのにちょっと時間がかかりました。Picocli作者のRemko Popmaさんのサンプルリポジトリに設定を利用したbuild.gradleがありました。サンプル本当にありがたいですね。

完成

出来上がったのは、kuromoji-cliというリポジトリになります。内部で利用しているのはAtilikaのKuromojiです。LuceneのKuromojiではないのでご注意を(LuceneのKuromojiで最初やってみたのですが、リフレクションなどが多用されてて、Single Imageにするのが手間がかかりそうだった)。コマンドのポータビリティはそれほど無いと理解してる(あってる?)ので、利用してみたい方は、リポジトリをクローンしてからビルドしてみてください。

参考資料

まだ途中?

ほかにもあると便利かも?という機能があればIssueやPRを上げてください。とりあえず、頭にあるのは以下のとおりです。

JSONの出力はまだ未対応
いろんな辞書をAtilikaのKuromojiはサポートしてるのでそのへんも対応してみる?

実践Rust入門の3章を読んでるところ

Sun, 23 Feb 2020 16:37:17 +0900

これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。

実践Rust入門はじめました

3章のクイックツアーを読んでます。バイトニックソート自体の理解はちょっとおいておいて、読み進めています。いくつか疑問に思ったことがあったので、またメモを。まだ、3.5.7の手前ですが。

疑問点

3.4.1のジェネリクス対応のテストケースの部分で、既存のu32用のテストケースの入力のデータ列にVec<u32>という型注釈をつけるのですが、追加した文字列の入力データには注釈をここではつけないのはなんでなんだろう?ちなみに、なくても動いた。バージョンの違いとかあるのかしら?
3.4.6のmatch文
- match文の引数?が*orderになっていたが、orderでも実行できた。引数にくるのが参照だから*が付いてるんだとも運だが、なくても動くのはコンパイラがよしなに解釈してくれてるからかな?

便利なツール

Rust標準のツールの説明がいくつか3章で紹介されてて便利だったのでメモ。

rustfmt

フォーマッター。デフォルトでフォーマット機能が付いてるの便利ですね。言語として決まってると、プロジェクトごとに悩まなくていいってのがありますし。

rustfmt ファイル名

という形で使えるみたい。プロジェクトごとだとcargo fmtのほうが楽そうかな。

標準ライブラリAPIドキュメントをブラウザで閲覧

rustup doc --std

これでデフォルトブラウザでRustの公式ドキュメントが開きます。しかもローカルファイルだからサクサク。検索バーもついてて便利です。

エラーのドキュメントを閲覧

rustc --explain 308

コンパイル時にエラーが出たときに、error[E0308]のようにコンソールに出てきます。ヒントも出てくるのですが、詳細が上記のコマンドで読めるみたいです。

2019年に買ってよかったもの

Fri, 21 Feb 2020 17:05:02 +0900

もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。

BRAVIA KJ-55X9500G

Amazon | ソニー SONY 49V型液晶テレビブラビア 4Kチューナー内蔵

テレビをやっと買い替えました。前に使っていたのはプラズマディスプレイで、10年以上たったもので、パネルの一部が赤い残像が残ってたりしました。もう流石にいいでしょうということで、買い替えたのがSonyのテレビです。 4Kのチューナーもついているし、アップコンバーターもついているので普通の地上波でもきれいです。まぁ、10年前のテレビに比べればたくさんいいことがありますよねw

新しいTV買って一番活躍してるのはYouTubeボタンだったりします。最近はミュージックビデオがYouTubeにたくさんあるので、King Gnuなどの音楽流したりするのに便利です(テレビなのに)。今は、プライムビデオボタンがより活用される感じになってきてます(テレビなのにw)。

Sodastream

Amazon｜スピリットワンタッチホワイトスターターキット

ここ数年、炭酸を普段飲んでます。甘いもの飲まないようにって意味でも。。。で、これを買うまでは、サントリーの天然水スパークリングレモンとかを、箱買いしてました。が、まぁ、ペットボトルのゴミが半端ないんですよ。場所も取るし。

ソーダストリームのことは知ってたのですが、自分で炭酸の量を考えながら、入れないといけないので避けていました。

が、今回購入したものは、水の入ったボトルを指して、ボタン一つで3段階の炭酸を入れることができるんです!買って本当に重宝してます。うちでは1Lのボトルを1本追加して、2本で運用してます。家族はなっちゃんのオレンジとかを炭酸割りしたり、カルピスソーダ作ったりして楽しんでます。ワンタッチということで、簡単に入れられるので家族も重宝してます。

Nature Remo + Chromecast

Amazon | Nature スマートリモコン Nature Remo mini Remo-2W1

Google Home miniがキャンペーンで手に入ったので、ベッドルームの照明やクーラーの操作もできそうなのでNature Remoを導入しました。 Chromecastは余っている液晶モニターにつないで、スマホからキャストできるようにしたり、音楽聞けるようにしてあります。

Nature Remoは温度計などもついているので、部屋の温度に合わせてエアコンのオンオフなども可能で、暑い夏にとても便利でした。寝る時間にはクーラーが入っているのですんなり寝れたりと。スマホから電源オンオフできるのも便利ですね。 Chromecastはモニターにつなぎましたが、今は、Google Music Playのプレーヤーになってます。 (最近、家にあるCDを読み込んでGoogle Play Musicにアップしてる)。

ただ、それ以上のことには使えてないので、もうちょっと面白いことしてみないとなぁ。

モニターアーム

Amazon | HUANUO PC モニターアーム液晶ディスプレイアームガススプリング式

Amazon | グリーンハウス液晶ディスプレイアーム 4軸クランプ式

ディスプレイがふるくなってたので、4Kディスプレイに買い替えた(27インチで4万切るとかで安い。。。)んですが、Mac Book Pro 15インチ(今は16インチ)を使っていて、Macの画面がディスプレイにかぶるのでモニターアームを買いました。 1つ目がガススプリング式のアームです。なのに、5000円を切ってるんですよ。おそるべし。 2つ目はクランプ式です。アームにしたものの特に動かすことはなく、高さを出したいだけってことがあるので、クランプ式のも使ってます(家ではディスプレイ2枚使ってる)。コスパ最高です。

Anker PowerCore 10000 PD

Amazon | Anker PowerCore 10000 PD（10000mAh PD対応最小最軽量大容量モバイルバッテリー）

Pixel 3にしてから、電池の持ちはよくはなってるんですが、もしもの時のためにモバイルバッテリーは話せないですよね。 PD対応なので、Pixel 3に急速充電ができるし、サイズもそれほどじゃまにならないサイズなので便利です。USB-Aもついているので、このあと紹介するイヤホンの充電ケーブルなんかも差し込めて大活躍です。

サウンドピーツのイヤホン

Amazon | SOUNDPEATS(サウンドピーツ) Q35HD ワイヤレスイヤホン高音質・低遅延 IPX8防水

私が持ってるのはこの前のバージョンで、micro-USBで充電するタイプですが、こちらもコスパ最高です。冬は防寒も兼ねてヘッドフォンをしているのですが、春から秋にかけてはこれまで、優先のイヤホンを使ってました。もしくは、Bluetoothのレシーバーに優先のイヤホンつけてました。電池切れたら、イヤホンさして使う感じで。が、Pixel 3はイヤホンジャックがありません。ということで、ワイヤレスイヤホンに移行するかということで選んだのがこちらです。世の中的には、完全ワイヤレスイヤホンが流行っていますが、片方無くなってしまうイメージしかわかなくて。。。これが壊れても、完全ワイヤレスではなくつながったワイヤレスイヤホンを使うと思います。

ヘッドルーペ

Amazon | Tumao ヘッドルーペルーペメガネ LED付拡大鏡眼鏡の上装着メガネゴムバンド両用 5レンズ交換調節

プラモデルをちょいちょい作るんですが、もう年ですね。。。細かいところが見にくくて。ガンダムのRG系のプラモデルだと、1/144なんですよ。小さいんですよ。見えないんですよ。。。

完成しましたー！ pic.twitter.com/S9QTS4kJDI
— Jun Ohtani (@johtani) February 16, 2020

ということで、ヘッドルーペ導入してみました。最初は、卓上に置けるルーペにしてみたんですが、自分がルーペがあるところに動かないといけないの結構つらくて。これのおかげで、プラモデル作成に問題はなくなりました。老眼とは関係なく、ちょっと猫背になっちゃうのが今は悩みの種ですが。。。こたつで作ってるからなぁ。

まとめ

ということで、いくつかよかったものを紹介してみました。今年はちゃんと年末に書こう。。。

ブログ移行日記(その5) - Jugemのブログを移行

Fri, 21 Feb 2020 12:04:00 +0900

ブログ移行日記(その5)です。前回まではこちら

今回はこれまでとは異なる特殊な話です。

最初にブログを書き始めたときに利用していたのがJugemのブログでした。その後、Octopressに移行して、今年、Hugoに移行したという流れです。

で、よくよく考えると、Jugemのブログも移行できるんじゃないか?となりました。じゃあ、やってみるかと。なので、今回のブログは自分の備忘録です(興味のない人が大多数じゃないかな)。一応、Pythonで書いたプログラムはGitHubに上がっています。文字列置換と正規表現のオンパレードです。

JugemからExport

まずは、移行元のデータが取り出せるかどうかを調べたところ、text形式もしくはXML形式でエクスポートが可能でした。

変換処理が必要なはずなので、XMLでダウンロードします。独自のXMLですが、記事ごとにXMLのタグ(<entry>)でまとめられているので、処理が楽です。

XMLをMarkdownに

<entry>タグの下に次のような項目が入っているので、抜き出します。

ヘッダ部

title - 記事タイトル
author - 著者
category - タグ
date - 投稿日付
description : 本文(先頭部分)
sequel : 本文(つづき)

titleからdateまでをHugoのMarkdownのヘッダ部分として出力します。日付は形式が違うので合わせるように変換し、 titleは(Jugemより移植)という文字列を追加しました。

また、Hugoの個別のコンテンツにするためにそれぞれをMarkdownのファイルに変換しています。ファイル名は変換後のdateの先頭10文字(yyyy-MM-dd)に-を付け加えて、タイトルを追加しました。ホントは英語のファイル名にしたかったんですが、ちょっと手抜き。ファイル名に使用できないような文字は-に置換しています。

本文

本文部分はもう少し複雑です。まずは、descriptionとsequelから抜き出した文字列を結合します。

で、内部の文字列に次のようなものがあるので、それぞれMarkdownに変換したりという処理を書いてます。

などです。アフィリエイトタグは、数行に渡るの複数のHTMLタグで記述されているので、 ASINと商品タイトルだけを抜き出しています。 Hugoでアフィリエイトのリンクを作るために、hugo-amazon-jpという公開されているshortcodeを元に、カスタマイズしたものを使っています。これ用に、必要なASINとタイトルを別ファイルに出力したりしています。

また、いくつか画像を使っている記事があったのですが、これが曲者でした。 XMLに入っているimgタグに画像へのURLがあるのですが、アクセスしても存在しないURL担っています。。。ブログで公開している画像のファイル名に似たものがXMLに入っていたので、URLを組み直して、ダウンロードするという処理も書いています。

あとは、昔ちょっと凝った書き方(spanタグで章みたいなことやってた)をしていた部分の処理を加えて完成です。

まとめ

元のXMLを見たり、抜き出したファイルを見ながら、トライアンドエラーでプログラムを書きました。なんとなく変換できたなかっていうところで、取り込んで公開しました。まだ、全部の記事をチェックしてないですが、なんとなく移植できたので一旦これでいいかなと。昔の記事を見たときにおかしい場所があったら手で治すつもりでいます。

なんか、もうちょっとうまくプログラムかけた気もしますが、書き捨てのプログラムだと思うのでこんなもんかな。

1点気になっているところは、コメントの部分です。ブログにコメントをいただいていたのですが、その部分は移植できてないです。

Octopresに移植していこうは、Disqusのサービスでコメント部分を提供しています。ここに移植するのも変な話だなぁと思っているので、本文にコメントを取り込む感じかなぁ？

もともとのJugemのサイトもそのまままだ残してあるので、そのうち気が向いたらで。

Azure Cognitive Searchでインデックスを作って検索

Wed, 19 Feb 2020 11:48:01 +0900

お手伝いしているお客さんがAzure Cognitive Searchを利用してます。検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、いくつか触った感触をブログにまとめてみようかと(お客さんからはOKいただいてます)。

Azure Cognitive Searchとは？

公式サイト

「AIを活用した」クラウド検索サービスと紹介されています。

昔はAzure Searchと呼ばれていましたが、ここ最近はAzure Cognitive Searchと呼ばれているみたいです(Microsoft Igniteで発表された話がまとまっているページもあります)。もともと、検索エンジンのSaaSサービス(キーワード検索、あいまい検索、オートサジェスト、スコアリングなどの機能)として作られていた部分に、データの登録パイプラインにCognitive Serviceの便利な機能を簡単に使えるようにしたものというイメージでしょうか。

バックエンドはElasticsearchのはずです。変わってなければ。昔、Elastic社主催のユーザーカンファレンスでMSの方が公演された資料が公開されていたりします。ちなみに質問が多いのでしょうか、Azure Cognitive SearchとElasticsearchの違いはなんですか?というページがよくある質問のページに用意されていました。参考までに。

今回はちょっとしたインデックスをつくって検索する部分を紹介してみようかと思います (Cognitiveなところは機会があればまた)。

普通の使い方については、Azureのドキュメントなどを読んで頂く形にします。ポータルと呼ばれるブラウザ上でAzureのサービスを触ることができる画面が用意されています。ここで、簡単な操作(インデックス作成、フィールドの追加)

APIを使ってインデックス(特にAnalyzer)の設定をしたり、データをいれて、クエリしてみるというところをサクッと紹介しようと思います。

インデックスの作り方

インデックス作成に関するドキュメントも用意されています。最初はポータル(GUI)でインデックスを作成する方法が紹介されています。ですが、今回はn-gram(n=2)のAnalyzerを利用したかったので、GUIではなくAPIでインデックスを作成しました。カスタムアナライザーを利用する場合、REST APIを利用しなければ行けないということになっています。 n-gramのAnalyzerを含むインデックス生成のREST APIは以下のとおりです。こちらを実行することで、インデックスが作成されます(JSONの記述ミスなどがある場合はエラーが返ってきます)。

@host = <サーチのサービス名>.search.windows.net
@api-key = <APIキー>

###

POST https://{{host}}/indexes/?api-version=2019-05-06
Content-Type: application/json
api-key: {{api-key}}

{
    "name":"ngram-test",
    "fields":[
       {
          "name":"id",
          "type":"Edm.String",
          "key":true,
          "searchable":false
       },
       {
          "name":"ngram",
          "type":"Edm.String",
          "searchable":true,
          "analyzer":"bi_gram_analyzer"
       }
    ],
    "analyzers":[
      {
         "name":"bi_gram_analyzer",
         "@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
         "tokenizer":"bi_gram_tokenizer",
         "tokenFilters":[
            "lowercase"
         ]
      }
    ],
    "tokenizers":[
       {
          "name":"bi_gram_tokenizer",
          "@odata.type":"#Microsoft.Azure.Search.NGramTokenizer",
          "minGram":2,
          "maxGram":2
       }
    ]
 }

なんだかどこかで見たことのある記述のようなそうでないような。。。 Analyzerは、charFilters(0以上複数可)、tokenizer(1つ必須)、tokenFilters(0以上複数可)から構成されます。フィールドで指定するのはAnalyzerなので、まずanalyzersにCustomAnalyzerの設定を行います。名前はbi_gram_analyzerにしました(好きに付けてください)。 tokenizerにはこのあと設定するtokenizerの名前を設定します。ここでは、bi_gram_tokenizerという名前にしています。また、大文字小文字を気にせずに検索したいため、tokenFiltersにlowercaseを指定しています。こちらはすでに定義済みのため、定義済みの名前で呼び出すだけで使用できます。

次が、bi_gram_tokenizerの設定です。 n=2としたいので、tokenizers配下にTokenizerの設定をします。 @odata.type":"#Microsoft.Azure.Search.NGramTokenizerがTokenizerの名前です(ちょっと独特な名前ですね)。 Tokenizerごとにオプションがあり、NGramTokenizerの場合は、minGram、maxGramがオプションに相当します。今回は2文字ごとにトークンを出力したいので、minとmaxをそれぞれ2としています。

これで、あとは、フィールドでanalyzerという設定にbi_gram_analyzerを指定すればそのフィールドはbi_gram_analyzerを使用してアナライズされるようになります(このへんはElasticsearchといっしょですね)。フィールドは文字列を扱うので、Edm.Stringというタイプにしてあります。データ型については、フィールドコレクションとフィールド属性というドキュメントを参考に設定しましょう。

閑話休題 - REST Client Exstension for Visual Studio Code

なお、今回のサンプルはREST Clinet Extention for Visual Studio Codeを利用する想定の記述になっています。

Visual Studio Codeで.restもしくは.httpというファイルに以下のAPIを記述すると、Send RequestというリンクがURLの上部に出てくるような拡張機能です。REST APIにリクエストするときに便利なツールになっています。変数も使えるので、APIのキーやURLの一部をこのように共通化して、他の環境でも使いやすくできるのは素晴らしいなと。

アナライザーの挙動の確認

設定したAnalyzerがきちんと機能しているかというのを確認する必要があります。入力した文字列がきちんと想定している単語として切り出されて、転置インデックスの見出し語に使われるかというのが重要になるからです。

Azure Cognitive Searchでもアナライザーのテスト用APIが用意されています。使い方はこちら。 APIの仕様のページもありました。「アナライザーの挙動はどんな感じ？」という文字列が、作成したインデックスの定義したアナライザーbi_gram_analyzerにより、どのように分割されるかを確認するAPIの呼び出しは以下のとおりです。

###
POST https://{{host}}/indexes/ngram-test/analyze?api-version=2019-05-06
Content-Type: application/json
api-key: {{api-key}}

{
   "analyzer":"bi_gram_analyzer",
   "text": "アナライザーの挙動はどんな感じ？"
}

レスポンスはこんな形です。ヘッダ部分は省略してあります。

{
  "@odata.context": "https://{{host}}.search.windows.net/$metadata#Microsoft.Azure.Search.V2019_05_06.AnalyzeResult",
  "tokens": [
    {
      "token": "アナ",
      "startOffset": 0,
      "endOffset": 2,
      "position": 0
    },
    {
      "token": "ナラ",
      "startOffset": 1,
      "endOffset": 3,
      "position": 1
    },
    {
      "token": "ライ",
      "startOffset": 2,
      "endOffset": 4,
      "position": 2
    },
    {
      "token": "イザ",
      "startOffset": 3,
      "endOffset": 5,
      "position": 3
    },
    {
      "token": "ザー",
      "startOffset": 4,
      "endOffset": 6,
      "position": 4
    },
    {
      "token": "ーの",
      "startOffset": 5,
      "endOffset": 7,
      "position": 5
    },
    {
      "token": "の挙",
      "startOffset": 6,
      "endOffset": 8,
      "position": 6
    },
    {
      "token": "挙動",
      "startOffset": 7,
      "endOffset": 9,
      "position": 7
    },
    {
      "token": "動は",
      "startOffset": 8,
      "endOffset": 10,
      "position": 8
    },
    {
      "token": "はど",
      "startOffset": 9,
      "endOffset": 11,
      "position": 9
    },
    {
      "token": "どん",
      "startOffset": 10,
      "endOffset": 12,
      "position": 10
    },
    {
      "token": "んな",
      "startOffset": 11,
      "endOffset": 13,
      "position": 11
    },
    {
      "token": "な感",
      "startOffset": 12,
      "endOffset": 14,
      "position": 12
    },
    {
      "token": "感じ",
      "startOffset": 13,
      "endOffset": 15,
      "position": 13
    },
    {
      "token": "じ？",
      "startOffset": 14,
      "endOffset": 16,
      "position": 14
    }
  ]
}

このAzure SearchのAnalyze API、使用できるオプションはすくないですが、ElasticsearchのAnalyze APIと似ています。

データの登録の仕方

データ登録もAPIからできます(あたりまえですね)。 APIは1件ずつではなく、バルクで登録できる形で提供されています。

サンプルとしては、以下のような形です。 @search.actionの部分(searchがあるとわかりにくい気がするけど。。。)が、ドキュメントの登録、更新、削除の命令を書き込むところになります。今回は単純に登録するだけなので、uploadを指定しました。ほかにもいくつかアクションが用意されています。用途に合わせて指定する感じになります。 id、ngramはそれぞれフィールド名です。ドキュメントに登録したい値を記述します。


POST https://{{host}}/indexes/ngram-test/docs/index?api-version=2019-05-06
Content-Type: application/json
api-key: {{api-key}}

{
  "value": [
    {          
      "@search.action": "upload",  
      "id": "1",
      "ngram": "新しいAzure Searchの使い方"
    },
    {          
      "@search.action": "upload",  
      "id": "2",
      "ngram": "Elasticsearchの紹介"
    }
  ]
}

検索クエリ

最後は検索クエリです。検索クエリはいくつかのオプションがあります。ざっくりだと、queryTypeがsimpleとfullという2種類が用意されており、ちょっとした検索を作る場合はsimpleで事足りそうという感じです。入力された単語(スペース区切りで複数扱い)をフィールド(複数可)に対していずれかの単語を含むもしくは、すべての単語を含むという検索に行くというパターンですね。このときの、「いずれか」か「すべて」の設定がsearchModeというパラメータになります。 anyの場合、Googleの検索と同様に、どれかの単語が入っているドキュメントが対象に、allの場合すべての単語が含まれるドキュメントだけがたいしょうになるといった形です。

queryType=fullの場合はLuceneの構文でクエリがかけます。ElasticsearchのQuery String Queryみたいな形です。

簡単なサンプルは次のような感じです。このサンプル


POST https://{{host}}/indexes/multi-field-test/docs/search?api-version=2019-05-06
Content-Type: application/json
api-key: {{api-key}}

{
   "search": 'ngram:"使い方" ngram:"紹介"',
   "queryType": "full",
   "searchMode": "any"
}

すこしだけクエリの補足を。 searchに入力された単語をダブルクォートで囲んでいます。これは、「使い方」という文字がbi_gram_analyzerにより「使い」「い方」に分割されるのですが、必ずこの順序で出現したものだけを検索対象にしたい(フレーズ検索)という意味になります(*bi_*gramなので、「紹介」に関してはダブルクォートは厳密には必要ないです)。

あと、レスポンスは今回記載していませんが、@search.scoreという項目で、スコアが返ってきます。デフォルトのスコア計算には何を使ってるんだろう?ドキュメントにはTF-IDFとの記述があるのですが。。。カスタマイズもできそうです。

少しオモシロイと思ったのは、スキーマ(インデックスの設定)に定義されているが、ドキュメントとしては登録していない項目についても、 Azure Cognitive Searchはドキュメントのフィールドがnullという形で返ってくるようでした。そもそもフィールドが存在しないドキュメントとフィールドの値がnullのものの違いは無いようです。

簡単ですが、インデックスの設定、ドキュメントの登録、検索の方法の紹介でした。

ちょっと触った感想

一番売りである、Cognitiveの部分はまだ触っていないです、すみません(こっちが売りな気もするんですが)。検索エンジンの部分としては、Elasticsearchを知っていると、「あー、そんな感じね」という気持ちになれるサービスです。個々のAPIやデータの形式は異なるので、きちんとAPIのリファレンスなどを確認しつつという形になりますが、なんとなくこういうAPIなどがありそうだな?と予測しつつ使えるかなと。内部的にはElasticsearchだと思いますが、独自のAPIでラップされているおかげで、バージョンの違いなどを意識せずに使えるのではないかと思います。

また、今回は紹介していませんが、マイクロソフト独自の各言語のアナライザー(日本語も含む)があります。 Luceneのアナライザーとマイクロソフトのアナライザーのどちらも利用できますので、ここの違いを見てみるのも面白そうだなと思いました。緯度経度を利用した検索、フィルター検索(スコア計算対象にならない)、ファセット、スコア調整の機能なども備えているようです。

なんにせよ、利用する場合やドキュメントを読む場合に、全文検索の仕組みをなんとなく知っておいたほうが読みやすいんじゃないかなというのが感想です。

ここ数年はElasticsearchがメインでほかはほぼ触っていない状況だったので新しい製品に触れるのは面白いですね。時間があったら、アナライザーの違いなども調べてみたいなと思います。

「検索システム探訪」したいな=>やりました

Mon, 10 Feb 2020 23:20:27 +0900

また、ツイートから始まるお話です。まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。

「検索システム探訪」みたいな名前がいいかな? https://t.co/sG7BDdGI9h
— Jun Ohtani (@johtani) February 6, 2020

検索について知り合いとお茶をしながら話をしていて、こういう話を聞くの面白いなぁと思ったので。どんなことを個人的には聞きたいかな?というのをまとめといたほうがいいかと思いブログを書いています。こんなことも面白そうだよね?

どんなこと聞きたいかな?

いまのところ思いついた内容はこんな感じかな? こんなのも聞くと面白そうだよね?などありましたら、コメント欄に書いてもらえればと。

利用しているシステム・サービスは?
- 構成やどこのサービスなのか？
検索ユーザーはどんな人？
- ユーザーの種類
- ユーザーの検索ニーズ
検索対象データはどんなもの？
- データ件数はどのくらい？
- 属性、項目がどのくらいあるか？
検索結果として出したいものは？
- ソートはどんなものがあるの？
- ランキングで重要なものは？
UI/UXはどんな感じ?
- ハイライト、ソート、ファセット(Aggs)
- キーワードサジェスト、オートコンプリート
検索システムの監視(オブザバビリティ??)
- ビジネス的な指標
- クエリログ、クリック(ユーザーに関する情報)
- システムメトリクス
困っていることは？
- ランキング
- クエリ
- 検索システム分析

第1回やりました。

ちなみに、最初のツイートに対して、すぐに返事をくれた方がいました。

うちでよければご説明します！
— Kizashi （令和もRailsエンジニア募集中） (@kizashi1122) February 6, 2020

Twitter本当にありがとうございますという感じです。

で、早速話を聞かせていただきました。大阪の方だったので、テレカンでやらせていただきました。移動時間とか気にせずにできるので、テレカン形式いいですよね。

内容は、非常に面白かったです。使ってるシステムについて、どんなところで、どのようなように検索エンジンをつかっているのか、どんなことで困っているのかなどをお聞きすることができました。

2020/02/13 追記

対応していただいたIngageの永田さんから、内容を公開しても良いという承諾をいただいたので、メモを公開します。

サービス : Re:lation
- 問い合わせメールなどのチームで対応する対応
利用している検索エンジン
- Elasticsearch (AWS Es)
  - ノード数 8 - 3 master + 5 data
データ
- データ数 : 約1億5千万
- 親子関係 : チケット - メール(=1ドキュメント) - コメント
  - 画面としてはチケットの一覧=aggsでチケットIDの一覧を生成してリスト表示
- インデックス数 : 5 = テナントごとに振り分けしてる。
  - 8シャード - スケールアウトした場合も対応できるので。
- PostgreSQLにマスターは保存
- データの単位はメール。コメントはtextの配列でメールに保存されている。
- EsはIDの一覧を返す。ただし、チケットのIDの一覧
機能
- ハイライト
  - Esではなく独自実装。
- クエリ
  - n-gramでやってる = kuromoji使ってない
  - min=1, max=2
悩み事
- EBS上だったものをローカルにしたので速くなった。
- 期間が長いと、検索結果一覧の表示が遅い
  - aggsが遅いのかな?
  - 検索結果一覧はチケットが持っているメールの日付の降順。結果一覧はチケットの一覧。
- 詳細検索はDB、左のステータスもファセットも現在はDBから生成
  - Es使ったほうが早いかも?
- マルチテナントのつらさ
- 検索ログ
  - 独自ログはとっていない = アプリのログから判別
今後
- アドレス帳検索

お誘いお待ちしております!

今後もこれやっていきたいなぁ。話してもいいよ!という方がいらっしゃいましたら、@johtaniまでDMもしくはメンションをください。お待ちしております!

ボードゲーム紹介

Sat, 01 Feb 2020 21:04:54 +0900

年末、何種類かのボードゲームを家族で楽しみました。家族の感想を交えて簡単に紹介しようかと思います。家族や知人でボードゲームを購入するときの参考に参考にしてもらえたらと。それぞれのゲームの詳細については、それぞれWikipediaなどのリンクを張っておくので、参考にしていただけたらと。結構有名なボードゲームが多いのかな?

カタン

Amazon | カタンスタンダード版 | ボードゲーム | おもちゃ

簡単な紹介

プレーヤー数 : 3-4名 (拡張版を追加すると5-6名でもプレイできるみたい)
対象年齢 : 10歳以上
種類 : 対戦型
紹介 : 大航海時代に発見された無人島を複数の入植者たちが開拓していき、もっとも繁栄したプレイヤーが勝利するという内容のボードゲーム(Wikipediaより)。
特徴 : 5種類の資源を元に、道を作ったり、開拓地や都市を作ったり、サイコロを使った運も必要ですが、プレーヤー同士で手持ちの資源を交渉することも可能なゲームです。

感想

最初の配置が重要な気がします。資源の組み合わせによってできることが変わってくるので、何をやりたいかというのを元に考えて配置するのが重要そうです(私はまだうまくできてませんがw)。
プレーヤー同士の交渉も1つの手段なので、会話しながら、自然と交渉術も身についてきそうです。
戦略だけじゃなくサイコロを使った運もあるので、子供と大人が混ざっていても偏った結果にはならないです。
自分の道や町が発展していくのも楽しみの1つです。

お化け屋敷の宝石ハンター

Amazon | お化け屋敷の宝石ハンター FBH20 | おもちゃ | おもちゃ

簡単な紹介

プレーヤー数 : 2-4名
対象年齢 : 8歳以上
種類 : 協力型
紹介 : お化け屋敷がおばけでいっぱいになる前に、みんなで協力して８つの宝石をみつけて、屋敷から脱出しよう！(メーカーホームページより)。
特徴 : 対戦ではなくプレーヤーみんなで協力してやるボードゲーム。おばけのフィギュアも可愛いです。サイコロを利用した運もありますが、みんなでどういった戦略で宝石を取り出すかなど会話も進むゲームです。上級編という難しめのルールも用意されているので、ハラハラ・ドキドキしながらプレイできます。

感想

負けて悔しくなったり機嫌が悪くなることがないのがいいですね。
普通のルールだと少し物足りない感じですが、上級編のルールはより、みんなで協力する必要が出てきます。
また、上級編のルールは絶妙な難易度で、もう一度やりたいと思わせるのが良い仕組みです。

ラビリンス

Amazon | ラビリンス (Labyrinth) ボードゲーム | ボードゲーム | おもちゃ

簡単な紹介

プレーヤー数 : 1-4名
対象年齢 : 8歳以上
種類 : 対戦型
紹介 : 動く迷路で宝探し！通路が動く不思議な迷路の中に、「宝物」や「奇妙な生き物」が隠されています。プレイヤーはこれらを集めてこなければなりませんが、そのためには、巧みに迷路を動かさなければなりません。(メーカーホームページより)。
特徴 : サイコロがないボードゲームです。先を予測しながら人のじゃまをしつつ、自分に有利に進めていくゲームです。プレーヤー個別に難易度を変えられる仕組みがあります(子供だけに有利なルール設定が可能)。

感想

子供ルールがあるので、1度のゲームで別々の難易度が設定できるのがいいです。左右盲の人には子供ルールとかもありです。
ラビリンスが得意な人は地図を読むのが得意な人だと思います。
頭も使うけど、自分が望んだ道ができた時の快感があります。

モノポリー

Amazon | ハズブロボードゲームモノポリークラシック C1009 正規品 | ボードゲーム | おもちゃ

簡単な紹介

プレーヤー数 : 2-6名
対象年齢 : 8歳以上
種類 : 対戦型
紹介 : プレイヤーは双六の要領で盤上を周回しながら他プレイヤーと盤上の不動産を取引することにより同一グループを揃え、家やホテルを建設することで他のプレイヤーから高額なレンタル料を徴収して自らの資産を増やし、最終的に他のプレイヤーを全て破産させることを目的とする。モノポリーとは英語で「独占」を意味する。(Wikipediaより)。
特徴 : 資本主義とは?みたいなのを体験できるゲーム。すごろく型ですが、ゴールがあるわけではなく、決着がつくまでぐるぐる回る感じです。

感想

資本主義を象徴しているゲーム展開。真剣勝負間違いなしです。
負けると途中退場ってのがちょっとつらいです。。。
カタンとは違った感じの交渉術になります。
コマが色んな種類があってかわいいです。

パンデミック

Amazon | パンデミック:新たなる試練 (Pandemic) 日本語版ボードゲーム | ボードゲーム | おもちゃ

簡単な紹介

プレーヤー数 : 2-4名
対象年齢 : 8歳以上
種類 : 協力型
紹介 : 『パンデミック』（Pandemic）は、プレイヤーが新型ウイルス対策チームの一員となり、協力しあい感染症の世界的流行（パンデミック）に立ち向かうというボードゲームである。(Wikipediaより)。
特徴 : プレーヤーが個別のロール(役割)を持っており、よりみんなで協力をしないとウイルスに打ち勝てない感じです。

感想

ルールが結構複雑で、理解しながらだと少し時間かかりました。
8歳以上になっていますが、少しむずかしい印象でした。
戦略、戦術が問われる形のゲームなのでしっかり理解すると楽しそう。
世界地図上で、ウイルスと戦っていく感じは臨場感があって面白いです。

ナインタイル

Amazon | ナインタイル | カードゲーム・トランプ | おもちゃ

簡単な紹介

プレーヤー数 : 2-4名
対象年齢 : 6歳以上
種類 : スピード対戦型
紹介 : 「ナインタイル」の基本ルールは、それぞれの手元にある、９枚のタイルを自由に動かしたりひっくり返したりして、誰よりも早くお題どおりに並べるだけ。(公式サイトより)。
特徴 : ボードゲームというか、カードゲーム。ルールは簡単ですが、記憶力と素早さが重要です。

感想

脳トレに良さそう(子供に勝てませんでした。。。)。
瞬発力+記憶力が重要。
デザインがきれい

じゃあ、家族の人気は?

ラビリンス、カタン、モノポリーあたりが人気です。ゲーム性もありますが、デザインとしてもきれいなものが多かったです。

テレビゲームも面白いですが、ワイワイ喋りながらボードゲームをやるのも楽しかったです。今回紹介したボードゲームはどれもある程度ルールを理解するところから始めないといけないですが、理解力や説明力なども必要になってくるので色んな楽しみがあるかなと思います。

実践Rust入門はじめました

Fri, 31 Jan 2020 21:58:12 +0900

実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。

実践Rust入門[言語仕様から開発手法まで] | κeen, 河野達也, 小松礼人 |本 | 通販 | Amazon

経緯

もともとは、言語処理100本ノックはじめました(Rust)という感じで、触っていたのですが、場当たり的にやってても時間を持っていかれるだけだなということに気づいたのが最初です。

今年の目標は、覚えられなので、ちょっとずつでもアウトプットしていこうってのもあり、読書記録をつけつつ、読んでいこうかなぁと。

どこまで読んだ?

2章の2-2-5までです。前回、Rustの環境はセットアップしていたのですが、新PCに切り替わったので、rustupからはじめました。

rustup

rustupではデフォルト設定のままではなく、PATH変数の書き換えだけはしない形でインストールを行いました。

PATH変数は.zshrcファイルで変更したかったためです(rustupコマンドに変更して貰う場合は.profileなどのファイルが変更されそうだったため)。

インストールが終わったあとに.zshrcに以下の行を追加しました。

### For Rust env
source $HOME/.cargo/env

疑問点

ここまで読んだ疑問点です。

cargo new helloしたあとにmain.rsに以下のmain()関数が出来上がっている!?

fn main() {
    println!("Hello, world!");
}

驚きましたが、cargo new hogeってやっても、おなじmain.rsができてました。デフォルトで出来上がるんですね。どんな超能力!?と思ってしまいましたw

cargo new helloして出来上がったCargo.tomlに著者名が入力されていた。

authors = ["Jun Ohtani <メアド>"]

なんで?と思いました。まだ解明してないです。本を読んでいけばわかるかな?

予想:gitの設定(~/.gitconfig)に氏名とメアドが設定されているので、これを利用しているのかな?

フリーランスはじめました(仮)

Fri, 31 Jan 2020 20:37:39 +0900

12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。

結論

実際にはフリーランスとして働き始めてます。検索周りをお手伝いするお仕事を。読解いとこあれば所属するつもりでもいるし。
— Jun Ohtani (@johtani) January 27, 2020

フリーランスとして最初の仕事はElasticsearchではなく、Azure Cognitive Searchの支援だったりします。Esで困ってる方の手伝いもしますので、興味ある方はDMください。
— Jun Ohtani (@johtani) January 31, 2020

2020年1月24日が、正式なElasticの退職日でした(有給休暇消化してた)。で、現在のステータスはこのツイートです。

現在の心境

どこかに就職してガッツリ検索もやりたいし、いろんな会社の検索やElastic Stackに関するお手伝いをするのにも興味があるし、どちらにも興味がある状況です。まぁ、検索に興味が尽きないというのだけは決まってますかね。

悩んでいるところに、幸いにもAzure Search周りで手伝ってほしいという話が舞い込んできたので、フリーランスとしてお手伝いをさせていただいてます(現時点で、半稼働で、が3月末まで)。

Elastic Stackなどの知見もあるのでのお手伝いをするというのもありかなぁと。お仕事発注してもいいな?という方があれば、TwitterのDMなど、連絡をいただければと。

現在の状況でした。

副業ができる会社に就職するのがどっちもできていいのかも?

ブログ移行日記(その4) - 検索機能(Algolia)の導入

Tue, 28 Jan 2020 13:40:04 +0900

ブログ移行日記(その4)です。その他の記事はこちら。

前回までで、なんとなく移行は終わってます。今回はテーマで使えるようになっているブログの検索機能の導入の話です。

検索サービスはAlgoliaを利用します。 OctopressのころはElastic社のサービスであるElastic Site Searchの機能を利用して、クローリングしてから検索できるようにしていましたが、Hugoで導入できるモジュール?があったので、今回からこちらに移行しました。

参考記事

Algoliaとは?

検索のas-a-serviceをやっている会社です。Wikipediaによると本社はサンフランシスコにあるみたいですね(フランスの会社のイメージでした。起業された方がフランス出身だからかなぁ?)。クラウドで検索インデックスを保持でき、API経由で検索したり登録したりできる感じのサービスです。内部で使われているのはOSSではない独自の検索エンジンです。

クラウドで提供されているサービスなのでサクッと検索を使い始めることができるのがいい点ですね。また、小さな非商用のプロジェクトにフリーで利用できるプランも提供されているようです(2020年1月現在)。

Algoliaのサービス登録からインデックス作成

私が利用しているテーマで設定する方法の記載があったので手順の通りにやってみました。大きく2つの作業(Algolia側とHugo側)が必要です。まずは、Algoliaで必要な作業から。作業の流れだけ記載しておきます。詳細は「Static site search with Hugo + Algolia」の3)を確認してください。

Algoliaのサインアップ(すでにアカウントがあれば不要)
New Applicationの作成(名前とプランの指定)
リージョンの指定
インデックス名の指定
APIキーを確認

です。これで、Algolia側の準備は完了です。

今回は関係ないですが、Algoliaの管理画面で、利用状況(データ登録などの操作回数、クエリの回数、インデックスに保存されているレコード数)の確認が可能です。ほかにも有料プランを利用するとAnalyticsなどもできるようです。

Hugo側で必要な設定

今度はHugo側です。Hugoのサイトのディレクトリに移動してからの作業です。

仕組みとしては、

Hugoのoutput機能でAlgolia向けのJSONファイルを生成する
Node.jsのライブラリを使用してAlgoliaに1.で生成したJSONを登録、更新する
検索画面の作成

という流れになります。ですので、作業としては以下のとおりです。

Output出力の設定(すでにテーマ側で設定されているので、特に作業は必要なし)
npm環境の構築(Hugoのconfig.tomlと同じディレクトリ階層)
1. Node.jsのインストール(必要であれば)
2. npm環境の初期化
3. npmでatomic-algoliaのインストール
4. atomic-algolia向けの設定(登録のためのAPI関連の設定)
5. Algolia向けJSONの出力設定
検索関連の設定
1. content/search/placeholder.mdの作成
2. 検索用のAPIキーなどを設定

npm関連の作業

以下、npm関連の作業です。

Node.jsのインストール(必要であれば)
- 割愛します。環境に合わせてインストールしてください。私はnvm経由でインストールしています。
npm環境の初期化
- Hugoのディレクトリでnvm initを実行
npmでatomic-algoliaのインストール
- Hugoのディレクトリでnpm install atomic-algolia --save
atomic-algolia向けの設定(登録のためのAPI関連の設定)
- Hugoのディレクトリに.envファイルを作成し、以下を設定します。
Algolia向けJSONの出力設定
- 特に変更なし(config.tomlに少し設定があります)。

ALGOLIA_APP_ID=AlgoliaのApplication ID
ALGOLIA_ADMIN_KEY=AlgoliaのAdmin API Key
ALGOLIA_INDEX_NAME=先程作ったインデックス名
ALGOLIA_INDEX_FILE=public/algolia.json

最後のALGOLIA_INDEX_FILEは固定文字列でいいと思います。 hugoコマンドを実行するとpublicディレクトリ配下にalgolia.jsonというファイルが生成され、Algolia登録用のJSONが出力されています。

余談 : algolia.jsonの出力の設定は、config.tomlに記載があります。また、JSONファイルのテンプレート自体はthemes/hugo-theme-cleanwhite/layouts/_default/list.algolia.jsonにあります。Algoliaに登録するデータの構造など変更をする場合はこのテンプレートをカスタマイズすれば良さそうです。

検索関連の設定

実際に検索の画面を表示するために、検索用の画面と、検索用のAPIの設定が必要です。

content/search/placeholder.mdの作成
- /search/が検索用のページになります。空のファイルです。実際にはJavaScriptが検索用の窓を表示したりしてくれます(これが必要な理由がまだ不明だなぁ)。
検索用のAPIキーなどを設定
- 検索のためのAPIキーなどの設定が必要となります。テーマ作者の方のサンプルのconfig.tomlにパラメータは用意されています。

以下の値を設定します。

  algolia_search = true
  algolia_appId = "AlgoliaのApplication ID"
  algolia_indexName = "作成したインデックス名"
  algolia_apiKey = "AlgoliaのSearch-Only API Key"

以上でAlgolia関連の設定などの作業が終了です。

Algoliaへのデータ登録方法

最後に、実際にデータを登録する必要があります。手順は、以下のとおりです。

hugoコマンドの実行(htmlと一緒に登録データのalgolia.jsonを生成)
npm run algoliaコマンドの実行(atomic-algoliaを利用してAlgoliaにデータを登録)

設定などが問題なければ、Algoliaの管理画面で登録ができているはずです。実際にブログのデプロイにはdeploy.shというファイルをこちらを元に作成して使っています。このなかで、hugoコマンド実行後にnpm run algoliaを実行するようにしいます。

今後の課題

Hugoで生成された記事はそれぞれのブログポスト以外に、タグごとのページも生成されています。こちらも実はAlgoliaのインデックスに登録されていて、タグを入力すると、タグ名のリンクが出てきます。

こちらはelasticsearchで検索したときの検索結果です。1件目はタグページです。

これらのページはAlgoliaに登録しないようにするのが良さそうかな?と考えているところです(考えてるだけ)。

2020/01/29更新

list.algolia.jsonを編集して、記事だけをインデックスするように修正しました。テーマに存在するlayouts/_default/list.algolia.jsonを、自分のところにコピーし、次のように変更しました。if文を1行追加して、postという種類のものだけを出力するようにしました。

{{/* Generates a valid Algolia search index */}}
{{- $.Scratch.Add "index" slice -}}
{{- $section := $.Site.GetPage "section" .Section }}
{{- range .Site.AllPages -}}
  {{- if or (and (.IsDescendant $section) (and (not .Draft) (not .Params.private))) $section.IsHome -}}
    {{- if (and (eq .Section "post") (ne .URL "/post/")) -}}
      {{- $.Scratch.Add "index" (dict "objectID" .UniqueID "date" .Date.UTC.Unix "description" .Description "dir" .Dir "expirydate" .ExpiryDate.UTC.Unix "fuzzywordcount" .FuzzyWordCount "keywords" .Keywords "kind" .Kind "lang" .Lang "lastmod" .Lastmod.UTC.Unix "permalink" .Permalink "publishdate" .PublishDate "readingtime" .ReadingTime "relpermalink" .RelPermalink "html" .Params.Description "title" .Title "type" .Type "url" .URL "weight" .Weight "wordcount" .WordCount "section" .Section "tags" .Params.Tags "categories" .Params.Categories "author" .Params.authors "content" .Params.Description "excerpt_html" .Params.Description "excerpt_text" .Params.Description "summary" .Summary)}}
    {{- end -}}
  {{- end -}}
{{- end -}}
{{- $.Scratch.Get "index" | jsonify -}}

まとめ

これで、ブログ内記事検索ができるようになります。 Algoliaは個人の非商用利用の場合、フリープランが用意されているのがありがたいですね。まだ、Hugoと連携しただけで、Algolia自体でどんな機能があって、どんなことができそうかといったところは調べていませんが、簡単に利用できるのはとても助かります。

まぁ、個人ブログの検索機能ってそんなに使う人はいないんですが、自分としては便利かなぁと。

ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)

Fri, 24 Jan 2020 17:04:41 +0900

ブログ移行日記(その3)です。その他の記事はこちら。

今回は、Hugoの設定とテーマの一部変更した点について記載します。

設定ファイル(config.toml)

Hugoの設定ファイルはconfig.tomlになります。hogo new siteコマンドで生成したディレクトリの中にデフォルトで含まれていますが、こちらではなく、テーマの作者が用意してくれたconfig.tomlを元に変更を加えました。

ちなみにテーマの作者の方が設定とコンテンツを含めたサンプルも公開してくれています。設定やディレクトリの構成はこちらを参考にしました。

設定ファイルで変更した項目は以下のとおりです。

サイトのタイトルや説明など

特記することはありません。好きなように変えました。

baseurl
title
SEOTitle
description
keyword
slogan
sidebar_about_descrption

画像関連(ヘッダーや著者近影)

画像の置き場はstatic/images/ディレクトリですが、設定ファイルには images/から設定します。

header_image : ブログのヘッダー背景
sidebar_avatar : 著者近影

言語周り(特に多言語対応する予定は無いのですが)

languageCode = “ja”
defaultContentLanguage = “ja”

オフにした機能、削除した項目

freands = false
bookmarks = false

上記の設定変更以外に、[[params.bookmark_link]]や[[params.friend_link]]も削除。

中国のサービスや、特化した設定など。

Baidu Analytics関連
Disqus proxy関連
Reward(wechat pay & alipay関連)

params.social関連

rss = true
twitter
linkedin
github

ほかはすべてコメントアウト。

外部サービス関連

disqusShortname : Disqusのショートネーム
googleAnalytics : Gooogle AnalyticsのトラッキングID
algolia関連 : 別のブログ記事として、設定方法などを書きます。

追加した設定(昨日のブログで説明済み)

Octopressと同じ形のパーマリンク

[permalinks]
  post = "/blog/:year/:month/:day/:slug"

Markdownファイル中のHTMLタグ表示

[markup.goldmark.renderer]
  unsafe = true

以上が設定ファイル関連です。

テーマの変更点

テーマそのままでは問題があったり、独自に変更したいという点があったので、いくつか変更をしています。

フォントの変更

そのままテーマを適用するだけでうまく行けばよかったのですが、フォントの問題が発生しました。テーマの作者の方が中国の方だから?かどうかはわかりませんが、デフォルトのままだと中華フォントになってしまいました。

あー、中華フォントだな。 pic.twitter.com/OvHpY4LSp1
— Jun Ohtani (@johtani) January 16, 2020

config.tomlにcustom_cssという設定があり、こちらで指定したCSSのファイルがテーマのlayouts/partials/head.htmlから読み込まれる仕組みがあるようなので、フォントに関するCSSをこの機能を使用して指定するようにしました。

config.tomlの設定は次のとおりです(リスト)になっているので、複数のファイルに分割して、読み込ませることも可能なのかな?。

custom_css = ["css/custom-font.css"]

cssファイルについては、static/css/custom-font.cssというファイルを作成し、次のような記載になっています。フォントの指定と右側サイドバーの自己紹介の部分の文字色を変更するためのものです。

body, h1, h2, h3, h4, h5, h6, .navbar-custom { 
    font-family: Helvetica,"Sawarabi Gothic",Meiryo,"メイリオ","Hiragino Kaku Gothic ProN", "ヒラギノ角ゴ ProN",YuGothic,"游ゴシック",Arial,sans-serif; 
}
.sidebar-container {
    color: #404040;
    font-size: 14px;
}

faviconの変更

テーマにfavicon.icoが含まれていたのですが、せっかくなので独自のものに変えてみようかと。ただ、残念ながら、こちらはパスおよびファイル名がlayouts/partials/head.htmlに直書きされていました。

画像はimages配下にと思っていたのですが、このパスだけを変更するためにhead.htmlを自分の配下にコピーしてカスタマイズするのもどうかと思った(テーマに変更やバグ修正が入るたびに手動でコピーするのはなぁと思った)ので、static/img/favicon.icoファイルを作成しました。

テーマよりもHugoのプロジェクトにあるファイルを優先するようなので、ファイルだけをプロジェクトに作成しました。

記事一覧のテンプレート

記事の一覧で表示される、作成者と作成日時が英語表記でかつ、冗長な感じがしたので、スッキリさせるために、layouts/partials/post_list.htmlをテーマからコピーして、次のように変更しました。

元の形式は : Posted by author Monday, January 2, 2006
現在の形式 : 2006-01-02 by author

記事のテンプレート

今回採用したテーマでは、記事の先頭に記事のセクションを元に目次を生成してくれるものでした。

目次をコンテンツから自動で作ってくれるの便利だな。 pic.twitter.com/9bU3sLnUrm
— Jun Ohtani (@johtani) January 16, 2020

とても便利です。ただ、表示が「TOC」なんです。英語でしかも「ToC」という表記ならまだ気にならなかったかもですが、大文字だと流石に気になったので、プロジェクトのlayouts/_default/single.htmlにコピーして「目次」という日本語に書き換えました。このHTMLにテーマで修正が入った場合はどうしようかなぁ。。。というのが目下の悩みです。。。

Archetypeテンプレートの追加

最後は新規記事を書くときに生成されるMarkdownのメタデータの追加です。 HugoにはArchetypesというのが存在します。

Hugoではhugo new 記事としたときに、記事の種類(content/ディレクトリ名=記事のタイプ)によって、作成するmarkdownファイルをテンプレートから生成する機能があります。この生成時に使われるのがarchetypesというディレクトリにあるファイルです。

私のブログサイトでは、今のところcontent/postというブログの記事だけを書く予定ですので、archetypes/post.mdというファイルを作って以下のようなメタデータをhugo newしたときに自動で生成するようにしました(テーマにあったpost.mdファイルの代わり)。

---
layout: post
title: "{{ replace .Name "-" " " | title }}"
slug: "{{ substr .Name 11 }}"
author: johtani
date: {{ .Date }}
comments: true
tags: []
draft: true
---

タイトルはファイル名のハイフンを空白に変換したもの(実際にはファイル名は英語にしているので、使いませんが。。。)
slugはファイル名の先頭からYYYY-MM-DD-という11文字を除いたもの。これは、OctopressのURLに合わせるために使用するURLの一部の文字列です。
author: johtani : 著者は私だけだから固定文字列
comments: true : ブログ記事にはDisqusのコメント機能を利用
tags: [] : 各内容によってタグを付けるが、生成時には空
draft: true : 明示的にこの行を消すまではドラフト記事としたいため

という感じです。ほかにどのよなメタデータがあるのかまではまだ調べていないので、今後また適宜変更していくと思います。

まとめ

Hugoの設定や、テーマそのままではなく独自の変更を加えた部分を思い出して書き出してみました。

これで、Algoliaに関する部分以外はだいたい思い出して書いたと思います。次は、Algoliaの使い方と設定について書き残す予定です。

ブログ移行日記(その2) - Markdownファイルの変換

Thu, 23 Jan 2020 19:31:54 +0900

その他の記事はこちら

ブログ移行日記(その2)です。前回はHugoとは?というのと、自分が選んだテーマについて記載しました。本家の手順などを参考にすると、Hugoにテーマを適用し、でHTMLを生成して、表示するところまでできるはずです。

今回は、OctopressのmarkdownファイルをHugo用に変換する方法について紹介します。お手製ですが、Pythonスクリプトを作ったので、そちらも合わせて簡単に紹介する予定です。

参考ブログ

「Octopress Hugo 移行」でググるといくつか出てきます。先人の知恵ありがたいですね。ということで、私はこちらの2つのブログを参考にさせていただきました。ありがとうございます。

画像のコピー

画像はそのまま上記参考ブログを元にsource/imagesからstatic/imagesにコピーしました。特にディレクトリ構造の変更とかもしませんでした。

コンテンツのコピー

こちらは、コピーのタイミングでいくつか変換などの処理を行いました。ファイルの変換にはPythonのスクリプトを書きました。自分向けの移行ツールなんで、ディレクトリ名とか引数にすらしてないです。。。

参考ブログと同様の変換

メタデータの日付変換
categoriesをtagsに変換
画像タグの変換
- タイトル、画像のサイズなどに合わせていくつか分岐があります。

参考ブログとは異なる変換、変更

コードブロックは無変換
- 0.60.0からCode Fencesに対応したみたいなので不要でした。
ディレクトリ構造の変更
- ファイルを年ごとのディレクトリに格納(これまでは、全てのファイルが同一ディレクトリにあった)
拡張子の変更 (.markdown -> .md)
メタデータにauthorの追加(自分しか書かないんですけどね)

URLをOctopressに合わせる

Google検索からの流入もあり、これまでのURLに変更はかけたくないなと。こちらも参考ブログに記載があるので、そのまま参考にさせていただきました。

slugについては、移行ツールでファイル名を元に追加する処理を書きました。

HTMLを含んだMarkdownの対応

TweetやAmazonのアフィリエイトのリンクがHTMLタグでいくつかの記事に含まれており、デフォルトの設定だと表示されません。 config.tomlファイルに以下の設定を追記することで、出力されるようになりました。

[markup.goldmark.renderer]
  unsafe = true

名前がunsafeなので、ちょっと気になりますが。。。すべての記事を表示してチェックしてみたわけではないので、おかしな記事を見つけた方は連絡をいただけると助かります。

まとめ

OctopressのファイルをHugo用にコピーや変換した方法を思い出しながら書いてみました。基本的には参考ブログに上げた2つのブログを真似したものになります。

次は、利用したテーマのサンプル設定を元に、自分用に変更した点などについて書き残しておこうかな?

ブログ移行日記(その1) - Hugoとテーマ

Wed, 22 Jan 2020 11:23:34 +0900

その他の記事はこちら

起因

いつものツイートから始まる私の行動です。

ってことで、Hugo勧められたし、テーマが豊富だしということで、乗り換えた次第です。

(元)同僚に教えてもらった記事を見てる。Gatsbyも気になるんだけど、デザインセンスないし、テーマが豊富なのがいいなぁ。/ Comparison of Gatsby vs Jekyll vs Hugo | GatsbyJS - https://t.co/yUbKiBmtMS
— Jun Ohtani (@johtani) January 9, 2020

一応Gatsbyのサイトにあった比較も見たのですが、テーマの豊富さが勝ちました。デザインを自分でやれるほどではないので。

理由

乗り換えるに至ったのは主に2つの理由です。

Octopressが更新されていない
ページが増えてきてサイトの生成に時間がかかる

前に使っていたOctopressもJekyllというものがベースになっていました。 Jekyllは今でも更新があるのですが、Octopressが更新されなくなってしまったのと、Rubyがベースになっているため?なのかはわかりませんが、ブログのページ数が増えてきて、サイトのビルドに時間がかかってくるようになりました。

結果

まだ、改良点があるかもですが、とりあえず公開できる感じになったと思ったんで切り替えました。

前のブログはこんな感じで、

移行後はこんな感じです。

Hugoとは?

公式サイト

こちらにあるように、Go言語で実装されているウェブサイト構築フレームワークです。 Go言語で実装されているのもあり、インストールが簡単でした。 Macを使っていますが、Homebrewでインストールができてしまいます。他の方法もあるようでしたが、Emacsをインストールするのにbrewを入れているので、brewでインストールしました。

使い方は色んな人が書いてるし、公式ドキュメントを見ていただけばいいかな。

テーマとは?

Hugoのサイトにテーマの一覧があります。一応、個人のブログなので、それなりにデザインを入れつつ、他の人と違う感じにしたいなと。テーマ一覧をざっと眺めて良さそうなのをピックアップしたら、最終的にこちらのテーマになりました。

Clean White

それなりに更新されてますし、DisqusとSearch(Algolia)が使えるのでこのテーマに決めました。テーマのインストール方法などはGitHubのREADMEの「Quick Start」に記載があります。

私は、Hugo自体の設定などをGitHubで管理したかったので、git submoduleを利用して、次のような構成になりました。

hugo - main repository
├── archetypes
├── content
├── data
├── layouts
├── public - github.com/johtani/johtani.github.io
├── resources
├── static
└── themes
    └── hugo-theme-cleanwhite - github.com/zhaohuabing/hugo-theme-cleanwhite.git

hugo : hugo new siteコマンドで作成されたディレクトリです。このディレクトリでまずgit initしました(このリポジトリはプライベートで管理してます)。
themes/hugo-theme-cleanwhite : テーマのQuick Startにあるgit submodule addコマンドでサブモジュールとしてテーマをインストールしました。
public : hugoが生成するHTMLのトップのディレクトリがこちらです。私はGitHub pagesを利用してブログを公開しているので、git submodule addでjohtani.github.ioをサブモジュールにしました。

Hugoで生成したHTMLなどをGitHub pagesで公開するときの手順などはHugoのドキュメントに記載がありました。

まとめ

Hugoに移行した理由や、Hugoとテーマの簡単な紹介でした。テーマが豊富なのはデザイン力(りょく)がない身としてはありがたいですよね。次はOctopressのmarkdownファイルをHugo用に変換したり、それに関する設定周りの話を書く予定です。

About

Thu, 16 Jan 2020 18:33:15 +0900

フリーランスの検索エンジニア/コンサルタント。元Elastic社のDeveloper Advocate。

ElasticsearchやOpenSearch、Weaviateなど検索サーバーや、検索サービスに興味があり、検索技術勉強会の運営などを行っている。

Talks

Books

OctopressからHugoへ移行中(まだ途中)

Thu, 16 Jan 2020 18:23:37 +0900

5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、ほかのプラットフォームを使用するように変更しました。

とりあえず、今回の移行で参考にした記事とかURLをリストアップしてみました。詳細についてはまた明日以降で。

参考記事
- 移行関連 : https://iriya-ufo.net/blog/2018/12/27/octopress-to-hugo/#github-pages-
- 移行関連 : https://gam0022.net/blog/2016/09/25/migrated-from-octopress-to-hugo/
- Hugo自体の日本語紹介記事 : https://knowledge.sakura.ad.jp/22908/
Hugo概要
- https://gohugo.io/
テーマ
- 一覧 : https://themes.gohugo.io/
- 利用したテーマ : https://github.com/zhaohuabing/hugo-theme-cleanwhite
データ移行
- 作ったスクリプト : https://github.com/johtani/from-octopress-to-hugo
favicon
- 作ったサイト : http://emblemmatic.org/markmaker/#/
Algoliaセッティング
- 参考 : https://blog.uni-3.app/2019/01/02/hugo-algolia-search/
GitHub Pagesでの運用
- https://gohugo.io/hosting-and-deployment/hosting-on-github/#types-of-github-pages

残タスク

Amazonのアフィリンクをきれいに表示するlayoutか何かを用意する?

今年の振り返りと来年の抱負（2019）

Tue, 31 Dec 2019 12:59:03 +0900

今年も振り返りブログ書いてます。Sasukeがついてる。

振り返り（2018年に書いた抱負から）

まずは去年の抱負を元に。

TOEIC

受けました。

お。TOEICの点上がってた（まだまだだけど。。。）
— Jun Ohtani (@johtani) October 21, 2019

無事、上がってました。テストの点数を上げるのが目的ではなく、今の実力がどんな感じかというのを確認するために受けました。前回までが低かったのもあるんですが。また、数年後に受けてみるのかな?

CfP見つけて応募 & いろんな場所に顔を出す

色んな所には顔を出しました。 CfPはそれほど出せていなく、とちぎRubyとDevRelJPで喋った程度かと。 12月に最終出社日を迎えたので、今後は顔を出したりCfP見つけて応募も、一旦休憩に入る予定です。

もっとブログ！

12月に入ってから、一気に増えてますねw Elasticでは結局それほどかけなかったなぁ。

Rustの継続

こっちは、書籍も買ったのに手がついてないです。来年に書籍を読みながら再入門する予定です。

開発の継続

一応ほそぼそと続けてますが、メンテナンスですね。 Analyzer向けのKibanaのプラグインのバージョンアップにだけ対応していたり。年初にReact化には着手しました。あとは、Luceneにちょっとしたパッチ(Lukeの画面とKuromojiのUniDic対応)を送った感じかな。もっとLucene周りやりたいかな。

日本でエンジニア獲得!

トレーナーやエンジニアが入社してくれました! が、私が退職してしまいますが。。。私自体が次のステップに移らないとなぁと。 Elasticに興味がある人いたら、中の人を紹介できるので声をかけてください!

振り返り(今年あったできごと)

さて、ここからは今年の出来事を。

検索技術勉強会発足
勉強会運営座談会
初フロリダ
初カナダ&初ナイアガラの滝
退職(予定)

検索技術勉強会ってのをはじめました(はじめましたブログはこちら)。やっぱり検索の話を聞いたり考えたりするのが好きなので、もっといろんな話を聞く機会がほしいなぁと。ツイートすると何人かの知り合いが手を上げてくれたので、初めて見たのが2月でした。所属会社もあったので、自分が全面に出ない形で運営に協力するという形式でやっています。なんだかんだでもう4回も開催できています。スピーカーへの声掛けなど、複数人で運営するとそのあたりが多様性が出るし、楽になるのですごくいいなぁと。来年も2月か3月にやりたいねと話をしているところです。興味のある方は、ぜひスピーカーを!

で、その流れで、他の勉強会の運営ってみんなどうしてるんだろう? という疑問も出てきたので、勉強会運営座談会なるものもやってみました。少人数で集まって、勉強会の運営ってどんなやり方してます?どんなことに困ってます?みたいなのを共有してみました。自分自身がそれほど、ほかの勉強会の運営に顔を出してたわけでもなく、やり方をみんなはどうやって共有してるのかなぁ?というのが気になったので。思った以上に属人化してるのかもなぁというのが感想でした。ドタバタしてたので、あれからやってませんが、共有する勉強会みたいなのも面白いのかも?

今年も2回ほどElasticの社内イベントで海外に行かせてもらいました。 5月にフロリダと11月にトロントでした。フロリダでは、NASAにも行けたし、トロントでは足を伸ばしてナイアガラの滝を見に行くなどもしてみました。こういう機会が定期的にあるのは、いいですよねぇ。

最後は、退職イベントですね。5年5ヶ月勤めたElasticでの仕事が、12/6で最終出社日でした。実際の退職日は1/24となっています(現在有給休暇消化中)。長かったような、短かったような。日本で1人目で入社してさまざまなことをやらせてもらい、本当に色んな経験ができました。英語も上達したし。ただ、外にいることでできることがありそうだなと感じたこともあってのこの決断でした。

最終出社日以降、色んな人とランチさせてもらったりしています。次に何をやろうかな?ってのんびり考えながら休んでいるところなので。やっぱり、検索周りのことをやりたいなぁというのが念頭にあるので、そのあたりで模索中という感じです。が、せっかくの機会なので、少しのんびりしようかなとも思ってます。なので、プラモデルの作成や配達業(デス・ストランディング)をやってみたり、16インチMacbookのセットアップしながらブログ書いたりしています。年明けに入ったら、プログラミングもちょっとやりたいな。

あとこの場を借りて、ブログの欲しい物リストのものを送っていただいた皆様に感謝を述べさせていただきます。本当にありがとうございました!この感謝はまた何かの機会にでも!

来年の抱負

ということで、来年の抱負です。

職につく
ブログプラットフォームの移行
プログラミング
Rust再入門
検索の勉強
検索技術勉強会の継続

まぁ、まずは職につかないとですね。どこかに在籍しつつ、副業で検索周りのこととかやるのもありかもなぁと考えたりしています(プラモデルつくりながらw)。

ブログのプラットフォームをOctopressからHugoあたりに移行しようかなと思ってます。Octopress自体がもう開発がされてないようですし。Hugoだとテンプレート?テーマ?がそれなりにありそうなので良さそうかなぁと。移行プログラムも書かないとかな。新しいものを調べるのって楽しいですよね。

プログラミングも復活させたいなと。どうしてもこれまでは、しゃべるのをメインにしていたので、後回しにしてしまっていたのもあります。まぁ、向いてないのかもと思ったりもしますが、下手の横好きなりに少しずつでも何かを改善したり作ったりしたいなと。勉強会の運営周りですこし楽をするためのプログラム書いたりもしているので、この辺もブログに書こうかな?

RustはTantivyというプロダクトも出てきているし、勉強しようと思って、自転車本を買いつつ、Kindleの肥やしにしているので、手を動かそうとおもいます。ブログ書いてサボった場合の可視化しないとなw

検索の勉強もやりたいなと。これまではElasticsearchに注力していましたが、ほかのプロダクトやサービスも調べてみたいなと。教えを請いに皆さんのところにお邪魔するかもしれないので、そのときは優しくしてください。

今年始めた検索技術勉強会を今後も継続できるようにしたいなと。で、運営周りを楽にできるような仕組みをもう少し導入できればなぁと考えていきたいなと思います。

さて、嵐の曲も始まったし終わりです。

今年も様々な方々に助けていただきました。また、最終出社日以降にランチを一緒にさせていただいたり、遊びに行かせていただいたりとありがとうございました。年明けもひましてるので、ぜひランチしましょうw

来年はなにやってるんだろうなぁ? 今後も皆さんよろしくおねがいします!!

macOS標準のターミナルのウィンドウグループが便利

Mon, 23 Dec 2019 10:14:39 +0900

このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。

普段、macOSの標準ターミナルを使ってます。で、ターミナルを使うシーンは次のような感じです。

ブログのデプロイ（参考：Octopress環境のDockerイメージ化）
ElasticsearchとKibanaの動作確認
1. Elasticsearchの起動用ターミナル
2. Kibanaの起動用ターミナル
プラグインの開発(elasticsearch-ingest-csv と analyze_api_ui)
1. elasticsearchのリポジトリ
2. kibanaのリポジトリ
3. ingest-csvのリポジトリ
4. analyze_api_uiのリポジトリ

上記のように1.以外については複数のターミナルをそれぞれのディレクトリで起動して使っています。これらの3つのパターンのときに、毎回ターミナル(シーンによっては複数のウィンドウ)を開いて、ディレクトリに移動って大変だなと。

ウィンドウグループって？

そこで、ターミナルに便利な機能がないのかな?と思い、メニューを見ていたところ「ウィンドウグループ」というのがあったので調べて、現在の使い方に至っています。

ウィンドウグループの使い方の説明はこちらです。

使い方にあるようにウィンドウの場所、設定、タブなどを保存できます。そして、「ウィンドウグループを開く」というメニューから保存しておいたグループを開くと、簡単に作業環境が再現可能になります。

開くときのメニューはこんな感じです。

作り方

ウィンドウグループの使い方に載ってます。まずは、保存したいターミナルを開いて、開いたときに移動していたいディレクトリに移動します。複数のタブやウィンドウを開いた状態にしたい場合は、複数ターミナルを起動して、それぞれ移動したいディレクトリに移動しておきます。

グループとしてまとめたいウィンドウが起動できたら、あとは、「ウィンドウ」メニューの「ウィンドウをグループとして保存」を選択します。

これだけです。あとは、使いたくなったときに開くだけです。簡単ですよね?

作るときの注意点としては、複数のウィンドウグループを作りたいときは、それぞれグループごとに作成しては、個別にやる必要があります。現在開いているターミナルのうち、あれとこれをウィンドウにしたいというやり方はできないので、そこだけ注意点です。環境ごとにプロファイル(バックグラウンドの色やテーマ)を覚えさせることができるので、1.のシーンだとIceberg、2.のシーンではBasic、3.のシーンではHomevrewで設定していたりします。 (ただ、Preztoのテーマをagnosterにしてしまったので、Basicだとプロンプトが見にくくてしょうがないのですが。。。)

設定はどんな感じ？？

ウィンドウグループの管理については、ターミナルの「環境設定」に管理用の画面があります。

この画面でいらないグループを削除したり、設定のエクスポート/インポートも可能です。

私の使い方

3つの利用シーンは説明しました。すべてのウィンドウグループを変更するたびにインポート/エクスポートしてます。上記1.と3.のユースケースはほぼ変更がないので、エクスポートしたものを移植用に管理していますが、2.のユースケースについては、頻繁に更新しています(ElasticsearchとKibanaのバージョンをアップしないといけないので)。

このとき、MacのGUIで毎回設定をしているわけではありません。エクスポートしたファイルは、.terminalという名のXMLファイルになっています。

その中に、次のようなパスが記述されています。このバージョン番号の部分をアップデートのたびにemacsなどで変更し、ターミナルの管理画面で、削除してからインポートし直すだけで、バージョンアップに対応している感じです。


					<key>Tab Working Directory URL</key>
					<string>file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1/</string>
					<key>Tab Working Directory URL String</key>
					<string>file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1</string>

まとめ

ということで、標準ターミナルのウィンドウグループを使うと、よく開くディレクトリやウィンドウ、タブを覚えて置かせることができるので、それぞれの環境向けのターミナルを、好きなときに開くことができるようになります。私は、ウィンドウは1つで複数のタブをウィンドウグループという形で覚えさせておくことで、各シーンの切り替え、もしくは併用を閉じたり開いたりを簡単にできるようにしています。

他のターミナルソフトを使うと似たようなことが簡単にできたりするのかな? みなさんがどうやってこのような作業やってるのかな?ってのはちょっと気になるところです。

余談（いつものようにツイートとその反応）

ちなみに、みんなどんなターミナル環境なんだろう？と思いツイートしてみた結果はこちらです。 (コメントRTってうまいことひろえないのかなぁ？)

Mac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？
— Jun Ohtani (@johtani) December 11, 2019

Iterm2使ってtmux使って今はIterm2だなー

command2回押すだけでターミナル出すくせが抜けん https://t.co/P8o4M1HSoj
— GO☆ | TAFDATA (@_gogoponz) December 11, 2019

Alacritty + tmux やなー。標準はもう使ってない。 https://t.co/HI7hPCg3uo
— Ryo HIGASHIGAWA (@biwakonbu) December 11, 2019

標準です https://t.co/W27e2pcq3j
— shin higuchi @Acroquest (@shin0higuchi) December 11, 2019

Macを買って以来、ずっと結局標準ターミナル以外使っていない感じ。珍しかったのか。。 https://t.co/Zjz32SgjC6
— Kazuhiro Hara™ (@kara_d) December 11, 2019

homeshick導入

Wed, 18 Dec 2019 08:11:06 +0900

ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。

で、ツイートしたところ（こればっかりだなｗ）、homeshick(homesick)が便利だよとの情報を得たので使ってみました。

homesick、正確にいうとhomeshickを使ってます。悪くないです
— 🤓k.bigwheel🤓 (@k_bigwheel) December 10, 2019

使い方とか

実物はGitHubで公開されていました。

https://github.com/andsens/homeshick

何者かというと、ホームディレクトリにあるドットファイル(.zshrcなど)をgitコマンドで管理するのを楽にしてくれるシェルの関数群みたいです。インストールは至ってかんたんで、git cloneで持ってくるだけです。homeshickのリポジトリのREADMEに記載があります。

使い方はTutorialsにあります。

homeshick generate ほげほげで管理する単位（castle）を作ります。ほげほげが名称です。今回私はdotfilesにしました。
homeshick track ほげほげ .zshrcで管理したいファイルを指定します。すると、homeshickが対象のファイル（ここでは.zshrc）をcastleの保存先ディレクトリにコピーしてから、シンボリックリンクをホームディレクトリ上に作ってくれます。
homeshick cd ほげほげで、castleの実際のディレクトリに移動します。実態は.homeshick/repos/ほげほげです。
git remoteコマンドでcastleとGitHubの関連をつけて、あとは、普通にgitコマンドでコミットしたりすればOKです。

すごく簡単に導入できました。あとは、実際にtrackしたいファイルを追加していく感じです。現状は、.zshrc、.gitconfigあたりを管理しています。ついでに、homebrewでインストールしたものもbrew bundle dumpで出力して、homeshickで管理することで、brewでインストールしたものの管理もできそう（参考）。

ってことで、至極かんたんでした。すばらしい。

参考

zshへの移行

Tue, 17 Dec 2019 09:35:03 +0900

Macbook Proが新しくなり、OSがCatalinaになっちゃいました。これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げたところ、なんか色々と設定が動いてないな？と思ったら、zshがデフォルトに切り替わってました。

ということで、デフォルト変わったし、時間あるしzshってどんな感じなのか調べてみようと。

準備前（ツイート）

で、ツイートをしたところ、海外の方？より返信が来ました。

I have a series of posts explaining the transition: https://t.co/dz8QNjxxGf
— Scripting OS X (@scriptingosx) December 10, 2019

おもしろそうなので、ざっくりと読んでみました。zshを利用されているTwitterの知り合いの何人かからはzsh + oh-my-zshがいいよとコメント頂いてたんですが、

Moving to zsh

Catalinaからzshがデフォルトになるからと、手元の環境を変更するための話をブログにまとめてくれてます。

Moving to zsh

サラッと読んだので、いくつか抜粋すると

bashでいくつか今設定しているものがあるのでその説明
1. alias - ファイルをそれぞれの拡張子ごとにアプリを切り替えてる（openコマンドの利用例があって参考になりました）。
2. functions - manコマンドのときに新しいWindowひらいたりとか
3. shell settings - 大文字小文字関係なくファイル名をTabで候補を表示したり、historyをターミナル個別ではなく共有できるような設定にしたり
4. prompt - 現在のディレクトリがどこかとか表示したり
zshの設定ファイル群の説明
shellオプションの抜粋

といった感じでした（途中で読むのやめましたが。。。）

面白かったのは、Suffix Aliasesです。ファイル名だけをターミナルで指定すると、拡張子に応じて起動するコマンドを切り替えたりできると（結局まだ採用はしてないですがｗ）

結局？

結局、上記ブログを読んでいろんなオプションあるんだなぁ。と思ったのですが、手っ取り早く試すためにPreztoをインストールしました。以下のような構成になってます。

なるほど、これがzsh + prezto + powerline fontか。前までgit-promptを拾ってきてbashに組み込んでたけど、ブランチ表示されるし便利だな。 pic.twitter.com/Z2ArBgRZey
— Jun Ohtani (@johtani) December 12, 2019

Mac標準ターミナル
Iceberg プロファイル
Powerline font
Prezto
agnoster theme - prompt agnoster or ~/.zpreztorc の変更
.zshrcにいくつかaliasなどを追加。参考:gist
- Preztoのデフォルトでlessなどからエディタを立ち上げるとnanoが起動したので、vimに変更
- Preztoが作る設定と自分の設定を混ぜたくなかったので、.zshrcでinit.zshを呼び出し

になりました。フォントサイズだけはちょっと大きくしました（老眼ェ。。。）ターミナルの参考にさせていただいたブログは「preztoでzsh構築した時のメモ」です。

ターミナルソフト(余談？)

terminalも人によっては、色んなものを使ってたなと思いツイートしました。結構みなさん標準のterminalを使ってるみたいでした。ただ、私が聞いたこともないターミナルソフトもちらほらあったので、色々あるんだなぁと。

Mac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？
— Jun Ohtani (@johtani) December 11, 2019

Octopress環境のDockerイメージ化

Mon, 16 Dec 2019 10:01:01 +0900

最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。で、時間もあるのでこれまでほったらかしてきた、このブログの環境をちょっと変更しようかなと。

まずは、変更するにしても、Octopressのブログの環境自体は必要です。実際に、移行する前のこの記事自体も書いているわけですし。

ただ、今後なくなる環境をローカル環境にセットアップするのもどうかと思い、Docker環境にしてみました。

参考

“Octopress Docker image"でググって出てきたサイトを参考にしました。

参考ブログ：Octopress in a Docker Container

セットアップからDockerイメージのビルドまで

Docker for Mac自体もインストールしていなかったので、インストールしておきます。
参考ブログの方がGitHubのリポジトリにDockerfileをアップしてくれているので、手順に従い、cloneします。
1. cloneしたDockerfileの3行目にENV LC_ALL C.UTF-8を追加します（UTF-8でブログを書いており、previewした場合にエラーが出たため）
2. 参考ブログにある「Build the docker image」の手順に従い、Gemfile、.gitconfigをコピーしてイメージをビルドします。
参考ブログの「Rakefile」にあるように、自分のoctopress/RakefileのProcess.spawn(...)にアドレスを追加します（Dockerコンテナの外からアクセスできるように）
自分のoctopressにあるGemfile.lockを削除しました（ビルドしたイメージにはいるGemと一部バージョンが異なる記載のものがあったため）

ここまでで、

Docker run

実際にコンテナを実行するためのスクリプトを書きました（書いたと言っても参考ブログにある起動コマンドを叩いてるだけですが。。。）

launch-octopress-docker.shというファイル名で以下のコマンドを実行してるだけです。

!/bin/sh
docker run -p 4000:4000 --rm --volume /Users/johtani/projects/blog/octopress:/octopress --volume /Users/johtani/.ssh:/home/blogger/.ssh -ti blog/octopress /bin/bash

このシェルを起動すると、Dockerコンテナにbashで接続し、/octopressディレクトリにログインしています。あとは、いつものようにrake new_post["...."]で新規記事のテンプレートを作成したりすればOKです。

rake generate; rake previewと実行してからローカルのブラウザでhttp://localhost:4000に接続すればプレビューも可能。

ということで、このDockerファイルとかを持っておけば、他の環境でもかんたんにOctopressの環境が再現できそうです。先人の知恵有り難し。これで、クリーンなまま他のブログ環境に移行できそう。

追記(2019/12/17)

Docker環境でいくつか問題があったので、追記しておきます。

Docker for Macが再起動しない

Docker for MacがCatalina環境だと問題があるみたいでした。 CPUの数やメモリの数を変更してDockerを再起動したところ、ずっとStartingのまま。

解決方法としては、launchctlの設定に$PATHを追加するみたい。これで、問題なく起動するようになった気がする

sshの設定ファイルの問題

.ssh/configにMacのKeyChainを利用する設定を記載してるんですが、Ubuntu上だとこの設定のせいで、エラーが出てしまいます。 IgnoreUnknownという設定で、知らないオプションがあったら無視するという設定になる模様。ということで、Dockerコンテナ上でrake deployのときにエラーが出てたのが解消できました。

退職します

Fri, 06 Dec 2019 15:51:30 +0900

本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。

思い返せばもう5年と5ヶ月も前ですが、Elastic（当時はElasticsearchって社名だった）に参加しました。

社名も変わりましたし、プロダクトの数も増えたし、IPOもしました。初の外資＋スタートアップということもあり、ものすごくエキサイティングな5年半でした。 Elasticを離れはしますが、検索自体にはまだまだ興味があるので、LuceneやElasticsearchになにかしら関わる感じのことをする予定です。検索技術勉強会も今後もやっていきますし。

ただ、激動の5年半だったので、退職日までちょっとゆっくりしようと思っています。次にどんなことをするのかはまた、別の機会にでも。

おまけ

ということで、まぁお約束です。

ほしい物リストはこちら

Apache LuceneのKuromojiのUniDicビルド対応パッチについて

Wed, 04 Dec 2019 00:00:00 +0900

これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。

1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になってます。気軽に読んでくださいw。Advent Calendarつくらないの？と煽ったのもあり、穴を埋めようかなと。　

発端

ちょっと先ですがこういうのやります。実装寄りの話やOSS開発に興味がある方，きてください～ / Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編） https://t.co/NgEmUohoPo #kuromoji
— Tomoko Uchida (@moco_beta) September 6, 2019

「Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編）」という勉強会があり、参加したところ、UniDicの辞書のビルドがコケるという話を聞いたんで、ちょっとやってみるかと。

ちなみに、Kuromojiとは、Apache Luceneに入っている、日本語向けの形態素解析ライブラリです。IPAdicの辞書を内包しており、SolrやElasticsearchといった、Apache Luceneを利用している検索エンジンで手軽に使える形態素解析ライブラリになっています。が、対応している辞書がデフォルトだとIPAdicなのです。

問題点

LUCENE-4056というIssueが上がっています。

build.xmlには記載はないけど、辞書のビルダーは対応していそうな雰囲気を醸し出しているので、試してみたというのが発端？かと。で、実際に動かしてみると動かない点がありましたと。

また、Issueの会話で出ていたUniDicの辞書のライセンスの話もありました。ただ、UniDicがライセンスを変更したので、このあたりはクリアできそうかなと。

パッチ

ということで、動かしてみていくつか修正してパッチを作りました。

https://github.com/apache/lucene-solr/pull/935

最近のLuceneはGitHubでプルリク遅れるのが便利ですね。そんなに大したことはやってないです。以下の点が問題だったので直しています。

IPAdicとUniDicで語彙定義ファイルのCSVの形式（カラムの数）が異なる
unk.defのカラム数も異なる

あとは、辞書のダウンロードの部分やbuild.xmlでの処理を追加した形です。このプルリクを適用したlucene-solrのソースディレクトリを持ってきて、手元でjarをビルドすれば普通はIPAdicの辞書を内包したkuromojiのjarファイルが出来上がります。

lucene/analysis/kuromoji/build.xmlファイルを、このGistにあるように変更して、ant build-dictとやれば辞書のビルドが可能です。また、cd lucene/;ant jarとすれば、UniDicの辞書を内包したjarファイルもビルドできます(lucene/build/analysis/kuromojiの下にjarファイルができあがります)。

確認？

一応、パッチは動くのですが、パッチ自体はUniDicの辞書をビルドする仕組みはオフのままです。なので、テストをどうやろう？というところでやなんで止まっています。。。

ただ、実際に作ったパッチできちんとIPAdicとUniDicがそれぞれビルドできているかの確認はしないとなと。

ということで、2つのjarファイルを読み込んで、それぞれトークナイズして、その出力を表示するツールを作ってみました。

上記パッチを適用したlucene-solrのソースを持ってきて、IPAdicの辞書を内包したkuromojiのjarファイルと、UniDicの辞書を内包したjarファイルを用意し、ツールの支持に従って、ファイルをディレクトリに配置して、実行すれば以下のような出力がされるようになっています（とりあえず作ったものなので、Javaファイルにトークナイズしたいテキストを書かないといけないのですが）。

たとえば、「自転車と自動車の違いはなんでしょう？」という文字列を入力すると、以下のような出力になりました。

+++ ipadic ++++++++++++++
token[0] is [自転車]
token[1] is [と]
token[2] is [自動車]
token[3] is [の]
token[4] is [違い]
token[5] is [は]
token[6] is [なん]
token[7] is [でしょ]
token[8] is [う]
+++ unidic ++++++++++++++
token[0] is [自転]
token[1] is [車]
token[2] is [と]
token[3] is [自動]
token[4] is [車]
token[5] is [の]
token[6] is [違い]
token[7] is [は]
token[8] is [なん]
token[9] is [でしょう]

UniDicは[短単位]で語彙が扱われるため、「自転車」や「自動車」がそれぞれ「自転」「車」、「自動」「車」という形でトークナイズされていることがわかります。

どちらがより便利なのか？というのは用途によっても変わってくるかと思いますが、検索の転置インデックスとしては、より短い単語で区切られている方が、より多くの文書にヒットする可能性が高くなるので、便利な可能性が高いです。

まとめ

ということで、パッチを作ってみたものの、まだ取り込まれていない状況です。着地点をどうするかって話かなと思っています。興味があれば遊んでみていただければと。

将来的には、辞書をjarから切り離して別のディレクトリやjarとして使えるようにしようというIssueも作られています。こちらがすすめば、UniDicだけでなく、その他の辞書を切り替えながら使えるようになる日が来るのではないでしょうか？

2019年のElastic StackとElastic

Sun, 01 Dec 2019 00:00:00 +0900

Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。

まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。

Elastic Stack 6.6.0リリース(1月)

リリース記事はこちら

Elastic APMが6.6のリリースと同時にElastic CloudでAPM Serverが無料で利用できるようになったのが地味に便利でした。APMのデモをやるために、それまでは手元にAPM Serverの起動が必要だったので。。。

ユーザーの方たちにはIndex Lifecycle Management（インデックスライフサイクル管理：ILM）がリリースされたのが便利だったと思います。まだ、ベータでしたが、インデックスの世代管理を格段に便利にしてくれるツールになり、現在では必須アイテムとなっています。もう一つ、地味に便利なのは、KibanaからElasticsearchへの接続を複数指定できるようになった点かと思います。

Elatic Common Schemaのベータリリース(2月)

リリース記事はこちら

Elastic Stackではメトリック、APM、ログなど、様々なデータを一元的に可視化することができるという利点があります。ただ、一元的にデータを可視化、検索するためには異なるデータセットに統一されたフィールド名が欠かせません。そのための手段としてElasticが公開したのがElastic Common Schemaです。各種データの項目名、型などを共通化する仕様をGitHub上で公開しています。最近のBeatsのモジュールはこのElastic Common Schemaに則ってデータが定義されるようになってきています。これにより、ログからメトリックへ、APMからログデータへというシームレスな移動ができるようになっています。

Elastic Stack 6.7.0リリース(3月)

リリース記事はこちら

Elastic MapsやUptimeといった、これまでの可視化とは異なる便利なアプリが増え始めました。Mapsでは地図の表現が格段にアップしたので、コレまで以上に地理情報と合わせた可視化が楽しくなりました。

もちろん、基本的に必要な技術が着実にGAされていくのもElastic Stackの素晴らしい点です。

Index Lifecycle Management(ILM)がGA
Cross Cluster Replication(CCR)がGA
CanvasがGA
Logs & Infra UIがGA

Elastic Stack 7.0.0リリース(4月)

リリース記事はこちら

メジャーバージョンのリリースです。 KibanaのUIが刷新されたり、Elasticsearchのクラスター管理の機能が新規に構築されたり、様々な改善がこのリリースでも入っています。また、メジャーバージョンのリリースのタイミングが、さまざまな大きな仕様の変更や改善が入るタイミングでもあります。これまで以上にパフォーマンスが改善（Top-Nクエリ高速化など）されたり、新しい機能の追加（ナノ秒のサポート）されたりしました。

Elasticsearchのセキュリティの主要な機能が無料に(5月)

リリース記事はこちら

6.8.0および7.1.0のリリースはこの機能の無償提供となりました。結構衝撃的な話だったのではないかなぁと。これ以前は有償の機能だったセキュリティの以下の機能をElastic License配下で無料で提供する形に変わりました。まだ、ご存知でない方は、データの安全のためにもセキュリティ機能を利用することをおすすめします。

TLSによる通信暗号化
ユーザー作成と管理にファイルおよびネイティブのレルム認証を使用可能
クラスターAPIとインデックスに対するユーザーアクセスの管理にロールベースのアクセス制御を使用可能、またSpaces機能でKibanaのマルチテナンシーの安全性を向上

Elastic{ON}19開催(5月)

今年も東京で開催しました。ビデオなどはこちらで公開されています。 https://www.elastic.co/elasticon/tour/2019/tokyo

今回も偉そうにElatic Stackの新しくなった点を紹介するなどしてました。。。

Elastic Stack 7.2.0リリース(6月)

リリース記事はこちら

Elastic SIEMがベータリリースされたのがこのタイミングです。 2月の発表したElastic Common Schemaをフルに活用していると言ってもいいのがこの機能になります。まだ今後もどんどん改善が入るであろうきのうになります。

また、Elasticsearchをバックエンドにした検索ミドルウェアとして利用いただけるElastic App Searchのセルフマネージド版もこのタイミングでリリースされています。

さらに、このリリースの直前にはElastic Cloud on Kuberunetes(ECK)というものベータリリースされました。少しわかりにくいかもですが、ElasticsearchやKibanaをKubernetesのOperatorとして利用できるようになっています。こちらもElastic Licenseでリリースされているのでk8s上でKibanaやEsを管理しようとしている方は触ってみると面白いかもです。

Elastic Cloud Elasticsearch ServiceがGCP日本で利用可能に(7月)

リリース記事はこちら

Elastic Cloudもプラットフォームが拡大した年でした。 Google Cloud Platformの東京リージョンを選択できるようになりました。さらなる統合（支払いをGCP経由にまとめたり、GCPのコンソールから利用できたりなど）も進んでいます。

Elastic Stack 7.3.0リリース(8月)

リリース記事はこちら

データフレームと呼ばれるデータ取り込み時のピボット機能が導入されました。また、MapsのGAリリース、Elastic APMの.NETエージェント正式リリースなど、細かいですが様々なものがリリースされています。

Elastic Cloud Elasticsearch ServiceがAzureで利用可能に(9月)

リリース記事はこちら

Microsoft Azureへのデプロイも可能になりました。残念ながらまだ日本リージョンには来ていないですが、今後出てくるはずです！さまざまなクラウドベンダーのサポートにより、より多くの人に使っていただけるようになるのかと。

Elastic Stack 7.4.0リリース(10月)

リリース記事はこちら

もう7.4.2まで出ていますが、いい感じの間隔で7.0、7.2、7.3と来ていますね。 7.4では、スナップショットリストアがKibanaから簡単に行えるようになりました。これまではKibanaのConsoleでJSONを見ながら管理されていたかもですが、GUIにより今どんなスナップショットがあるのか、どれをリストアするのかといった操作が簡単にできるようになっています。

KibanaについてはPKI認証のサポートなども始まり、様々な認証方式でより便利にKibanaが使えるようになっています。

12月？

12月ですし、Elasticsearch勉強会では「LT＆忘年会」ということで、懇親会がメインの勉強会として12/6に開催します。悪路クエストの緑川さん、吉岡さんに主体となっていただき、マイクロソフトさんを会場に借りて開催予定です。興味のある方はぜひご参加ください。 LTもおまちしています！

まとめ

駆け足でしたが今年を振り返ってみました。今年も色々ありました。残すところあと1ヶ月です！

さて、Elastic Stack Advent Calendar 2019は今日から25日まで続きます。今年はその2もできています！こらからの記事を楽しみにしています！本日はその2で**[kaibadash@github]**さんが「5分でできるElastic stack環境構築」というのを書いてくれてるはずです！

ということで、次はKunihikoKidoさんの「 Elastic Cloud を使うようになって設計方針やら変わったことについて書きます。」になります。お楽しみに！

Bonfire Data & Science #1に参加しました

Fri, 25 Oct 2019 19:40:02 +0900

Bonfire Data & Science #1にブログ枠で参加してきました。ということで、メモです。

日時 : 2019/10/25 19:00 - 21:30
場所 : Yahoo! Japan
サイト : https://yj-meetup.connpass.com/event/148121/
ハッシュタグ: #yjbonfire

概要

Data & Scienceとは？データとサイエンスに関わる人達の情報共有のための勉強会/交流会

サイトから引用です。

第1回のテーマは「画像検索」です！

最近EC系のサイトで類似画像検索が出来るようになったけどどうやってるの？
画像検索のモデルってどうしてるの？
画像検索のインフラはどうしてるの？
私たちの会社でも画像検索を用いたサービスを構築できるだろうか？
こういった疑問に答えたり、いま抱えている悩みを解決するヒントを得る場になればと思っています。

今回は、画像検索を行なっているヤフー, メルカリ, ZOZOテクノロジーズの3社に事例と基盤技術について登壇いただきます。

QAはこちら。https://app.sli.do/event/w3wayjmv/live/questions

Mercari画像検索について(仮)

発表者：荒瀬晃介(株式会社メルカリ / AIエンジニアリングチーム)
AIエンジニアチーム
写真検索プロジェクトのTech Lead
iOSのみで提供の写真検索
システムオーバービュー
- MobileNet v2で特徴抽出
- ANNのインデックスを使ってDBに入れる
論文も発表済み（3本）
- 今日の発表はこの内の2本を元に話をします。

C2Cでの問題点

商品は床やテーブル上で撮影
クエリは着用（着ている）画像が使われやすい。
- 人が写ってる写真が結果に多いと業者が出展しているように見えてしまう。

提案手法

人が写ってるものから人の代表ベクトルを抜き取る (クエリ時にのみ処理を実施しているので変更が容易)
特徴変換ベクトル
- トップスなど、分類ごとに学習させてからベクトルを構成
なんでMobileNet v2?
- エッジデバイスでの処理を見据えて選択

インフラ

Docker + k8s
CRDを使ってる？
training
- コンテナベースパイプライン
  - いくつかのバッチ処理を工程ごとにパイプライン化
  - バッチ実行情報をカスタムリソースとしている＝再実行が簡単（復旧作業が容易）
- 画像を扱う＝ダウンロードが時間がかかる -> 復旧しやすいようにPVにある程度キャッシュさせている
Serving…
- GCP側
なぜ2つに別れてるんだろう？実際のサービスも2つに分かれてたりするんだろうか？

将来の展望

Realtime Image Search
- カメラでものを写している状態でそれが何かを検索できる。
- 物体検出＋特徴抽出をエッジで行うためできる
エッジの性能により違いが出てきたりするっぽい

QA

Q: 業者が想定されると、購入意欲を下げるというのは実験した結果？それとも想像？
- A: 実験はしていないが、e-commerceにおいての研究がある
Q: どういう理由でマルチクラウドにしたんでしょう?
- A: 画像のマスターがAWS。メルカリのマイクロサービスはGKEなので、サービング環境がGCP
Q: 画像の内、服のエリアが大部分で体の面積が少ない場合と、メガネや帽子のように、アイテムの方の面積が少ない場合で、トレーニングに必要なデータ数は変わりましたか？
- A: カテゴリによる性質の違うはある。ので、改善は必要。

ZOZO画像検索について(仮)

発表者：平田拓也(株式会社ZOZO / AIエンジニアリングチーム)
(聞き逃した。。。)
WEAR
マルチサイズ

チーム構成

研究所＋ML Opsチーム

使用しているアルゴリズム

物体検出アルゴリズム
特徴量抽出アルゴリズム
近似最近傍探索（approximate nearest neighbor, ANN）

インフラ

GCPを採用。
- BigQuery上にデータ基盤がある
- Managed GPUが必要
なんでk8s?
- コンテナ
- Cloud Runがなかった

アーキテクチャ

マイクロサービス化されている
Google Cloud Next 2019 Tokyoでsonotsさんの発表があるよ

監視項目

CPUなどは見ていない
レスポンスタイムとステータス監視
リクエスト数
APM
使ってるものStackdriver + Datadog + Sentry
- Warningが30分で続けたら通知などができるのがStackdriver

画像検索の改善のためにやっていること

課題
- レイテンシーが大きい
  - 推論が大変？
- 急激なトラフィックの増加に対応できない
  - GPUのスケールアウトが問題 -> 先行投資が必要
流れ
1. キャッシュありなし
2. 物体検出 (GPU)
3. 特徴量抽出 (GPU)
4. 近似最近傍探索
5. DBから取得

2と3が問題

2と3を特徴量DBという形でデータが登録された時点で特徴量などを計算してしまうことでGPUへの依存をなくした。
Apache AirFlowが便利？

Cloud ComposerとApache AirFlow

Cloud Composerに関するいくつかのTipsがありました。

QA

Q: 推論をCPUでやったらどれぐらい遅いんだろう
- A: GPUインスタンス代金 < それと同等の速度を出すためのCPUインスタンス代金
Q: k8sスケールアウト時のリソース割当を最適化する為、resource limit / request標準化 or 時系列分析などから自動調整するなどはされていますか？
- A: …聞き逃した
Q: (TCOを考慮したクラスタ構成) Cloud Composerの値段が高いようなパプリッククラウド利用の課題対策としてプライベートクラウドとのハイブリッド構成にされているのでしょうか？もしハイブリッド構成でしたら、パブリック or クラウドを切り分ける基準はございますか。
- A: GKEオンリー
Q: cloud composerでairflowを使う辛い点は？
- A: 不安定さ。。。

Yahoo!ショッピングにおける画像検索(仮)

発表者：佐藤純一(ヤフー株式会社)
商品検索APIの開発とか検索エンジンの保守とか
類似画像検索システムの開発が直近の仕事

類似画像検索

ヤフーショッピング
- 3億の商品
- ファッション系はビジュアルが重要＝言語による表現が難しい
iOSとAndroid
- Androidだとカメラで撮影してから検索みたいなことも可能

システム概要

物体検出

ノイズ除去

特徴抽出

インデックス(NGT) -> https://github.com/yahoojapan/NGT

1000万件を超える

検索

アプリの画像をAPIに投げてベクトルから、近いものn件を取得

ベクトル化/インデックス更新

GPUマシン
Kafka使ってる
クラウドストレージに日次？バックアップみたいに保存
差分更新の仕組みがある
メンズとレディースは分けている
- 絞り込み検索のために分離（インデックスのメタデータとしてタグがある）

システム構成

Python
Kafka
TensolflowServing
可視化？監視？はGrafana＋Prometheus

開発を通しての学び

自動デプロイとかテスト
検索精度の確認ツールを作る
- コレ重要だよね。何が変更してるかとか、何が正しいかってのが必要だし。。。
復旧可能、早期復旧の仕組みを容易

今後の方針

対象商品の拡大
物体検出特徴抽出モデルの性能改善
NGTの検索システムをValdに移行
- Vald
  - k8s上で動作、分散検索、分散インデキシングなどの機能を提供予定

QA

Q: iOS(既存の画像)とAndroid(カメラで撮る)で画像検索の方式が違うのはなぜ？
- A: アプリの違い
Q: 1枚の写真に沢山写っている中で、対象の商品をどう識別しているんでしょう。靴もトップスもボトムスも写っていたら、かなり難しそう
- A: Yahooブラウザの場合は1番大きな領域のものを選択。Yahoo shoppingだと選択可能

NGTについて(仮)

発表者：岩崎雅二郎(ヤフー株式会社)
類似画像検索を20年くらいやってる

近傍検索ライブラリ

https://github.com/yahoojapan/NGT
- 高次元ベクトルの近傍検索
- ツリーとグラフによるインデックス
近傍検索とは?
- 距離空間上でのクエリの近傍のオブジェクトを取得
  - k最近傍検索（通常はこっち）
  - 範囲検索（あんまり使われない）
NGTの特徴
- 世界トップレベルの高速高精度な近似近傍検索
- OSS
- 追加削除が可能（削除がとくに難しいらしい）
- 多様な利用形態（Python、C++、C、Go、コマンドライン）
- サーバ版NGT（ngtd、vald）を提供
- 共有メモリ版でメモリサイズ以上のデータ登録可能
- 量子化版NGT（NGTQ）により。。。
ANNベンチマークによりテスト
- 実行環境が決められているらしい。誰が実行しても比較可能
- グラフベースの検索の仕組みのほうが性能がいいというのがベンチマーク結果からわかる

なんではやいの？

インデックス生成
- ツリー（グラフの探索起点の取得に利用する。DVP-tree）
- グラフ（ANNG）
  - ノードを逐次追加しつつ、近傍ノードを検索してから接続するというのを繰り返している
検索
- ツリーから絞り込みつつ、グラフを検索する
ANNGに課題があるのでONNG（Optimized Nearest Neighbors Graph）に
- ノード単位の次数（入出）を最適化
- データセットによって有効な次数が違う。。。

NGTを利用した深層学習で。。。

Yahoo!ラボ FavNavi
特徴量の構成（低次特徴量（300次元）、カテゴリ特徴量（128次元）、領域アスペクト比（1次元））
- 個別の特徴量だけだとイマイチな結果になるが、組み合わせるといい感じになる

モデル性西洋学習データ

スライドがあればいいなぁ（表書くの大変だし。。。）

QA

Q: 実際のお客さまの利用を考えると、近似近隣の密度が異なるので、近いものばかりの検索結果や遠いものも含んでしまった検索結果が出ると思うのですが、遠いものが含まれてしまうと、閾値でフィルタしたりするのでしょうか?
- A: NGTは近いものしかないので、外れ値ってなんでしょう。。。
  - 検索のフィルタリングをある程度している（カテゴリとか）。

まとめ

慣れない分野の話を聞きながらざっとメモを取ったものなので役に立つかはわかりませんが。。。

アルゴリズムとかまでは得意ではないんですが、画像「検索」ということで参加してみました。実際に画像検索の仕組みがどんな感じでできているのか、どんな技術がつかわれているのか？ってのがわかったのは面白かったです。確かに検索のためのキーワードって出てこないことあるしなぁと。あー、こんなかばんほしいとか、これなんだろ？みたいなのあるからなぁ。

Elasticsearch NEXT STEP 2を頂きました

Thu, 10 Oct 2019 15:56:29 +0900

この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました。なので、軽く読んでの感想と宣伝です（これ、電子版とかで買えないのかな？）。

Elasticのパートナーとしても活躍していただいてますが、こういう感じでさまざまなところでElastic Stackを広めていただいていて感謝しかありません。

章立てとしては以下の通りです。

Elasticsearchでエンタープライズサーチを実現する

同僚が作成、メンテナンスしているFSCrawlerを使った例も書かれています。ローカルのファイル（PDFやJSONとか）をサクッとElasticsearchにインストールしたりするのには便利です。

Kibana Canvasによる柔軟な可視化

Canvasについてどんなものなのか？というのとelasticcofeeというサンプルを元に、その変更の仕方などが説明されています。

Elastic APMによるアプリケーションパフォーマンス監視

Go AgentとAPM自体の使い方の説明です。最近強化されている他の機能との連携（AlertingやMachine Learning）についても触れてくれています。

Kubernetesクラスタのメトリクス・ログ・性能情報の可視化

Azure上でAzure Kubernetes Serviceの上で動いているアプリなどをBeats、APMでデータを取りつつ、他のAzure上にAzure Marketplaceのテンプレートを用いて起動したElasticsearchとKibanaの環境を用いて可視化する方法が説明されています。

ということで、薄い本ですが、手順をおって説明されていたり、7.3と新しいバージョンで書かれているのですばらしいなぁと。前作の「Elasticsearch NEXT STEP」に引き続きインプレスさんから出たりするのかなぁ？

ちなみに、Elastic APMのRubyに関して興味がある方は、私が前に発表したときの資料がありますので、こちらを参考にしてみてください。

Elastic Stackで始めるアプリケーション監視

Fri, 04 Oct 2019 00:00:00 +0000

ソフトウェアのテストしてますか？では、ドキュメントは？

Sat, 07 Sep 2019 00:00:00 +0000

アプリケーション(パフォーマンス) 監視入門 - Elastic編

Sat, 29 Jun 2019 00:00:00 +0000

勉強会の受付自作？アプリ？HTMLについて

Wed, 19 Jun 2019 19:10:44 +0900

Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、受付用アプリとかなくてという話になったので、普段Elasticsearch勉強会で使用している QRコード生成の仕組みを紹介してみようかと。

HTMLだけで済むようにQRコードを生成するjquery.qrcode.min.jsってのを使用してます。

HTMLコードはこちら。

仕組み

1枚だけのHTMLを生成
MeetupのOAuth2の仕組みを利用(consumer keyを発行する必要あり。)
Meetup APIを利用してユーザー情報取得
取得したユーザー情報をGoogle Formに埋め込んだ形で表示するURLを組み立てる
組み立てたURLをQRコードにしてHTMLに表示
受付で、QRコードリーダーを使って、QRコードを読み込むとGoogle Formが開くので、「送信」ボタンを押す

1. HTMLの作成

QRコードを表示するためのHTMLを作成します。Gistに貼り付けてあるので、参考にしてもらえれば。いくつか埋め込まないといけないものがあるので、個別にそれは説明します。

2. Google Formの準備

Elasticsearch勉強会では、出席者の情報として、IDと氏名をリストとして保存しています。目的としては、何人実際に参加したかを計測するのが目的です。ですので、参加者リストのGoogle Formを作成します。で、作成した後に、プレビューを表示する。こんな感じ。

この時のプレビューのURLをQRコードのURLとして使いたいので、このURLをQRコード表示のHTMLに埋め込みます。

function createGoogleFormURL(data) {
  var obj = {
    "entry.1744035444" : data.id,
    "entry.2031666715" : data.name
  };
  return "https://docs.google.com/forms/d/e/<GOOGLE_FORM_ID>/viewform?" + $.param(obj);
}

ここら辺です。 returnに書いてあるhttpsで始まる文字列をまず、先ほどのURLで置き換えます。次に、プレビューのHTMLの中から<input>タグを探して、nameの値を抜き出します。それをobjのキーに利用します。entry.で始まる文字列が該当します。

これで、このURLをQRコードにすれば、値（ここだとIDと氏名）が埋め込まれた形のGoogle Formがスマホのブラウザで起動します。

3. Meetup APIの準備

MeetupのAPIを利用できるようにします。Meetup.comにログインするとみれるAPIのページがあります。 https://secure.meetup.com/meetup_api

まず、OAuthを利用するためのConsumer Keyを発行します。

メニューのOAuth Consumersをクリックして、

“Create New Consumer"をクリックします。すると、次のような画面が開きます。

Consumer nameとRedirect URIが重要です。

Consumer nameはユーザーがMeetup経由で認証するときに、その認証画面で表示される名前になります。わかりやすい名前を表示してあげると良いかと。

Redirect URIが一番重要です。実際にOAuthで認証が通った後に表示するHTMLを提供しているURLを指定します。 Elasticsearch勉強会の場合は、私のドメインにwwwをつけた"https://www.johtani.info"を指定しています。実際にQRコード表示用のHTMLを配置するHTTPサーバーのトップのURLを指定します。（ちなみに、私のウェブサーバーはS3で運用してます。ですので、HTMLをS3のバケットにアップロードしてあるだけです）

必須項目を入力したあと、最下部にあるRegister Consumerボタンを押せばキーが生成されます。生成されたキーがOAuth2のURLのパラメータに必要になります。

これで、リダイレクトの準備が整いました。

OAuth2のURLには、Implicit Flowを利用します。これで、リダイレクト先のHTMLにトークンがわたるので、Meetup APIにこのトークンが使えるようになります。

認証用のURLはこちらです。このURLを参加者宛のメールに入れて毎回送信しています。

https://secure.meetup.com/ja-JP/oauth2/authorize?response_type=token&redirect_uri=<QRコード表示HTMLのURL>&client_id=<コンシューマーキー>

参加者はこのリンクをクリックすることで、次のような画面が出てきます。ログインしていない場合はLog in画面が表示され、まずはログインを促されます。

で、Allowをクリックすれば、redirect_uriに指定されているページが表示されるわけです。

QRコード表示用のHTMLでは、次のAPIを使用して、ログインしているユーザーの情報を取得してきています。

function getMemberId() {
  $.getJSON('https://api.meetup.com/2/member/self/?only=id,name&access_token='+ getToken(), displayQRCode);
}

ここで取れた値が、先ほどの「2. Google Formの準備」で説明したコードのdataの部分に渡ってくるわけです。

function createGoogleFormURL(data) {
  var obj = {
    "entry.1744035444" : data.id,
    "entry.2031666715" : data.name
  };
  return "https://docs.google.com/forms/d/e/<GOOGLE_FORM_ID>/viewform?" + $.param(obj);
}

4. QRコードの表示

あとは、jquery.qrcode.min.jsを使用してURLを表示するだけです。

function displayQRCode(data) {
  $('#qrcode').qrcode({width: 128,height: 128, text:createGoogleFormURL(data)});
}

サイズとURLを指定するだけですね。

まとめ

あとは、受付で、参加者の方が表示してくれたQRコードをスマホのQRコードリーダーやカメラで読み込めばGoogle Formが開いて必要な情報は入っているので、「送信ボタン」を押せば参加者リストが出来上がっていくという形になります。

毎回勉強会の前日に、前回のGoogle Formを「コピー」してから、各回の勉強会の登録者フォームを作成しています。コピーすることにより、Google Formの<input>タグに使用されるnameもそのままコピーされるので、 QRコード生成用のHTMLを書き換える部分の手間が減る形になっています（気づくまで数回かかったw）。

ですので、QRコードのHTMLの中身としては、「勉強会のページへのリンク」、「Google Formへのリンク」の2つを書き換えてから毎回アップロードしているだけとなっています。

このやり方が、スマートかどうかはわからないですが、受付アプリがない中、Meetup.comから取得した参加者リストのExcelやプリントアウトしたリストを元に参加者をチェックするよりは、手間が省けてるんじゃないかなぁと。

残念ながら、QRコードの存在を知らないでそのまま勉強会にくる人がいるので、受付で最低一人はMeetup.comの参加者リストから、名前を検索してチェックするという作業もやってもらってます。 QRコードを持ってきた方がすんなり受付を通過できるようになってますので、ぜひQRコードを持って勉強会にきてもらえればと。

What’s new in Elastic Stack 7.1?

Thu, 23 May 2019 00:00:00 +0000

勉強会運営座談会ってのをやってみた

Fri, 26 Apr 2019 00:02:06 +0900

Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートしてみたところ。

あー、勉強会運営座談会したい。
— Jun Ohtani (@johtani) 2019年4月2日

面白そう
— 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日

やってみるか。
— Jun Ohtani (@johtani) 2019年4月2日

やりましょう
— 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日

ってことで、何人か釣れたので、勉強会運営座談会をやってみました。会場提供していただいた、Classiさんありがとうございました！

参加してくれた人たちはまぁ、勉強会のサイトを見ていただければなんとなくわかるかなと。自己紹介とどんな勉強会、読書会運営してますってとこから始めて、次のようなトピックについてピザ食いながら3時間くらい話しました。

スピーカーの募集方法
- 運営側から声かけてる？それとも公募してる？
- 登壇時間とかどうしてる？
- スピーカーになってもらうためになんかやってる？
スケジュール管理
- 会場探し、スピーカー探し、イベントページ作るタイミングは？
- 複数拠点開催したことある？
- ハンズオンとかはどうしてる？
土日開催？平日開催？
アンケートとってますか？
使用してるイベントサイトは？
ドタキャン対応どうしてる？出欠とったりしてる？懇親会の規模とかどうやって見積もってる？
運営費用関連はどうしてる？
- グッズとか、ツールとか、スピーカーへの謝礼とか
運営って複数でやってる？
- その時のツールは？
- 運営メンバーにはどうやってなってもらう？
- 録画配信とかまで手が回る？
会場探すの大変じゃない？
- 会場の部屋の使い方はどうしてる？
行動規範とかどうしてる？
読書会の場合に人が減ってったりしない？

まぁ、こんな感じです。色々話してメモしてたんですが、まぁトピックくらいで。

そもそもは、勉強会の運営って本業ではない（はずな）ので、いかに楽をしつつうまく運営できるかってのを知りたいのと、他の人どうやってるかってのからアイデアもらえるといいなーと思ったんでやってみました。他のツールがどんなものかとか知れたし、あー、そういうやり方すればいいのねーみたいなのも知れたので、次回以降の勉強会に活かせればなーと。自分がやってるやり方とかもブログ書くといいのかなぁ？

残念です！次回もやるかもしれないので、 @johtani さんに期待してください！
— 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月25日

次回やるのかなぁ？興味ある人いるのかなぁ？

Elastic Stackでマイクロサービス 運用を楽にするには？

Wed, 17 Apr 2019 00:00:00 +0000

Elastic StackでKafkaをモニタリング！ を始めてみるには？

Tue, 09 Apr 2019 00:00:00 +0000

Elastic再入門 #elasticsearchjp

Wed, 20 Mar 2019 00:00:00 +0000

Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。

Tue, 26 Feb 2019 23:38:00 +0900

どーも、johtaniです。

Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。本日（2/26）は第1回目だったので、ブログを残しておこうかと。

勉強会自体の資料については第1回の勉強会のページにあるし、勉強会の感想とかブログはツイートやみんながブログを書いてくれると思うので、勉強会開催の経緯などについてブログを残しておこうかと。

なんで始めたの？

私自身が古くはFAST Searchに始まり、何か縁があって、検索のシステムに長く携わってきたこと（Apache Solrの本書いたり、Elasticsearch勉強会始めたり）もあり、検索が面白いなと日々思ってます（思ってるだけかもしれないが）。

で、これまでElasticsearch勉強会をやっているのですが、検索エンジン固有の話ではない、いわゆる検索の共通の課題というのがあるなぁと。そういう課題やノウハウって、製品に限らず共有できれば面白いことがもっとできるんじゃないだろうか？と感じることが多々ありまして。オープンソースのコミュニティをソースコードをベースではなく、共通の課題・話題を中心としたコミュニティがあってもいいんじゃないかなぁと。

まぁ、要は、私がみんなの検索で困ってることとか、どうやって検索システム考えてるのかが聞きたかったわけですよ。

ということで、一人でやっても面白くないので、興味ありそうな人を募ってやってみようということを始めたのが2018年12月くらいです。

運営とかどうしてるの？

まずは、共同主催者（コアメンバー）を募集してみようということで、Googleフォーム作って、興味ありそうな人がいる場所に投稿してみました。（TwitterとかFBとか）で集まったのが今回紹介したメンバー（スライド参照）です。ユーザー企業の人もいれば、私みたいな検索エンジンの人もいるので面白い感じにできたかなぁと。で、スピーカーを運営や知り合いに声をかけて第1回をやってみたという感じです。

今後どうするの？

残念ながら次回はまだ未定です。 2ヶ月に1回くらいのペースで開催できればなーと思ってますが、スピーカーが集まるかなどによるかなぁと。ということで、勉強会のグループのページにスピーカー応募フォームのリンクがありますので、スピーカーに興味がある方は入力していただければと。

もちろん第2回はやりたいので、勉強会のページからの連絡をお待ちください！！

Search Engineering Tech Talk オープニング

Tue, 26 Feb 2019 00:00:00 +0000

Elastic Stackでマイクロサービス運用を楽にするには？ - Elastic Stackの活用 -

Fri, 22 Feb 2019 00:00:00 +0000

Elastic Stackでマイクロサービス運用を楽にするには？ - Elastic Stackの活用 -

Tue, 05 Feb 2019 00:00:00 +0000

Elastic Stackでマイクロサービス運用を楽にするには？ - Elastic Stackの活用 -

Fri, 25 Jan 2019 00:00:00 +0000

今年の振り返りと来年の抱負（2018）

Mon, 31 Dec 2018 16:14:45 +0900

今年も振り返りブログをかけてます。よかったw

振り返り（2017年に書いた抱負から）

まずは去年の抱負を元に。

もっと英語の継続＆TOEIC

まぁ、継続してます。英会話も続けてますし、海外TVドラマや映画見てます。ただ、昨年書いたTOEICはイベントが被りまくってて受けれてないです。。。来年は受けれればいいが。ちなみに見たドラマはこの辺。あんまり見てないなぁ。「はじまりのうた」は飛行機の中で見たんですが、よかったです。最近は音楽系の映画が好きなのかなぁ。グレーテストマンショー（ミュージカル風）とかもハマったし。

Game of Thrones
はじまりのうた BEGIN AGAIN (映画)
24 シーズン4まで

今は、ボキャブラリのなさに苦しんでる感じです。キクタンとかするべきなのかもなぁ。基本勉強が下手だからなー。

継続的にイベントに登壇＆ CfPもっと出すぞ！

OSCには出てました。あとは、いくつかに呼ばれて出たりでしょうか。 CfPはJJUGしか出せてない気がするんで、もっと出さないとですね。。。春のJJUGでは20分で短すぎた「オープンソースとビジネスモデル」の話（同僚のネタ）が今年面白かった内容かなぁと。もっと話を作るのをうまくしないとだろうなぁ。ユースケースが増えてるんで、もっといろんなところに出ていかないとなぁと。ブースの出し方とかもちょっと考えないといけないかもなーと思ってたり。マンネリになってきてる気がするんで、なんか取り入れないとなぁ。

もっとブログ！

出だしはよかったんですが、途中でRustネタのブログも止まってしまいましたね。。。業務が忙しくなったのを言い訳にして時間が取れなくなってるんで、もっと習慣つけないとなぁ。

雑誌やWeb系雑誌で記事を。

できてないです。。。どうすっかなぁ。重い腰上げないのが問題なんですけどね。。。自社のウェビナーとかはそこそこやってましたが。

コミュニティを別の方法で盛り上げ

フォーラムは皆さんのおかげで盛り上がってきてる気がしてます。別の方法ではなく、勉強会を9月から毎月開催にして、ユースケースごとに切り替えてみました。あとは、スピーカー登録用のフォームの用意とかして、継続的に楽にスピーカーの人たちが見つけられるようにと。私は「全然」関わってないんですが、技術書典でいろんな方に書籍を書いていただきました。また、Elasticloverという毎週いろんな記事をまとめていただけ助かりました。少しでも感謝をということで、コミュニティランチというイベントで、フォーラムで回答していただいてる方や、書籍を出していただいた方を招いてCEOのShayとランチするというイベントもやってみました。少しは盛り上げられたかなぁ。次は、ハッカソンみたいなのとかやってみるのもありなのかなぁ？（サポートしきれない気がするんだよなぁ）

Elasticsearchなど検索系の開発にも参加

開発。。。 Analyzer向けのKibanaのプラグインの開発は継続してますが、あんまり開発してないですねぇ（GitHubの草をみながら)。ちょっとしたPRはやったりしてますが、もっとやりたい。。。とりあえず、来年しょっぱなは、検索系じゃないですが、KibanaのプラグインのReact化をやらないとなぁと。

振り返り(今年あったできごと)

さて、反省が多かったですが、ここからは今年の出来事を。

初スノーシュー in US
オフィス引越し
パリで料理w
K8sとde:code
QNAPとか
IPO!
初のオンライン登壇
初アイルランド!
Pixel3 XL

今年も初モノがちらほら。

アメリカでスノーシューやりました。昨年は釣りでしたが、今年はスノーシューでした。スノーシューはすごくよかったんですが、サンフランシスコから社内ミーティングのある場所までの移動に10時間バスに缶詰という変な初モノもありました。。。スノーリゾートのある山の上にバスで移動だったんですが、前日までの天候の生でチェーン規制が出てしまい、登りかけた山を降りて、違う経路で登り直すという長旅でした。。。途中からずっとゲームオブスローンズみてました。。。

オフィスが引っ越しました。人数が増えてきたのもあり、銀座のWeWorkに引っ越しました（私はあんまり行かなかったりしますがw）。ただ、すでに手狭になってきて、来年はまた引っ越してるかもなぁ。今年の終わりで日本のメンバーが22名に増えました！すごい！4年半前の22倍！

パリで料理もしましたwセールスのキックオフミーティングがパリで開催され、なぜか参加してきました。そこで、DevRelチームのミーティング＆ディナーがあったんですが、ディナーがアクティビティ付きで、チームのみんなとパリで料理やカクテル作ってきました。まさか、パリで手巻き寿司作るとは思わなかった（怖くて食べてないですw）

今年はイベントが連続することが多かったです。パリから帰ってすぐにde:codeでMSの川崎さんと登壇したりしました。Kubernetesを触る機会ができたんでよかったですが、時差ボケは辛かったw今年は他にもカンファレンス直後にトレーニングだったりと、夏に喉やられちゃいました。喉に負担をかけない話し方の練習すべきなんだろうなぁ。

自宅の環境もちょっと整えました。10年前から使ってた、TeraStationをQNAPに刷新。快適に検索できるわ、クラウドにバックアップとれるわで、すごく快適です。あとは、自室のディスプレイをディスプレイアームにつけたり、壊れたモニタースピーカーをYamahaのパワードスピーカーに買い替えたりと。ちょこちょこ自宅で作業したりするんで、快適です。

今年はめでたいことに会社がIPOしました。ニューヨーク証券取引所で株式公開しました。転職して4年、初体験なんで何がどうってのはいまいち実感わかないんですが、順調にきてるのは嬉しい限りです。今後も頑張りますよ！

自社のウェビナーでは、オンライン登壇してたんですが、インフラ勉強会でオンライン登壇させていただきました。 Elastic Stackの入門的な話をさせていただいたので、興味があればみていただければと。こういうのにはマイクが非常に重要だなというのが結論です。ウェビナーで使ってるShureのマイクで話したので聞き取りやすかったです。来年はもっと手軽にちょっとしたウェビナーとかポッドキャストやろうかな、ということで、持ち運び用にSAM SONGo Micを購入してみたのでどっかで試してみたいなー。

アイルランド（ダブリン）にも行きました。これまた、社内のミーティングなんですけどね。半年に1度エンジニアが集まる社内イベントがあるので、いろんなところに旅をさせてもらっていて、すごく楽しいです。みんなにも会えるし。ただ、アイルランドの英語はきつかった。。。

最後はPixel3です。SonyのXperiaをここ数年は使ってたんですが、電池の持ちなどが悪くなったんで、気になってたPixel3に変えました。すごくいい。いらないものが入ってないのもいい。あとカメラがすごくいい。他の機能をまだちゃんと調べてないんで、誰か便利機能知ってたら教えてくださいw

とまぁ、こんな感じでした。

来年の抱負

最後は来年の抱負を。

TOEIC
CfP見つけて応募 & いろんな場所に顔を出す
もっとブログ！
Rustの継続
開発の継続
日本でエンジニア獲得!

まぁ、英語ですね。これは地道にやるしかないんだろうなと思いつつ、コツコツが苦手でw とりあえず、今年はどこかでTOEIC受けないとな。

いつも行かないけど、弊社プロダクトに関係のあるカンファレンスのCfPを見つけ出して、応募しまくって、少しでもしゃべらないとなぁ。喋れなくても、Elasticsearchがらみで登壇していただいてる方がいるカンファレンスには顔を出していきたいなぁと。登壇される方いたら、ぜひ連絡ください！あとは、CfPのサイトを探す仕組みを作らないとなぁ。検索サイト作るかなぁ。あとは、カンファレンスではなく、いろんな会社に遊びにいきたいと思ってます。入門的な話をしてほしいような方、こんな使い方してますっていう話をしていただける方、大募集です。これもGoogle Formでも作ってみるか。

ブログなぁ。小さな習慣を読んだのに、習慣化できてないので、なんとかしないとという意味で。。。が、頑張ります。。。

Rustの継続＆開発の継続もですね。Java歴が長いので、他の言語を勉強しようと思ってRustやってますがなかなか身についてないというか、時間を取れてない。これもコツコツやらないとなー検索関連の開発もちょっとずつやりたいなと思ってるんで、LukeへContributeしようかな。

切実なんですが、日本に弊社のエンジニアを増やしたいなと。特に人前で喋ってもらえる人が増えると助かるんです。弊社最近、ユースケースが増えてきてて、追いつかなくてwダレカタスケテーw

さーて、そろそろ紅白のサザンが始まるんで終わりです。

今年も様々な方々に様々な面で助けていただきました。本当にお世話になりました。この場を借りてお礼申し上げます。

来年ももちろん、助けてもらうんで、よろしくお願いいたします！あと、話聞きたい方、声かけてくださーい。