エンタープライズ向けのカスタマーサポート、社内ITヘルプデスク、法務・コンプライアンス相談などの本番システムにおいて、大規模言語モデル（LLM）の「ハルシネーション（事実に基づかない虚偽情報の生成）」は許容できない重大な障害要因です。存在しない返品規定を顧客に案内したり、誤ったサーバー設定コマンドを社内エンジニアに出力した場合、直ちに業務上の損害や信頼失墜につながります。
基底モデルの追加ファインチューニング（SFT）だけでは、ハルシネーションを根本から防ぐことはできません。重みに焼き付けられたパラメータ記憶は静的であり、頻繁なビジネス情報の更新に追従できないだけでなく、未知の質問に直面した際にも確からしい誤答を生成する性質が残るためです。
この課題に対する実証済みのエンジニアリング標準が**検索拡張生成（RAG: Retrieval-Augmented Generation）**です。百川智能（Baichuan AI）は、Baichuan 4、Baichuan 4-Turbo、そして最大192Kトークンの超長文コンテキストウィンドウを備えた Baichuan2-Turbo-192K において、ネイティブな検索拡張APIを提供しています。社内ナレッジベースの検索とリアルタイムなWeb検索を統合し、モデルを「推測による当て推量」から「検証可能な証拠に基づく回答生成」へと転換させます。
本記事では、バックエンドエンジニア向けに、百川の検索拡張APIの技術アーキテクチャ、API設定、Pythonによる実装例、および本番環境でハルシネーションを遮断するための制御手法を解説します。
1. 企業向けQAにおけるハルシネーションの原因と百川のハイブリッド構造
実業務においてLLMが事実を誤認する主な原因は以下の3点です：
- 知識の時効性欠落：事前学習データのカットオフ以降に発生した規約変更や最新仕様を把握できない。
- 社内固有情報の隔絶：社外秘の社内規定、内部API仕様、障害チケット履歴は公開コーパスに存在しない。
- 自己回帰型モデルの流暢性バイアス：事実の裏付けがない場合でも、言語的整合性を優先して辻褄の合った虚偽を合成してしまう。
百川智能のアーキテクチャでは、モデルを「推論を行うCPU」、コンテキストウィンドウを「RAM」、そして検索拡張を内外データを連携させる「外部ストレージ」として位置づけています：
【ユーザーの業務質問】
│
▼
【意図解析と検索ルーティング】
┌────────────┴────────────┐
▼ ▼
【企業プライベートナレッジ】 【リアルタイムWeb検索】
(密ベクトル検索 ＋ 疎キーワード一致) (最新の公知情報・ニュース)
└────────────┬────────────┘
▼
【ハイブリッドリランクと統合】
▼
【Baichuan 4 / 4-Turbo 推論エンジン (最大192K)】
(厳格な証拠制約プロンプト)
▼
【出典リンク付きの検証可能な回答】
検索拡張の技術的強み
- ハイブリッド検索による語彙ドリフト防止：製品の型番、社内チケットID、専門略語に対して、密ベクトル（Dense Vector）検索単体では類似した別概念へマッチングがドリフトしがちです。百川は疎なキーワード一致（Sparse Search）と密ベクトル検索を統合し、固有表現の検索精度を高めています。
- プライベート文書と公知情報の両立：
knowledge_baseパラメータで社内ドキュメントを参照しつつ、必要に応じてwith_search_enhanceによりインターネット上のリアルタイム情報を同時に補完できます。 - エビデンスアンカー（証拠拘束）：回答生成は取得されたコンテキストに厳格に束縛され、参照されたドキュメントやチャンク情報が出力メタデータに含まれるため、企業の監査要件を満たします。
2. API接続準備とモデル選定
百川の開発者向けAPIはOpenAI互換のエンドポイント（https://api.baichuan-ai.com/v1）を提供しており、標準的なHTTPクライアントや既存のSDKから容易に移行可能です。
事前準備
- 百川智能開発者プラットフォーム でアカウントを作成。
- 管理画面のAPI Keyセクションでアクセスキー（
sk-...）を発行。 - 要件に応じたモデルの選択：
Baichuan 4：フラッグシップモデル。高度な論理推論や複数ドキュメントにまたがる複雑な分析タスクに最適。Baichuan 4-Turbo：低レイテンシ・高スループットに最適化されたモデル。大量アクセスのサポートデスク向け。Baichuan2-Turbo-192K：192Kの巨大なコンテキストを活かし、長大なマニュアルや規約全文をそのまま読み込ませる用途に適しています。
3. 社内文書のインデックス化とナレッジベース構築
社内独自の情報に基づいて正確に応答させるため、まずは文書を百川のナレッジベースに登録します。
ステップ 3.1: ファイルのアップロード
PDF、Word、Markdown、テキスト文書をファイル管理APIへPOSTします：
curl -X POST https://api.baichuan-ai.com/v1/files \
-H "Authorization: Bearer YOUR_BAICHUAN_API_KEY" \
-F "purpose=assistants" \
-F "file=@/path/to/security_policy.pdf"
成功するとレスポンスに file_id が返却されます。
ステップ 3.2: ナレッジベースの作成とチャンキング設定
ナレッジベース管理画面またはAPI経由で、アップロード済みファイルをナレッジベースに関連付けます：
- チャンクサイズ（Chunk Size）：1チャンクあたり500〜800トークンを推奨。
- オーバーラップ（Overlap）：境界部分の文脈断絶を防ぐため、100〜150トークン程度の重複を設定。
- Embeddingモデル：百川の独自モデル
text-Embeddingを指定。 - 生成された
knowledge_base_id（例:kb-sec-compliance-01）を控えます。
4. 検索拡張Chat Completions APIの呼び出し実装
v1/chat/completions エンドポイントに対し、with_search_enhance: true と knowledge_base パラメータを付与することで、検索拡張を適用した推論を実行できます。
以下は、Pythonの openai ライブラリを使用した本番向け実装スクリプトです：
import os
from openai import OpenAI
# OpenAI SDKを利用して百川のエンドポイントに接続
client = OpenAI(
api_key=os.environ.get("BAICHUAN_API_KEY"),
base_url="https://api.baichuan-ai.com/v1"
)
def query_enterprise_assistant(
question: str,
knowledge_base_id: str,
enable_web_search: bool = False
) -> dict:
"""
百川の検索拡張APIを呼び出して社内QAを実施する関数
:param question: ユーザーの質問文
:param knowledge_base_id: 参照先のナレッジベースID
:param enable_web_search: Webリアルタイム検索を同時に有効化するか否か
:return: 回答テキストとメタデータ
"""
# ハルシネーションを厳格に封じるシステムプロンプト
system_prompt = (
"あなたは企業の社内情報アシスタントです。必ず提供されたナレッジベースの検索結果および"
"検索情報のみに基づいて事実を回答してください。記載のない仕様や数値について推測で"
"回答することは厳禁です。該当する根拠が見当たらない場合は、"
"『社内ナレッジベースに該当する情報が見つかりませんでした。担当部門にお問い合わせください。』"
"と明確に答えてください。"
)
# 百川独自の拡張パラメータを設定
extra_body = {
"with_search_enhance": enable_web_search,
"knowledge_base": {
"knowledge_base_ids": [knowledge_base_id]
}
}
try:
response = client.chat.completions.create(
model="Baichuan 4",
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": question}
],
temperature=0.1, # 低温設定により自由な創作を抑止
top_p=0.85,
extra_body=extra_body
)
choice = response.choices[0]
answer = choice.message.content
citations = getattr(response, "knowledge_base", None)
return {
"status": "success",
"answer": answer,
"citations": citations,
"usage": response.usage.model_dump() if response.usage else {}
}
except Exception as e:
return {
"status": "error",
"error_message": str(e)
}
if __name__ == "__main__":
res = query_enterprise_assistant(
question="リモートワーク時の社内VPN接続手順とパスワード更新周期について教えてください。",
knowledge_base_id="kb-sec-compliance-01",
enable_web_search=False
)
print("回答内容：\n", res.get("answer"))
5. 本番運用でハルシネーションを遮断する4つの原則
APIのオプションを有効にするだけでなく、バックエンド側で以下のガードレールを講じる必要があります。
1. サンプリング温度の厳格制御（Temperature <= 0.1）
事実確認を目的とする社内QAシステムでは、temperature を 0.0 または 0.1 に固定します。温度を上げるとモデルが確率の低いトークンを選択し、事実と異なる細部を作り上げるリスクが跳ね上がります。
2. 拒否回答指示の明文化（Negative Constraints）
言語モデルは質問者の期待に応えようとする性質を持ちます。検索された資料に答えが存在しない場合、勝手に類推して回答しないよう、プロンプトで「知らない場合は知らないと答える」義務を明確に課す必要があります。
3. 動的検索ルーティングによるコストとレイテンシの最適化
Web検索（with_search_enhance: true）は1リクエストごとに従量課金（約0.03元/回）が発生し、外部通信に伴い約0.8〜1.5秒の遅延が加わります。社内規程の照会にはWeb検索をOFFにし、外部の市場動向や公的規格など最新の外部情報が必要な問い合わせのみ動的にONにするルーティングを推奨します。
4. 引用元のUI表示による透明性確保
APIレスポンスからドキュメント名や該当パラグラフを抽出し、画面上に脚注として表示します。ユーザーが元の文書を直接クリックして確認できる設計にすることで、誤解やトラブルを未然に防ぎます。
6. まとめ
ベクトルデータベースの構築、リランクモデルの調整、クローラーの保守など、自前でRAG基盤を一から構築・運用するには多大な開発コストと運用負荷が伴います。
百川智能の検索拡張APIを活用することで、高品質なハイブリッド検索エンジンと強力なLLM推論を短期間でシステムに組み込むことができます。適切なパラメータ設計とプロンプト規律を維持することで、事実に基づいた安全で信頼性の高い企業向けQAシステムを実現できます。