4BパラメータのオープンモデルがGPT-5.6 Solに並ぶ日 ― Castform × Neon Lakebaseで実現するRAGコスト1/100

メタディスクリプション: 40億パラメータのオープンモデルが、RL学習とエージェント型検索でGPT-5.6 Sol同等の精度を1/100のコストで達成。Castformのアーキテクチャ、Neon Lakebase Postgresの役割、コスト試算方法まで解説します。

はじめに：RAGのコストは「モデル選び」で9割決まる

「RAGを本番に乗せたら月のAPI代が想定の5倍になった」――自社データを活用したAIシステムを構築したエンジニアの多くが、一度は経験する悩みです。検索精度を上げようとマルチターンの問い合わせを実装すると、1リクエストあたりのトークン消費量が跳ね上がる。フロンティアモデルへの依存は、コストだけでなくレイテンシとベンダーロックという二重の重荷を組織にもたらします。

フロンティアモデル依存が生む3つの痛み

①コスト：GPT-5.6 Solのような最新フロンティアモデルは、シングルホップなら許容できる価格帯でも、マルチターン検索を伴うRAGでは1リクエストあたりのコストが急激に膨らみます。「精度のためにマルチホップを実装したら、コストが10倍になった」というケースは決して珍しくありません。

②レイテンシ：巨大モデルはトークン生成速度の問題だけでなく、API呼び出しのネットワーク遅延も蓄積します。マルチターン検索では1回の問い合わせで10秒を超えることも珍しくなく、UXに直結する問題として設計者を悩ませます。

③ベンダーロック：OpenAIやAnthropicのAPIに深く依存したシステムは、モデルのバージョンアップや価格改定、さらには2026年6月のGPT-4引退のような突然の変更に無防備です。プロンプトの調整、出力フォーマットの再設計、コスト構造の見直しを繰り返す「アップグレード地獄」は、エンジニアリングリソースを大量に消費します。

「小さいモデルは検索が下手」という定説が崩れた

これまで、小規模なオープンソースモデルをRAGに使う際の最大の課題は検索の質でした。具体的には「1回の検索で情報が足りなくても追加検索をしない」「複数のソースをまたぐ複合的な質問（マルチホップ）に弱い」「いつ検索を打ち切るべきかを判断できない」といった問題が指摘されてきました。

この定説を根本から覆したのが、Castform社とNeonが共同で実証した成果です。強化学習（RL）によるポストトレーニングとPostgreSQLネイティブの検索基盤を組み合わせることで、4Bパラメータのオープンモデルが金融検索タスクにおいてGPT-5.6 Solと同等、一部のタスクではGPT-5.2を約35%上回る精度を、1/100のコストで達成しました。

本記事でわかること

本記事では以下の内容を段階的に解説します。

• Castformのアーキテクチャ：3つの構成要素とRLがもたらす能力変化
• Neon Lakebase Postgresの技術的役割：なぜ「PostgreSQL1本」でRL訓練まで賄えるのか
• フロンティアモデルとの定量比較：コスト・レイテンシ・精度の三軸
• 自社データへの適用ステップと、移行コストの現実的な見積もり方
• 損益分岐点の試算方法

結論サマリー：1/100のコストで同等精度は何が可能にしたのか

詳細に入る前に、結論を3行でまとめておきます。

1. オープンソースの小規模モデル（4B）に強化学習でポストトレーニングを施すことで、「自律的に複数回検索を繰り返す」能力を獲得させます。

2. NeonのLakebase Postgresがドキュメント格納・RL訓練データ生成・訓練中の並列検索負荷吸収を一手に担い、外部のベクトルDBを不要にします。

3. 結果として推論コストが約1/100に下がりながら、ドメイン特化タスクではフロンティアモデルを上回る精度を実現します。

数字で見ると、Pass@8（8回の試行で正答に到達できる確率）が訓練期間中に約63%向上し、GPT-5.6 Solと同等の水準に達します。重要なのは「汎用的な何でも知っているモデル」ではなく「特定ドメインの検索・回答に特化したモデル」として設計するという発想の転換です。

誰に有効で、誰には向かないのか：自社の特定ドメイン（金融、法務、製造業の社内ナレッジ、医療など）に特化したRAGを運用しており、月間リクエスト数が一定規模以上あるケースで最も効果的です。逆に、汎用的なチャットボットや多様なタスクをこなす必要があるシステム、あるいは月数千リクエスト程度の小規模利用では、RL訓練の初期投資に対するROIが出にくい場合があります。

Castformのアーキテクチャ ― 「MLの専門知識なしでRL」を成立させる仕組み

Castformとは

Castformは、オープンソースのLLMを強化学習でポストトレーニングするためのプラットフォームです。従来、RLによるLLMの微調整はPPO（Proximal Policy Optimization）などのアルゴリズムに精通したMLエンジニアが必要でした。Castformはこのプロセスを抽象化し、「プロンプトエンジニアリングと同程度の手軽さでRL」を実現することをポジショニングとして掲げています。

アーキテクチャの核心は3つの構成要素に分解されます。

構成要素①：タスク定義 ― 社内データからQ&Aペアを自動生成する

RL訓練において最初のボトルネックになるのが学習データの調達です。通常の教師あり学習であれば、大量の「質問→正解回答」ペアを人手でアノテーションする必要があります。Castformはこのコストを根本から変えます。

既存の社内ドキュメント（PDFマニュアル、Confluenceページ、Notionドキュメント、Markdownファイルなど）をそのまま入力として、Q&Aペアを自動生成します。重要なのは、これが「正解回答のラベル付き」データである必要がないという点です。RL訓練では「報酬関数」が正解・不正解の判断を担うため、入力となる質問群さえあれば学習を開始できます。

# 必要パッケージ: pip install anthropic pypdf
import json
import re
from pathlib import Path

import anthropic
from pypdf import PdfReader


class DocumentCorpus:
    """ドキュメントコーパスクラス"""

    def __init__(self, documents: list[dict]):
        self.documents = documents

    @classmethod
    def from_files(cls, file_paths: list[str]) -> "DocumentCorpus":
        documents = []
        for path in file_paths:
            p = Path(path)
            if not p.exists():
                print(f"Warning: {path} not found, skipping.")
                continue
            if p.suffix.lower() == ".pdf":
                reader = PdfReader(str(p))
                text = "\n".join(page.extract_text() or "" for page in reader.pages)
            else:
                text = p.read_text(encoding="utf-8")
            documents.append({"source": str(p), "content": text})
        return cls(documents)


class Task:
    """Q&Aペア生成タスク"""

    def __init__(self, qa_pairs: list[dict]):
        self.qa_pairs = qa_pairs

    @classmethod
    def from_corpus(
        cls,
        corpus: DocumentCorpus,
        num_questions: int = 1000,
        question_style: str = "factoid",
        language: str = "ja",
    ) -> "Task":
        client = anthropic.Anthropic()
        qa_pairs: list[dict] = []
        questions_per_doc = max(1, num_questions // max(len(corpus.documents), 1))

        style_desc = {
            "factoid": "事実を問う単純な質問",
            "multi_hop": "複数のステップを要する複雑な質問",
            "comparison": "比較・対照を求める質問",
        }.get(question_style, "事実を問う単純な質問")

        lang_desc = "日本語" if language == "ja" else "English"

        for doc in corpus.documents:
            content = doc["content"][:4000]  # トークン制限のためトリミング
            prompt = (
                f"以下のドキュメントから{lang_desc}で{style_desc}を{questions_per_doc}個生成し、"
                f"各質問に対する回答も含めてください。\n"
                f'JSON配列形式で出力してください: [{{"question": "...", "answer": "..."}}]\n\n'
                f"ドキュメント:\n{content}"
            )
            message = client.messages.create(
                model="claude-opus-4-5",
                max_tokens=2048,
                messages=[{"role": "user", "content": prompt}],
            )
            raw = message.content[0].text
            match = re.search(r"\[.*\]", raw, re.DOTALL)
            if match:
                try:
                    pairs = json.loads(match.group())
                    for pair in pairs:
                        pair["source"] = doc["source"]
                    qa_pairs.extend(pairs)
                except json.JSONDecodeError:
                    pass

        return cls(qa_pairs)


# 既存ドキュメントをそのまま投入
corpus = DocumentCorpus.from_files([
    "docs/product_manual.pdf",
    "docs/faq.md",
    "docs/technical_specs.pdf"
])

# Q&Aペアを自動生成
task = Task.from_corpus(
    corpus=corpus,
    num_questions=1000,
    question_style="factoid",  # または "multi_hop", "comparison"
    language="ja"
)

この設計の実用的な意味は大きく、アノテーションコストがほぼゼロになります。従来、1,000件の高品質Q&Aペアを人手で作成するには数十万〜数百万円のコストがかかりましたが、自動生成により初期投資の大半を削減できます。

構成要素②：環境 ― モデルに「検索ツール」を持たせる

RLの「環境（Environment）」とは、エージェント（モデル）が行動を取り、その結果をフィードバックとして受け取る場のことです。Castformの環境は、モデルに知識ベースへの検索ツールを提供します。

ここで注目すべき設計判断が、訓練時の検索エンジンにBM25を採用している点です。ベクトル検索（dense retrieval）ではなく、古典的なキーワード検索アルゴリズムであるBM25を選んだ理由はRL訓練中のノイズ低減にあります。

ベクトル検索は意味的類似性を捉える能力が高い反面、訓練中にモデルのクエリ生成能力が変化するたびに検索結果のばらつきが大きくなり、報酬信号が不安定になります。BM25はキーワードマッチングベースのため結果が決定論的で、訓練の安定性を確保しやすいのです。実際の推論時（本番環境）では、ベクトル検索とのハイブリッド構成を取ることも可能です。

構成要素③：報酬関数 ― 3指標で「良い検索」を定義する

報酬関数は、モデルの行動（検索クエリの発行、最終回答の生成）を評価する基準です。Castformでは以下の3軸で評価します。

① 検索精度（Retrieval Precision）：発行した検索クエリが、正解を含むドキュメントを的確に取得できたか。不要なドキュメントを多数取得する「ノイジーな検索」にはペナルティが与えられます。

② 引用品質（Citation Quality）：生成した回答が、実際に取得したドキュメントの内容に忠実かどうか。いわゆる「ハルシネーション」を検出する指標です。LLMをジャッジとして利用し、「この回答はソースから支持されているか」を自動評価します。

③ 回答正確性（Answer Correctness）：最終的な回答が、参照ドキュメントを踏まえて正確かどうか。

これら3指標の組み合わせに加え、Pass@8メトリクスを採用しています。Pass@8とは「同一の質問に対して8回の独立した試行を行ったとき、少なくとも1回正解できる確率」を指します。コード生成分野で広く使われるPass@kメトリクスをRAGに応用したものです。

# 必要パッケージ: pip install anthropic
import re

import anthropic


def compute_retrieval_precision(retrieved: list[str], relevant: list[str]) -> float:
    """検索精度（Precision@K）を計算する"""
    if not retrieved:
        return 0.0
    relevant_set = set(relevant)
    hits = sum(1 for doc in retrieved if doc in relevant_set)
    return hits / len(retrieved)


def llm_judge_citation(answer: str, sources: list[str]) -> float:
    """LLMを使って回答の引用品質を評価する（0.0〜1.0）"""
    client = anthropic.Anthropic()
    sources_text = "\n---\n".join(sources[:5])  # ソース数を制限
    prompt = (
        "以下の回答がソースに基づいているか評価してください。\n"
        "0.0（全く根拠なし）から1.0（完全に根拠あり）のスコアを数値のみで返してください。\n\n"
        f"ソース:\n{sources_text}\n\n"
        f"回答:\n{answer}"
    )
    message = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=16,
        messages=[{"role": "user", "content": prompt}],
    )
    try:
        score = float(re.search(r"[0-9.]+", message.content[0].text).group())
        return max(0.0, min(1.0, score))
    except (AttributeError, ValueError):
        return 0.0


def compute_answer_accuracy(prediction: str, reference: str) -> float:
    """回答の正確性をトークンF1スコアで計算する"""
    pred_tokens = set(prediction.lower().split())
    ref_tokens = set(reference.lower().split())
    if not pred_tokens or not ref_tokens:
        return 0.0
    common = pred_tokens & ref_tokens
    precision = len(common) / len(pred_tokens)
    recall = len(common) / len(ref_tokens)
    if precision + recall == 0:
        return 0.0
    return 2 * precision * recall / (precision + recall)


def compute_reward(
    query: str,
    retrieved_docs: list[str],
    generated_answer: str,
    ground_truth_docs: list[str],
    ground_truth_answer: str
) -> float:
    # ① 検索精度
    retrieval_score = compute_retrieval_precision(
        retrieved=retrieved_docs,
        relevant=ground_truth_docs
    )
    
    # ② 引用品質（LLMジャッジ）
    citation_score = llm_judge_citation(
        answer=generated_answer,
        sources=retrieved_docs
    )
    
    # ③ 回答正確性
    accuracy_score = compute_answer_accuracy(
        prediction=generated_answer,
        reference=ground_truth_answer
    )
    
    # 加重平均
    return 0.3 * retrieval_score + 0.3 * citation_score + 0.4 * accuracy_score

学習エンジン：安定性を優先したDPPO（Distributed PPO）の採用理由

RL訓練のアルゴリズムとして、CastformはDPPO（Distributed Proximal Policy Optimization）を採用しています。近年のLLM向けRLではGRPO（Group Relative Policy Optimization）やDPO（Direct Preference Optimization）なども使われますが、DPPOを選んだ主な理由は訓練の安定性です。

大規模な並列ロールアウト（モデルに複数の検索行動を実行させてデータを収集するプロセス）を伴うエージェント型のRL訓練では、勾配の爆発や方策の崩壊が起きやすくなります。PPOの「更新幅を制限する」という本来の設計思想が、このような不安定なシナリオで真価を発揮します。

RL学習で何が変わるのか ― 「1回検索して終わり」からの脱却

訓練前の小規模モデルの限界

RL訓練を受けていない4BモデルをそのままナイーブなRAGに使うと、典型的な問題が現れます。「Aという製品の2024年第4四半期の売上を、競合他社Bの同期売上と比較した場合の差異は？」のような質問に対し、モデルは最初の1回の検索で取得したドキュメントだけで回答を生成しようとします。情報が不完全でも「足りない」と認識できず、根拠の薄い回答を自信を持って出力してしまいます。

訓練後に獲得する2つの判断力

RL訓練を経ると、モデルは根本的に異なる行動パターンを示します。

① 情報が足りなければ自律的に再検索する（マルチホップ）

上記の例では、訓練済みモデルは「製品Aの売上データ」を検索した後、「まだ競合他社Bのデータが取得できていない」と認識し、追加の検索クエリを自律的に発行します。この「検索→評価→再検索」のループを、必要な情報が揃うまで繰り返します。

② 情報が揃ったら検索を打ち切る

これは見落とされがちな重要な能力です。無限に検索を続けるモデルは、コストとレイテンシの観点から実用に耐えません。訓練済みモデルは「これ以上の検索は不要」という判断を下し、適切なタイミングで最終回答の生成に移行します。報酬関数が「不必要な検索行動」にペナルティを与えることで、この判断力が獲得されます。

エージェント型検索（Agentic Retrieval）とは何か

従来のRAGアーキテクチャは、概念的には以下のようなシーケンシャルなパイプラインです。

ユーザークエリ → 検索（1回） → 取得ドキュメント → LLM回答生成 → 出力

これに対し、Castformが実装するエージェント型検索は動的なループ構造を持ちます。

ユーザークエリ 
    ↓
[エージェントのターン開始]
    → 検索クエリ生成
    → 知識ベース検索
    → 取得結果の評価
    → 「情報十分？」 
        → Yes: 最終回答生成 → 出力
        → No: 新しい検索クエリ生成 → 繰り返し

この構造的な違いが、複合的な質問への回答精度を飛躍的に向上させます。

定量的な成果

Neonのブログで公開されたデータによると、RL訓練期間中にPass@8メトリクスが約63%向上しました。金融検索タスクのベンチマークでは、訓練済みの4BモデルがGPT-5.2を約35%上回る精度を達成しています。GPT-5.6 Solとの比較では同等水準を実現しており、コスト差（後述の1/100）と組み合わせると、費用対効果の優位性は圧倒的です。

研究トレンドとの接続

この方向性は学術界でも活発に研究されています。Search-R1（Reinforcement Learning for Search-Augmented Reasoning）やMARAG-R1（Multi-Agent RAG with RL）といった研究が、小規模モデルへのRL適用による検索能力向上を実証しており、Castformの実装はこれらの知見と軌を一にしています。2026年現在、「小さくて賢いモデルをドメインに特化させる」というアプローチは、研究と産業実装の両面で急速に成熟しつつあります。

フロンティアモデルとの徹底比較 ― コスト・レイテンシ・精度

比較表

コスト：なぜ1/100まで下がるのか

コスト削減の算数は単純です。パラメータ数 × トークン量 × マルチターン回数の掛け算が推論コストを決めます。

• パラメータ数：GPT-5.6 Solは推定で数千億〜兆パラメータ規模。4Bモデルはその1/100〜1/1000以下。
• トークン量：フロンティアAPIはトークン単価がそもそも高い。4Bモデルをセルフホストすればトークン単価は劇的に下がります。
• マルチターン回数：エージェント型検索で複数回のLLM呼び出しが発生する場合、各呼び出しのコストが積み上がります。小さいモデルはこの「積み上がり」のベースが低い。

月10万リクエスト、平均3ターンの検索を想定した場合：

• GPT-5.6 Sol：$0.03 × 3 × 100,000 = $9,000/月
• Castform + 4B（セルフホスト）：GPU費用を含めても $90〜$500/月程度

この差はスケールするほど広がります。

レイテンシ：マルチターン検索で10秒超が積み上がる構造

GPT-5.6 Solのような大規模APIは、1回の呼び出しで数秒のレスポンスタイムが発生します。マルチホップ検索で3ターン呼び出すと、それだけで10〜15秒のレイテンシになります。これはエンドユーザーへの影響だけでなく、検索→評価→再検索というループのスループットにも直接影響します。

4Bモデルをローカルまたは近傍のクラウドで推論する場合、1ターンあたり1〜2秒程度に抑えられるケースが多く、同じ3ターンでも3〜6秒のレイテンシで完了します。

精度：汎用性能とドメイン特化性能を混同しない

重要な注意点として、「4Bモデルがフロンティアモデルを上回る」はドメイン特化タスクにおいての話です。数学オリンピックの問題を解く、複数の外国語を流暢に扱う、コードのゼロショット生成などの汎用タスクでは、依然としてフロンティアモデルに軍配が上がります。

Castformのアプローチは「特定ドメインの検索・回答」という明確に定義されたタスクに特化することで、汎用的な大規模モデルを上回る専門性を獲得します。これは「スペシャリストがジェネラリストを特定分野で上回る」という当然の原理です。

2026年のAIコスト事情

GPT-4が2026年6月に正式引退し、後継モデルへの移行が進む中も、フロンティアモデルの価格は下落傾向にあります。しかし「下がってはいるが、4Bセルフホストとの差は依然として大きい」というのが現状です。むしろ、フロンティアモデルの価格競争が激化するほど、ユーザーへの「乗り換え圧力」が高まり、システムの維持コストが予測困難になるという逆説的な問題も生じています。

Neon Lakebase Postgresの役割 ― RAG基盤を1つのDBに集約する

Lakebase Searchの正体

NeonのLakebase Searchは、PostgreSQLの拡張として提供される2つのモジュールで構成されます。

• lakebase_vector：高性能なベクトル類似検索（HNSW/IVFFlatインデックス対応）
• lakebase_text：BM25ベースの全文検索

この2つをPostgreSQL上で統合することで、「ドキュメント格納 → ベクトル化 → 検索 → RL訓練データ生成」をすべて同一のデータベース上で完結させます。

役割①：生ドキュメントをそのままPostgreSQLに格納する

-- pgvectorを使ったベクトル検索と全文検索の初期設定例
-- 必要な拡張: pgvector (pip install pgvector, または apt install postgresql-<ver>-pgvector)
CREATE EXTENSION IF NOT EXISTS vector;

-- ドキュメントテーブルの作成
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    title TEXT NOT NULL,
    content TEXT NOT NULL,
    source_file TEXT,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    -- ベクトル埋め込み（1536次元の例）
    embedding VECTOR(1536),
    -- 全文検索用のtsvector
    -- 注意: 日本語には 'simple' を使用。本格的な日本語検索には pg_bigm 拡張を推奨
    search_vector TSVECTOR GENERATED ALWAYS AS (
        to_tsvector('simple', title || ' ' || content)
    ) STORED
);

-- HNSWインデックスの作成（pgvectorによる高速ベクトル検索）
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- 全文検索用GINインデックス
CREATE INDEX ON documents USING gin(search_vector);

従来のRAGシステムでは「PostgreSQLでドキュメントを管理し、Pineconeでベクトルを管理し、Elasticsearchでキーワード検索する」という三重構成が一般的でした。Lakebase Searchはこの分散を解消し、単一のPostgreSQLインスタンスで全機能を賄います。運用の複雑さが大幅に減り、一貫したトランザクション保証のもとでデータを扱えます。

役割②：合成データ生成 ― SQL関数でRL訓練データを作る

-- SQL関数でRL訓練用Q&Aペアを生成
CREATE OR REPLACE FUNCTION generate_training_pairs(
    doc_id INTEGER,
    num_pairs INTEGER DEFAULT 5
)
RETURNS TABLE (
    question TEXT,
    relevant_doc_ids INTEGER[],
    difficulty TEXT
) AS $$
BEGIN
    -- lakebase_text関数を使って関連ドキュメントを特定し
    -- 多様な難易度のQ&Aペアを自動生成
    RETURN QUERY
    SELECT 
        generated_question,
        ARRAY[doc_id] || related_ids,
        question_difficulty
    FROM lakebase_text.generate_qa_pairs(
        doc_id := doc_id,
        count := num_pairs,
        include_multi_hop := true
    );
END;
$$ LANGUAGE plpgsql;

-- 全ドキュメントに対してトレーニングデータを生成
SELECT * FROM generate_training_pairs(id, 10)
FROM documents
WHERE source_file IS NOT NULL;

役割③：RL訓練の負荷を吸収する

RL訓練におけるロールアウトフェーズでは、複数のモデルインスタンスが同時に検索を実行し、そのデータを収集します。訓練規模によっては1分間に数千件の並列検索クエリが発行されます。

NeonのLakebase Postgresは、オートスケール機能でこの突発的な負荷を吸収します。通常のデータベースでは「訓練用のピーク負荷に合わせてプロビジョニングすると、通常時にコストが無駄になる」というジレンマが生じますが、Neonはアクティブな接続数と実際の負荷に応じて自動でスケールするため、このトレードオフを解消します。

RL訓練中の検索負荷イメージ:

ロールアウト開始 → [並列クエリ急増] → Neonが自動スケールアップ
ロールアウト終了 → [負荷低下]      → Neonが自動スケールダウン

役割④：ブランチング ― ロールアウト間の干渉を防ぐ隔離環境

Neonのユニークな機能としてデータベースブランチングがあります。Gitのブランチのように、データベースの状態を瞬時にコピー（実際にはcopy-on-writeで軽量）し、独立した環境を作ることができます。

RL訓練では複数のロールアウトが同時進行するため、あるロールアウトが書き込んだデータが別のロールアウトの検索結果に干渉すると、報酬信号が汚染されます。ブランチングにより各ロールアウトを完全に隔離された環境で実行でき、訓練の再現性と品質を確保します。

-- ブランチングの概念的な利用例
-- （Neon APIを通じて操作）

-- ロールアウト1用のブランチ作成
neon branch create --name rollout_epoch5_run1

-- ロールアウト2用のブランチ作成（同じ親から）
neon branch create --name rollout_epoch5_run2

-- 各ロールアウトが独立した環境で検索・書き込みを実行
-- 訓練終了後にブランチを破棄
neon branch delete rollout_epoch5_run1
neon branch delete rollout_epoch5_run2

パフォーマンス指標

• スケール：10億ベクトルまでのスケーリングに対応
• HNSWインデックスビルド速度：標準的なPostgres拡張（pgvector等）と比較して50〜100倍高速
• ハイブリッド検索：ベクトル検索とBM25のスコアをRRF（Reciprocal Rank Fusion）で統合

自社データで試すには ― 導入ステップと移行コスト

ステップ1：対象ユースケースの選定

まず「どのドメインの、どういった質問に答えるシステムか」を明確に定義します。Castformのアプローチが最も効果を発揮するのは以下のような特徴を持つユースケースです。

• ドメインが明確に定義されている（金融規制、製品マニュアル、社内規定など）
• マルチホップが必要な質問が多い（「AとBを比較して」「AがBに与える影響は」など）
• 回答の根拠となるソースドキュメントが存在する（ハルシネーションを評価できる）
• 月間リクエスト数が数千件以上ある（RL訓練コストを回収できる規模）

ステップ2：既存ドキュメントの棚卸しとQ&Aペア自動生成

既存ドキュメントをLakebase Postgresに投入し、自動Q&A生成を実行します。生成されたQ&Aペアの中から100〜200件をサンプリングして人手で品質確認し、「明らかに不適切なもの」を除外するフィルタリングを行います。全件確認は不要で、このサンプリングチェックが現実的なバランスです。

# ドキュメント投入とQ&A生成のサンプル
import neon
from castform import DataPipeline

# Neon Lakebase Postgresに接続
db = neon.connect(connection_string=NEON_CONNECTION_STRING)

# ドキュメントを格納しながらベクトル化
pipeline = DataPipeline(db=db)
pipeline.ingest_documents(
    directory="./company_docs",
    file_types=[".pdf", ".md", ".txt"],
    embedding_model="multilingual-e5-large"  # 多言語対応モデル
)

# Q&Aペアを自動生成
qa_pairs = pipeline.generate_qa_pairs(
    num_pairs=2000,
    include_multi_hop=True,
    difficulty_distribution={"easy": 0.3, "medium": 0.5, "hard": 0.2}
)

print(f"生成されたQ&Aペア数: {len(qa_pairs)}")

ステップ3：報酬関数の設計とベースライン測定

デフォルトの報酬関数をそのまま使うことも可能ですが、ドメイン特性に合わせたカスタマイズで精度が大きく改善するケースがあります。例えば、法務文書では「引用の正確性」の重みを高める、金融では「数値の正確性」を専用指標として追加するなどです。

RL訓練を開始する前に、未訓練の4Bモデルでベースライン測定を行います。どの種類の質問が弱いのかを把握することで、訓練後の改善を定量的に評価できます。

ステップ4：小規模ロールアウトでのA/B評価

初回の訓練は小規模（Q&Aペア200〜500件、数エポック）で試し、Pass@8の改善傾向を確認します。改善が見られたら規模を拡大し、本番相当の評価セット（理想的には人手で作成した100〜200件のゴールドセット）で最終評価します。

既存RAGパイプラインからの移行コスト

流用できる資産：

• 既存のドキュメントコーパス（前処理済みであれば再利用しやすい）
• 既に用意している評価セット
• アプリケーション層のロジック（LLMを呼び出す部分のインターフェース）

作り直しが必要な箇所：

• 検索レイヤー（Pinecone/Weaviateなどから Lakebase Postgresへの移行）
• モデルサービング基盤（OpenAI API呼び出しからローカル推論への変更）
• モニタリング・ログ収集（推論サーバーのメトリクスを自前で収集する必要がある）

移行工数の目安として、エンジニア1〜2名で1〜2ヶ月程度が一般的な見積もりです。ただしドキュメント数や既存システムの複雑さによって大きく変わります。

コスト削減効果の試算方法 ― 自社ケースに数字を当てはめる

試算に必要な4変数

1. 月間リクエスト数（R）：エンドユーザーからの質問数
2. 平均ターン数（T）：1リクエストあたりのLLM呼び出し回数（マルチホップ考慮）
3. 平均トークン数（K）：1ターンあたりの入出力トークン合計
4. 単価（P）：1,000トークンあたりのコスト

計算例：月10万リクエストのケース

■ GPT-5.6 Sol を使う場合
R = 100,000
T = 3（マルチホップ平均3ターン）
K = 2,000トークン/ターン
P = $0.005 / 1,000トークン（推定）

月額コスト = 100,000 × 3 × 2,000 × $0.005 / 1,000
          = $3,000 / 月

■ Castform + 4B モデル（セルフホスト）の場合
GPU推論コスト（A100 1枚、スループット考慮）:
- オンデマンド: 約$3/時間
- 月720時間: $2,160

ただし4Bモデルは大幅に高スループット。
同じR=10万リクエスト, T=3をA100 1枚で処理すると仮定：
実際のGPU稼働時間は大幅に少なくなる。

現実的な概算: $100〜$500/月（モデルサイズとスループットによる）

■ コスト削減額
$3,000 - $300（中間値）= $2,700/月
= 年間 $32,400 の削減

見落としがちなコスト

• RL訓練の初期投資：GPU時間で数十〜数百ドル（規模による）
• 再訓練コスト：ドキュメントが大幅に更新された際の定期的な再訓練
• エンジニアリング工数：移行・運用のための人件費
• インフラ管理：セルフホスト推論サーバーの監視・メンテナンス

損益分岐点はどこか

RL訓練の初期投資を$500（小規模）〜$5,000（大規模）と仮定した場合、月間のコスト削減効果が$500以上あれば1〜10ヶ月で回収できます。月10万リクエストのケースでは数ヶ月以内に損益分岐点を超え、以降は純粋なコスト削減として積み上がります。「使うほど得をする」構造は、大規模な本番運用で特に効果を発揮します。

導入前に押さえるべき注意点と限界

ドメイン特化ゆえの汎化性能トレードオフ

特定ドメインにRL訓練した4Bモデルは、そのドメイン外の質問には弱くなります。「社内の製品マニュアルに特化させたモデルに、一般的なプログラミング質問をしても期待通りの回答は得られない」と理解しておく必要があります。万能なシステムを作りたい場合は、用途別にモデルを分けるアーキテクチャを検討してください。

学習データの質が精度上限を決める

RL訓練の効果は、入力ドキュメントの品質と量に大きく依存します。古い情報、矛盾した記述、構造化されていないドキュメントが多いと、Q&A生成の品質が下がり、報酬関数も正確に機能しなくなります。訓練前のドキュメント品質改善に時間を投資することが、最終的な精度を左右します。

評価パイプラインを先に用意しないと改善が回らない

「訓練したが本当に良くなったのかわからない」という状態は最悪です。RL訓練を始める前に、**人手で評価した正解セット（ゴールドセット）**を100〜200件用意しておくことを強く推奨します。このセットに対するPass@8を定期的に測定することで、訓練の進捗と方向性を客観的に把握できます。

セルフホスト運用の体制要件

フロンティアAPIからセルフホスト推論に移行するということは、推論サーバーの運用責任を自前で持つことを意味します。最低限、以下の体制が必要です。

• GPU推論サーバーの監視：メモリ使用量、スループット、エラー率の監視
• モデルのバージョン管理：訓練済みモデルの安全な保管とデプロイ管理
• 障害対応プロセス：推論サーバーのダウン時のフォールバック設計

よくある質問（FAQ）

Q. 4Bモデルで本当に業務品質に届くのか？

A. ドメイン特化タスクに限れば、RL訓練後の4Bモデルが業務品質に達するケースは実証されています。ただし「どのタスクで使うか」の定義が重要です。社内規定の検索・要約、製品マニュアルに基づいたFAQ応答、財務データの比較分析など、ドキュメントに根拠が存在するタスクで特に高い精度を発揮します。汎用的なコード生成や多言語翻訳など、ドキュメント根拠のないタスクには向いていません。

Q. RLの知識がなくても運用できるのか？

A. Castformはそのための抽象化を提供しているため、RLアルゴリズムの詳細知識は不要です。ただし「報酬関数の設計」という概念的な理解は必要です。「何が良い回答で、何が悪い回答か」を定量的に定義できるエンジニアであれば、RLの数学的背景を知らなくても運用できます。

Q. 既存のベクトルDB（Pinecone等）から乗り換える必要はあるか？

A. RL訓練フェーズではLakebase Postgresとの統合が前提となりますが、本番推論環境では必ずしも乗り換える必要はありません。ただし、運用の一元化という観点では、Lakebase Postgresに統合した方が管理コストは下がります。移行コストと運用効率のトレードオフを考慮して判断してください。

Q. フロンティアモデルとのハイブリッド構成は可能か？

A. 可能です。「日常的な質問はCastform訓練済み4Bモデルで処理し、4Bが自信を持って答えられない（不確実性が高い）ケースのみGPT-5.6 Solにフォールバックする」というルーティング構成が現実的な選択肢です。コストとカバレッジのバランスを取るアーキテクチャとして有効です。

Q. どのくらいの期間で効果が出るのか？

A. ドキュメントの整備状況と規模によりますが、一般的なスケジュール感は以下の通りです。ドキュメント整備と投入に1〜2週間、Q&A生成と評価セット作成に1週間、初回RL訓練と評価に1〜2週間で、合計4〜6週間でファーストリザルトを確認できます。本番相当の精度に到達するまでのイテレーション込みで2〜3ヶ月が現実的な見通しです。

まとめ：RAGの競争軸は「モデルの大きさ」から「学習のさせ方」へ

本記事の要点3つ

**①「小さいモデルは検索が下手」という定説は、RL訓練によって覆された。**4Bパラメータのオープンモデルに強化学習でポストトレーニングを施すことで、自律的なマルチホップ検索能力が獲得され、ドメイン特化タスクではフロンティアモデルを上回る精度が実証されています。

**②コスト削減は1/100という次元の話であり、ベンダーロック解消というボーナスも付いてくる。**月間コストの差は大規模運用では年間数十万ドル規模になります。さらに、APIプロバイダーの価格改定やモデル廃止に左右されないセルフホスト構成により、コスト予測の安定性も大幅に向上します。

**③Neon Lakebase Postgresは「PostgreSQL1本でRAGインフラを完結させる」という発想を現実にした。**ドキュメント格納からベクトル検索、BM25全文検索、RL訓練データ生成、訓練中の負荷吸収まで単一のシステムで賄うことで、運用の複雑さを根本から削減します。

次のアクション：まず評価セットを作るところから

本記事で紹介したアーキテクチャを試してみたいと思った方に、最初の一歩として推奨するのは評価セットの作成です。

1. 自社のRAGシステムに寄せられる典型的な質問を100件収集する
2. 各質問に対して「理想的な回答」と「根拠となるドキュメントへの参照」を記録する
3. 現在のシステムのPass@8を測定してベースラインを把握する

この評価セットがあれば、Castformを試す際に「本当に改善したか」を客観的に判断できます。逆に評価セットなしに導入を進めると、「感触は良さそうだが数字で示せない」という状況に陥りがちです。測定できないものは改善できません。評価セットの構築こそが、ROIを最大化するための最初の投資です。

参考リンク・出典

• How Castform + Neon Beats Frontier Models on Price and Efficiency (Neon Blog)
• RAG Not LAG: RL for Blazing Fast Agentic Retrieval (Castform Blog)
• Lakebase Search — Neon Docs
• Best Open-Source LLMs for RAG in 2026 (Premai)