ブラウザ検索 × VPS生成
ハイブリッドRAGを本番投入する

この三部作は、「AIコンシェルジュをどこまでブラウザで動かせるか」を追ってきた。 前編・後編で各部品を実機で検証した結果、答えははっきり分かれた。

この記事は、その設計を実際に本番サイト （sasagawa.tokyo のAIコンシェルジュ）へ投入するまでの全記録である。 すでに存在していたVPS完結型RAGを、どう最小の変更でハイブリッド化したか。 そして途中で踏んだ失敗をどう直したか。

出発点は、ConoHa VPS（2GB RAM / CPUのみ）で動く既存のRAGだった。 ブラウザは表示だけで、検索も生成もすべてVPSが担っていた。

// ブラウザ --WebSocket--> ws_server --RabbitMQ--> consumer.py
async def handle_query(payload):
    contexts = await retrieve(question)   # ① e5埋め込み + ChromaDB検索（VPS）
    contexts = trim_contexts(contexts)     # ② トークン調整
    prompt   = build_prompt(question, contexts)
    for token in llm(prompt, stream=True): # ③ llama.cpp 生成
        send(token)

変更後のアーキテクチャはこうなる。検索がブラウザに移り、VPSは生成に専念する。 3つの層——ブラウザ・Producer・Consumer——の責務が明快に分かれる。

実装の前に、絶対に確かめるべきことがあった。 ブラウザのe5（Transformers.js）とVPSのe5（sentence-transformers）が、 同じテキストに同じベクトルを返すか。 ここがズレると、ブラウザ検索の結果がサーバー版と変わってしまう。

VPS側で、ChromaDBの全チャンクを kb.json として書き出す。 既存の記事更新関数 add_articles() の末尾に1行足すだけで、 scrape / rescrape などすべての更新フローに乗る。

def export_vector_json(collection, model, cfg):
    data = collection.get(include=["metadatas", "embeddings"])
    # documents(本文)は含めない = ブラウザに本文を出さない
    chunks = []
    for cid, meta, emb in zip(data["ids"], data["metadatas"], data["embeddings"]):
        chunks.append({
            "id":    cid,                      # "url#chunkN"
            "title": meta["title"],
            "url":   meta["url"],
            "vec":   [round(float(x), 6) for x in emb],  # fp32ベクトル
        })
    # アトミック書き込み（一時ファイル→rename）で配信中を壊さない

公開UIの AIConcierge クラスに検索モジュールを足す。 既存の受信処理は一切変えず、送信だけを差し替える。

async sendMessage() {
  // ハイブリッド: ブラウザで検索できるなら
  if (this.searchReady) {
    const hits = await this.search.search(text, topK);
    this.showContextPreview(hits);   // 参照文書を即表示（体感UP）
    this.ws.send(JSON.stringify({
      action: "generate", question: text,
      chunk_ids: hits.map(h => h.id),   // ← idだけ。本文は送らない
    }));
    return;
  }
  // フォールバック: 従来のサーバー検索
  this.ws.send(JSON.stringify({ action: "query", question: text }));
}

Consumer側は handle_generate を新設。 既存の handle_query と違うのは文書の入手方法だけ。 検索（retrieve）を呼ばず、idからDBを引く。

# handle_query（既存）
contexts = await retrieve(question)        # VPSが埋め込み+検索

# handle_generate（新規）
got = collection.get(ids=chunk_ids,           # DBから直接取得（埋め込み不要）
                     include=["documents", "metadatas"])
# get()は順序不保証 → chunk_idsの順（類似度順）に並べ直す
id2idx = {cid: i for i, cid in enumerate(got["ids"])}
contexts = [... for cid in chunk_ids if cid in id2idx]
# 以降（trim/プロンプト/ストリーム/ログ）は handle_query と完全に同一

設計通りには進まなかった。本番投入までに3つの落とし穴を踏み、そのたびに直した。 これらは実装で最も学びの多い部分だ。

3つの落とし穴を越え、ハイブリッドRAGは本番で動いた。 「資本回収係数とは」と尋ねると、ブラウザがiseeit.jpのFP用語記事を正しく検索し、 VPSがその本文を根拠に正確な回答を生成する。検索も生成も、意図通りに繋がった。