ブログ & 開発ログ

通常、長期記憶とワーキングメモリの間には常に大きな隔たりがあります。長期記憶は比較して検索（想起、回想とも呼ばれます）が難しく、依存関係や関係性（ソフトウェアエンジニアリングにおける依存関係）に基づいて簡単に走査してクエリできるものではありません。一方、ワーキングメモリの容量は、必要なすべてのコンテンツを効果的に収容するには不十分です。

この問題を解決する一般的な方法は RAG（検索拡張生成）と呼ばれ、これにより任意の大規模言語モデル（テキスト生成モデル）が意味的に関連するコンテキストをプロンプト入力として取得できるようになります。

RAG には通常、ベクトル検索が可能なデータベース（カスタムでは Postgres + pgvector、または SQLite と sqlite-vec、DuckDB と VSS plugin プラグイン、さらには Redis Stack もベクトル検索をサポートしています。クラウドプロバイダーでは Supabase、Pinecone があります）が必要です。ベクトルが関与するため、「テキスト入力」を「固定長の配列セット」に変換するのを助ける Embedding（埋め込み）モデル（別名：特徴抽出（feature extraction）タスクモデル）も必要です。

ただし、この DevLog では、RAG とその一般的な動作原理についてはあまり詳しく説明しません。興味がある方がいれば、絶対に時間を割いて、それに関する素晴らしい専門記事を別の機会に書きたいと思います。

さて、まとめると、このタスクを完了するには2つの材料が必要です：

ベクトル検索が可能なデータベース（別名：ベクトルデータベース）
Embedding モデル（別名：埋め込みモデル）

ベクトルデータベースから始めましょう。

ベクトルデータベース

パフォーマンスとベクトル次元数の互換性の問題（pgvector は2000次元以下しかサポートしていませんが、将来のより大きな埋め込みモデルは現在の一般的なモデルよりも多くの次元を提供する可能性があるため）を考慮して、ベクトルデータベースのバックエンド実装として pgvector.rs を選択しました。

しかし、これは決して簡単なことではありませんでした。

まず、pgvector と pgvector.rs で SQL を使用してベクトル拡張を有効にする構文が異なります：

pgvector:

sql

DROP EXTENSION IF EXISTS vector;
CREATE EXTENSION vector;

pgvector.rs:

sql

DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;

1文字の違いだけだというのはわかっていますが......

しかし、上記の Docker Compose の例のように、pgvector.rs を直接起動し、以下の Drizzle ORM テーブル構造定義を使用してデータベースを生成すると...：

yaml

services:
  pgvector:
    image: ghcr.io/tensorchord/pgvecto-rs:pg17-v0.4.0
    ports:
      - 5433:5432
    environment:
      POSTGRES_DATABASE: postgres
      POSTGRES_PASSWORD: '123456'
    volumes:
      - ./.postgres/data:/var/lib/postgresql/data
    healthcheck:
      test: [CMD-SHELL, pg_isready -d $$POSTGRES_DB -U $$POSTGRES_USER]
      interval: 10s
      timeout: 5s
      retries: 5

そして Drizzle で pgvector.rs インスタンスに直接接続すると：

typescript

export const chatMessagesTable = pgTable('chat_messages', {
  id: uuid().primaryKey().defaultRandom(),
  content: text().notNull().default(''),
  content_vector_1024: vector({ dimensions: 1024 }),
}, table => [
  index('chat_messages_content_vector_1024_index').using('hnsw', table.content_vector_1024.op('vector_cosine_ops')),
])

次のようなエラーが発生します：

ERROR: access method "hnsw" does not exist

幸いなことに、これは解決可能です。ERROR: access method "hnsw" does not exist の提案を参考に、vectors.pgvector_compatibility システムオプションを on に設定するだけです。

当然、コンテナの起動時にベクトル空間に関連するオプションを自動的に設定したいので、docker-compose.yml 以外のディレクトリに init.sql を作成できます：

sql

ALTER SYSTEM SET vectors.pgvector_compatibility=on;

DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;

そして init.sql を Docker コンテナにマウントします：

yaml

services:
  pgvector:
    image: ghcr.io/tensorchord/pgvecto-rs:pg17-v0.4.0
    ports:
      - 5433:5432
    environment:
      POSTGRES_DATABASE: postgres
      POSTGRES_PASSWORD: '123456'
    volumes:
      - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql # Add this line
      - ./.postgres/data:/var/lib/postgresql/data
    healthcheck:
      test: [CMD-SHELL, pg_isready -d $$POSTGRES_DB -U $$POSTGRES_USER]
      interval: 10s
      timeout: 5s
      retries: 5

Kubernetes デプロイメントの場合、プロセスは同じですが、ファイルをマウントする代わりに ConfigMap を使用します。

よし、これでその問題は基本的に解決しました。

では、埋め込みベクトルについて話しましょう。

埋め込みモデル

ご存知かもしれませんが、私たちは 🥺 SAD（Self-hosted AI Documentation）という別のドキュメントサイトを立ち上げました。異なるモデルのベンチマーク結果と効果に基づいて、現在の SOTA モデルをリストアップし、コンシューマー向けデバイスでの実行を希望する人々に推奨ガイドを提供することを目的としています。埋め込みモデルはその中でも最も重要な部分です。ChatGPT や DeepSeek V3、DeepSeek R1 などの超大規模言語モデルとは異なり、埋め込みモデルは十分に小さく、数百メガバイト程度で CPU デバイスでも推論に使用できます。（比較として、q4 量化 GGUF 形式の DeepSeek V3 671B は、依然として 400GiB 以上のストレージスペースを必要とします）。

しかし、🥺 SAD はまだ建設中なので、今日（4月6日）時点で最新かつ最もホットな埋め込みモデルをいくつか選んで推奨します：

オープンソースおよびプロプライエタリモデルのランキング：

既視感

前日の開発配信で、AIRI のための基本アニメーションとトランジション効果の制作の進捗状況をお見せしました。

主な目標は、@yui540 の素晴らしい作品を移植し、再利用可能な Vue コンポーネントとして適応させることで、どんな Vue プロジェクトでもこれらの美しいアニメーション効果を簡単に使えるようにすることでした。

yui540 に関する詳細情報や関連する引用ライブラリ、作業内容は、新しくデプロイされたドキュメントサイトにまとめられています： https://airi.build/references/design-guidelines/resources/。

最終的な移植結果はかなり良く、以下にデプロイされています： https://proj-airi-packages-ui-transitions.netlify.app/#/。

また、これからは各パッケージのすべてのプレイグラウンドが "proj-airi" + "${subDirectory}" + "${packageName}" というパターンで Netlify にデプロイされるようになります。

前日の主な目標は CSS の実装を Vue コンポーネントに分割することでしたが、実際の再利用性の部分はまだ完全には実現されていません。他のページでも便利に使えるように、柔軟かつ拡張可能なワークフローとメカニズムを設計する必要があります。

日中

unplugin-vue-router が提供する definePage マクロフックを試してみたところ、私の使用シナリオに非常に適していることがわかったので、この方向で探索を続けることにしました。

https://cowardly-witch.netlify.app/ からさらに3つの新しいアニメーション・トランジション効果を移植しました。これらはすでに https://proj-airi-packages-ui-transitions.netlify.app/#/ で利用可能です。

昨日、公式ドキュメントサイトを https://airi.build にデプロイしましたが、@kwaa から https://airi.more.ai/docs の方法を試してみてはどうかというコメントをもらいました。~~しかし、/docs のために 200 リダイレクトプロキシを設定する方法が思いつきませんでした。~~

編集：最終的にその方法を学びました。将来の開発ログに詳細を含める予定です。

試してみましたが、約10回のコミットを費やして CI/CD パイプラインと格闘しました（はい、またです）が、結局正常に動作させることはできませんでした。

今日の遅くには、いくつかの技術や DeepSeek チームが1週間前に公開したオープンソースリポジトリ、そしていわゆる ByteDance が公開した LLM ゲートウェイ AIBrix について調査しました。また、新しくリリース・発表された Phi-4-mini が AIRI で使用するために移植可能かどうかも研究しています。良いニュースは、[Phi-4-mini](https://techcommunity.microsoft.com/blog/educatordeveloperblog/welcome-to-the-new-phi-4-models