portal shit!

いろいろあって手元で docker build が通らなくなってしまったので ChatGPT に相談したら Alpine Linux はビルドが遅くなるので Debian Slim に変えた方がよいと言われてガチャガチャやった。BuildKit を使ってキャッシュせよとも言われたけど、逆にビルドにめっちゃ時間かかるようになったので BuildKit は使わずに普通にビルドしてる。 Apple Silicon の Mac で Linux で動かすように linux/arm64 でビルドしてたけどこれが遅い原因だと散々言われた。クロスプラットフォームで BuildKit のキャッシュを使うとめっちゃ遅くなるらしいので逆効果だった（半日以上ビルドしても終わらないてことがざらだった）。

Docker 、これまで Alpine ベースのイメージを使ってたせいで自前でいろいろコンパイルしたりインストールしたりしてたけど、ビルド済みのものをダウンロードしてくる運用はやっぱり楽。 Alpine 使っても最終的なイメージサイズは膨大になってたし、もっと早めに Debian ベースに変えればよかった。

ちなみにビルドが通らなくなったのは tantiny が依存する rayon という Rust のライブラリが Rust 1.8 以降でしか動かなくなったため。 tantiny は Rust 1.77 までしかサポートしてないので Rust のバージョンを 1.77 で固定していたが、このせいでビルドにこけるようになった。なので tantiny をフォークして rayon と rayon-core のバージョンを古いバージョンに固定した。

tantiny および tantivy は楽に運用できる非常に優れた全文検索ライブラリだと思うけど、 tantiny のメンテナーの人が仕事で使わなくなったそうでメンテナンスされてないのが悲しい。自分でできるならやりたいが、職業プログラマーではないし Rust わからんちんなのでどうしたもんか…。

Rust 製の全文検索システム Tantivy を Ruby から使える Tantiny を導入したことを書いた。

Rust 製の全文検索システム Tantivy を Ruby で使える Tantiny を導入した

過去記事の効率的な閲覧方法を模索し、全文検索システムTantivyとそのRubyクライアントTantinyを導入した。個人ブログでも高機能な検索が可能になり、技術の進歩を実感している。

portalshit.net

結構手軽に使えるのだがやはり日本語のトークナイズ（形態素解析）ができないのでいまいちなところがあった。 Tantivy には lindera-tantivy というものがあって、 Lindera は kuromoji のポートなので、これを使うと日本語や中国語、韓国語の形態素解析ができる。 Tantiny に導入できないか試してみたが、自分の Rust 力では到底無理だった。

ちなみに関連記事の表示でも日本語の形態素解析は行っている。

⛓TF-IDF で関連エントリーを表示

cho45 さんの以下の記事を参考に関連記事を表示するようにしてみた。 TF-IDFとコサイン類似度による類似エント...

portalshit.net

MeCab に neologd/mecab-ipadic-neologd を組み合わせてナウな日本語に対応させつつ形態素解析している。

この仕組みを作ってトークナイズは Ruby で自前で行い、 Tantiny および Tantivy にはトークナイズ済みの配列を食わせるだけにした（ Tantiny はトークナイズ済みのテキストを受け付けることもできる）。トークナイズを自前で行うことで辞書ファイルで拾いきれないような固有名詞もカバーできる。例えば 山と道 なんかは MeCab と mecab-ipadic-neologd にトークナイズさせると 山 と 道 に分割されてしまう。自前のトークナイザーで単語として認識させていている。おかげで「山と道」をちゃんと検索できるようになっている。

なお、自前のトークナイザーはこんなコードになっている。

class Tokenizer
  attr_reader :text

  class << self
    def run(text)
      self.new(text).tokenize
    end
  end

  def initialize(text)
    @text = text
  end

  def cleansed_text
    @cleansed_ ||= text.
      gsub(/<.+?>/, '').
      gsub(/!?\[(.+)?\].+?\)/, '\1').
      gsub(%r{(?:```|<code>)(.+?)(?:```|</code>)}m, '\1')
  end

  def words_to_ignore
    @words_to_ignore ||= %w[
      これ こと とき よう そう やつ とこ ところ 用 もの はず みたい たち いま 後 確か 中 気 方
      頃 上 先 点 前 一 内 lt gt ここ なか どこ まま わけ ため 的 それ あと
    ]
  end

  def preserved_words
    @preserved_words ||= %w[
      山と道 ハイキング 縦走 散歩 プログラミング はてブ 鐘撞山 散財 はてなブックマーク はてな
    ]
  end

  def nm
    require 'natto'
    @nm ||= Natto::MeCab.new
  end

  def words
    @words ||= []
  end

  def tokenize
    preserved_words.each do |word|
      words << word if cleansed_text.match?(word)
    end

    nm.parse(cleansed_text) do |n|
      next unless n.feature.match?(/名詞/)
      next if n.feature.match?(/(サ変接続|数)/)
      next if n.surface.match?(/\A([a-z][0-9]|\p{hiragana}|\p{katakana})\Z/i)
      next if words_to_ignore.include?(n.surface)
      words << n.surface
    end

    words
  end
end

preserved_words が手製の辞書だ。 はてな や はてブ も辞書登録しておかないと MeCab だとバラバラに分割されてしまって検索できなかった。

難点としては記事更新後に自動でインデックスの更新が行われず、 cron によるバッチ処理でインデックス更新を行っている[^{1]。なので検索インデックスにデータが反映されるまでにタイムラグがある。} Tantiny でやれれば記事作成・更新時のコールバックとして処理できるのでリアルタイムに変更を検索インデックスに反映させることができるが、個人の日記なのでタイムラグありでも大きな問題にはならない。

本当は Tantiny で lindera-tantivy を使えるようにして Pull Request がカッチョイイのだが、とりあえずは自分は目的が達成できたので満足してしまった。 5 年くらい前から Rust 勉強したいと思っているが、いつまでも経っても Rust を書けるようにはならない。

[^1]: mecab-ipadic-neologd を VPS 上でインストールできず（めっちゃメモリを使う）、手元の Mac で Docker コンテナ化して Docker Hub 経由でコンテナイメージを Pull して VPS 上で Docker 経由で動かしている（その辺について書いてる記事: ブログのコンテナ化を試みたけどやめた）

ブログ過去記事の閲覧 UI にはこだわりがある。これまで何度か記事を書いた。

過去記事ページの UI 考察

過去記事の探しやすさを最優先に、本文不要のタイトル一覧や年・月・カテゴリでの絞り込み、件数表示などを検討。主要ブログのアーカイブUIを比較し、自サイトのアーカイブ設計案と改善点を整理。

portalshit.net

ブログのアクティビティダッシュボード

Archive ページにこだわってしまう理由、グラフを表示させてみて（ブログ過去記事をカテゴリーごとに集計してグラフ化 - portal shit!）何となくわかった気がする。過去記事ページとい...

portalshit.net

このブログの維持管理で一番時間を割いているのが Archives ページだ。しかしアクセスログを見ると自分以外はほとんど利用していない。完全に自己満なのだが、過去の自分を振り返ることができてとても自分には有意義なページだ。

過去記事を振り返るときには検索をしたくなる。タイトルのみであればページ内検索で探せるが、やっぱり本文込みで検索したい。 Lokka の検索はあるが、検索結果ページは 7 件ずつ（この値はカスタマイズできる）表示で全文表示される。自分は検索キーワードに関する記事が存在するか知りたい訳ではない。著者なのでキーワードに関連する記事があるかないかくらいわかってる。じゃなくて過去の自分がいつ頃どの密度でそのトピックについて書いていたかを知りたいのだ。

タグやカテゴリーで絞り込む手もある。しかしカテゴリーやタグは理想的な分類ではない。二つのカテゴリーを横断するような記事があるし、タグは設定し忘れていることが多い。全文検索が一番頼りになる。

SQL で全文検索的なことをやろうとするとパフォーマンスが良くないだろう。やっぱり全文検索システムが欲しい。

Tantivy と Tantiny

とはいえ、個人のブログで全文検索エンジンを導入するのはしんどい。確かに Apache Solr や Elasticsearch を個人ブログに入れるのはきつい。もっと手軽に使えるものはないか探していて、 Rust 製の全文検索システム Tantivy と、その Ruby クライアントの Tantiny を発見した。

GitHub - quickwit-oss/tantivy: Tantivy is a full-text search engine library inspired by Apache Lucene and written in Rust

Tantivy is a full-text search engine library inspired by Apache Lucene and written in Rust - quickwit-oss/tantivy

github.com

GitHub - baygeldin/tantiny: Tiny full-text search for Ruby powered by Tantivy

Tiny full-text search for Ruby powered by Tantivy. Contribute to baygeldin/tantiny development by creating an account on GitHub.

github.com

これがめっちゃ簡単で昨日数時間サンデープログラミングをして導入できた。システム環境に適合するビルド済みのバイナリが GitHub にあれば Rust 環境のセットアップすら必要ない。 Gemfile に gem 'tantiny' と書いて bundle install するだけで使えてしまう。

うまくいかなかったもの

最初、同じ Rust 製で Wasm までセットで提供してくれる tinysearch を試した。 JSON 形式で全ファイルを書き出すだけで使えるやつだ。しかし残念なことに日本語では全く使えなかった。自然言語処理をやろうとしていてあるあるのパターンだ。日本語は MeCab などでトークナイズしてやる必要がある。

デフォルトのトークナイザーでもそこそこに優秀な Tantivy

Tantivy にもトークナイザーをカスタマイズできる仕組みはあるが、標準の Simple Tokenizer でもそこそこ精度が高い。固有名詞にちょっと弱いが、辞書ファイルがないので仕方ないだろう。

個人ブログでも全文検索できる時代

このブログは個人ブログだが、画像のリアルタイムリサイズサーバーを動かしている（おかげで S3 の転送量が安くて済んでいる）し、 TF-IDF で関連の高い記事も表示している。それに加えて全文検索まで入れてしまった。こういうのは大手のブログサービスを利用しないと使えない機能だったが、 OSS と新しいプログラミング言語（ Go や Rust ）のおかげで個人でもそこそこのスペックのサーバーでこれらを利用することができるようになってきた。 MovableType でサイトを構築していた時代から何も進歩していないようで実はとても進歩している。こういう文化の灯火が消えないようにしていきたい。