gihyo.jpにLanceDBの紹介記事を書きました
技術評論社のgihyo.jpで連載している「Python Monthly Topics」に、画像と本文をまとめて扱うLanceDB 〜pandasとの連携からキーワード・ベクトル検索まで〜を書きました。10月29日に公開されています。
LanceDBは、研究に加えて仕事でも使っています。記事の紹介とともに、Ploneへの組み込みなど、現在進めている開発についても報告します。
Blog
CMScomLabの活動記録や技術記事などのブログです。
ベクトル検索を試し、見つけた問題をOSS本家へ返す
ベクトル検索の研究やPloneへの組み込みを進める中で、Lance、SQLite vec1、LanceDBの動作について、本家への不具合報告や修正提案を行いました。修正がリリースされたものもあれば、修正案の確認が進んでいるものもあります。今回は、それぞれの問題に気付いた経緯と、報告までに確かめたことを紹介します。
アップロードした画像が言葉で見つかる：OSC東京でPlone＋LanceDBを実演しました
10月17日（土）のオープンソースカンファレンス2026 Tokyo/Fallで、PloneとLanceDBを組み合わせた画像検索を実演しました。アップロードした画像がすぐに自然言語で見つかることに驚きがあり、社内でも有効に使えそうだという反応をいただきました。
pgvectorの二値量子化、中心化の効果はモデルで変わる
pgvectorの二値量子化で、ベクトルから平均を引く「中心化」を試しました。8モデルを比較した結果、e5ではRecall@10が0.496から0.943へ改善し、snowflakeでは0.959から0.907へ低下しました。同じ前処理でも、モデルによって効果が逆になりました。
Vector Search Checkupでは、ベクトルの方向の偏りや、次元の使われ方を確認できます。今回は、その特徴を検索の設定に生かすため、PostgreSQL上で中心化の有無を比較した結果を紹介します。
PloneとLanceDBを組み合わせるとできること：OSC東京で開発版を初披露します
Ploneの検索にLanceDBを組み合わせるアドオンを開発しています。文章の言葉が一致する検索に加え、意味の近い文章や、検索語に合う画像を探せるようにする取り組みです。10月17日（土）のオープンソースカンファレンス2026 Tokyo/Fallでは、Plone Users Group Japanのブースで開発版を初めて紹介する予定です。
みんなのPython勉強会#123でSAENMについて話します
10月15日（木）のみんなのPython勉強会#123で、SAENM（セーンモデル）について初めて外部で発表します。トークのタイトルは「SAENM — Jupyterで残すPoCの試行錯誤、未来の自分と仲間を助ける記録」です。
「あの比較、前に試したはず」。PoCを進めていると、過去の結果だけでなく、そのとき何を考えて次へ進んだのかを知りたくなることがあります。今回は、そうした試行錯誤を未来の自分と仲間のために残す話をします。
PloneへのLanceDB組み込みで見つけたLanceの検索バグを修正した話
現在、Ploneの検索にLanceDBを組み込む作業を進めています。その中で、メタデータによる絞り込みに一致しないはずのデータが、検索結果に現れる不具合を見つけました。原因はLanceDBの基盤であるLanceのインデックス更新処理にあり、修正を提案したPull Request #9352がマージされ、Lance v13.0.0としてリリースされました。
PyCon JP 2026でベクトル検索を発表し、対話から見えたこと
2026年8月21日から23日まで、広島で開催されたPyCon JP 2026に参加しました。カンファレンスでは、2.3万枚を超える写真を検索するシステムについて発表し、最終日のSprintでは初心者向けのベクトル検索レクチャーを行いました。
今回のPyCon JPは、これまで進めてきた画像検索、ANN、ベクトルの診断、検索品質の評価について、実際に動くものとともに紹介する機会になりました。それ以上に印象に残ったのは、質疑応答、個別相談、オープンスペースを通じて、参加者の皆さんが感じている疑問を直接聞けたことです。
登壇そのものについては、会社公式サイトのPyCon JP 2026登壇報告でも紹介しています。本記事ではCMScomLabとして、会場でどのような対話があり、そこから何が見えたのかを報告します。
ベクトルの特徴を知る「Vector Search Checkup」を公開しました
Embeddingモデルから生成したベクトルは、モデルやデータによって異なる特徴を持っています。その特徴を知らないままベクトルDBや検索方法を選び、量子化を進めてよいのでしょうか。
今回、手元のベクトルをブラウザー上で診断できるVector Search Checkupをβ公開しました。Embedding空間の分布や幾何学的な特徴を数値と図で確認し、次に何を検証するかを考えるためのツールです。
ここでいう「診断」は、ベクトルの良し悪しを判定するものではありません。まず特徴を知り、その結果を手がかりに、用途や制約に合った検索を一緒に作り、改善していくための出発点です。
ベクトルが近いだけでは、良い検索とは限らない
ベクトル検索では、検索文や画像をEmbeddingモデルでベクトルに変換し、近いベクトルを検索結果として取り出します。それでは、最も近いベクトルを正しく取得できれば、良い検索になったと言えるのでしょうか。
ベクトルの近さは重要ですが、それだけで利用者が欲しい結果になるとは限りません。良い検索を作るには、ベクトル空間での近さと、検索結果としての良さを分けて評価する必要があります。
今回は、画像検索を例に、この二つの違いと検索結果の評価方法を整理します。