AI 搜索引擎架构：生产级检索、引用验证与安全门禁

核心摘要

AI 搜索引擎是一个检索、证据和答案验证系统，而不只是接入搜索 API 的 LLM。生产架构必须规划查询、只检索已授权来源、安全抓取网页、保留证据出处、生成原子主张、验证主张级引用、处理缺失或冲突证据，并把质量、安全、延迟与成本作为同一版本化发布的门禁。

目录

• AI 搜索引擎是什么
• 生产级整体架构
• 定义查询契约
• 安全检索与抓取证据
• 排序与证据组装
• 先生成主张，再验证引用
• 可运行的引用契约
• 按层评测完整流水线
• 垂直 AI 搜索如何设计
• 运营版本化发布
• 常见问题
• 总结

核心要点

• 检索成功不等于回答成功：相关文档仍可能被忽略、误读或错误绑定到主张。
• 引用是结构化证据关系：只有 URL 存在，不能证明证据支持主张，也不能证明引用完整。
• 检索内容是不可信数据：网页可能包含 Prompt Injection、错误事实、恶意文件和危险 URL。
• 授权必须发生在模型上下文之前：不能让 LLM 决定请求者能访问哪个租户或文档。
• 单一分数不足以发布：Retriever、证据、答案、引用、拒答、安全与运行指标需要独立门禁。

AI 搜索引擎是什么

AI 搜索引擎接收信息需求，并返回与可检索证据绑定的综合回答。它可以检索公开网页、私有语料、结构化数据库或多个来源，但其核心产品责任是让回答可验证且符合策略。

相邻概念的范围更窄：

最初的 RAG 论文将参数化生成器与显式非参数记忆结合。现代答案引擎在此基础上增加搜索路由、来源采集、策略执行、引用和交互。并非所有查询都需要生成：导航查询、精确记录、计算任务和弱证据场景，可能更适合返回链接、结构化结果、澄清问题或拒答。

商业产品内部实现通常不公开。不能从外部行为推断某个产品一定使用特定网页索引、模型、子查询数量、排序公式或引用算法。工程设计应从显式契约出发，而不是把对 Perplexity、ChatGPT Search 或其他产品的猜测写成架构要求。

生产级整体架构

生产级 AI 搜索应拆分信任边界，并从来源到主张始终保留类型化证据链。

各阶段应交换结构化契约，而不是自由文本：

1. 请求契约：认证主体、语言、时效性、回答模式、来源策略和预算。
2. 查询计划：子问题、检索路由、必需来源类别和终止上限。
3. 证据记录：不可变 ID、Canonical 来源、快照、文本区间、时间、授权范围和检索分数。
4. 回答对象：原子主张与引用关系，而不是埋在长段落中的 [1] 标记。
5. 验证结果：支持、不支持、冲突、未授权、过期或无法验证。
6. 发布 Trace：模型、Prompt、Retriever、索引、解析器、策略、语料版本、成本和耗时。

这种架构可以准确定位故障。表达流畅但没有证据的答案不会被误判为 Retriever 问题，漏召回也不会通过要求 Generator “更自信”来修复。

定义查询契约

查询契约应在 LLM 扩展请求之前，明确系统允许搜索什么、必须搜索什么。

{
  "requestId": "req-1842",
  "principal": {
    "tenantId": "tenant-a",
    "subjectId": "user-7",
    "roles": ["support"]
  },
  "query": "年度套餐适用哪项退款政策？",
  "locale": "zh-CN",
  "asOf": "2026-08-23T12:00:00Z",
  "answerMode": "cited-summary",
  "sourcePolicy": {
    "classes": ["approved-public", "tenant-private"],
    "domains": ["docs.example.com"],
    "maxAgeSeconds": 86400
  },
  "budget": {
    "maxSubqueries": 4,
    "maxFetchedBytes": 2000000,
    "maxEvidenceTokens": 12000,
    "deadlineMs": 5000
  }
}

规划器据此判断：

• 当前请求是否需要搜索；
• 查询属于导航、事实、比较、探索还是不安全类型；
• 哪些主张需要新鲜证据；
• 认证主体可以访问哪些私有库；
• 是否需要拆分问题；
• 何时停止搜索。

Query Rewriting 是提高召回的假设，不是必然收益。扩展查询可能偏离用户意图、放大错误前提，或把敏感词泄露给外部搜索服务。系统应保留原始 Query，记录全部子查询，在外部调用前识别敏感数据，并用实验比较单查询与多查询基线。

检索层模式可参考 Query Rewriting 术语。

安全检索与抓取证据

检索输出必须同时满足相关、已授权、足够新鲜和可安全处理，Dense Vector 只是候选生成方法之一。

在互补来源之间路由

不同 Retriever 的分数空间未经校准时，应按 Rank 融合，而不是直接相加。私有内容必须在进入 Reranker、Cache、Prompt 或日志前完成授权。生成后的过滤无法可靠撤回已经暴露给模型的信息。

隔离网页抓取

搜索结果 URL 只是候选地址，不是可信内容。Fetcher 应：

• 只允许预期协议；
• 解析并验证目标地址；
• 阻止 Loopback、Private、Link-local、Metadata 和内部网段；
• 每次重定向后重新验证；
• 执行出站网络策略；
• 限制重定向次数、时间、字节数、解压后大小和 Content-Type；
• 在沙箱中解析 HTML、PDF、Office、图片和压缩包；
• 去除主动内容，同时保留文本与 Offset；
• 记录最终 URL、Canonical URL、抓取时间、Header、Digest 和 Parser Revision。

这些控制符合 OWASP SSRF Prevention Cheat Sheet 的纵深防御思路。开放网页产品往往无法固定所有域名，因此网络隔离和目标地址验证更加重要。

Crawler 应实现 RFC 9309 Robots Exclusion Protocol。RFC 明确指出 Robots 规则不是访问授权；遵守 robots.txt 也不能替代版权、隐私、合同、付费墙和数据用途审查。

把检索内容视为不可信数据

网页可以包含间接 Prompt Injection，例如要求忽略策略、泄露秘密、调用工具或优先相信污染来源。OWASP RAG Security Cheat Sheet覆盖文档投毒、权限继承、来源追踪、Chunk 隔离、缓存风险、输出验证和 Fail-Closed。

Delimiter 与提示词可以减少混淆，但不能建立安全边界。Generator 不应拥有扩大自身数据权限、修改过滤条件、跟随任意链接或调用高风险工具的权限。

排序与证据组装

排序目标应是在预算内提升证据覆盖与质量，而不是简单选择相似度最高的内容。

基础流程：

1. 从已批准路由召回较宽候选集。
2. 归一化稳定的 Document 与 Passage ID。
3. 合并完全重复和近重复内容。
4. 按 Query 或 Sub-question 相关性重排。
5. 执行来源类别、时效性、语言和权威性策略。
6. 保留实质冲突的证据。
7. 选择覆盖必需信息单元的多样证据集。
8. 达到证据充分条件或预算后停止。

证据记录需要保留验证所需信息：

{
  "evidenceId": "ev-7",
  "documentId": "policy-annual-refunds",
  "sourceUrl": "https://docs.example.com/policies/refunds",
  "canonicalUrl": "https://docs.example.com/policies/refunds",
  "snapshotSha256": "sha256:replace-with-real-digest",
  "retrievedAt": "2026-08-23T12:00:01Z",
  "validFrom": "2026-07-01",
  "textStart": 1480,
  "textEnd": 1612,
  "passage": "年度套餐可在首次购买后的 14 天内退款。",
  "policyScope": {
    "tenantId": "tenant-a",
    "classification": "internal",
    "authorized": true
  },
  "scores": {
    "retrieval": 0.73,
    "reranker": 0.91
  }
}

这些分数是特定发布版本的排序信号，不是事实正确概率。Snapshot Digest 与 Offset 能让审核者在实时网页变化后仍检查模型当时看到的内容。

Context Assembly 还应保留冲突。如果当前政策写 14 天，旧版本写 30 天，静默删除其中一条会掩盖数据生命周期问题。应把版本和权威性信号交给 Verifier，并向用户说明未解决冲突。

检索实现可阅读语义搜索工程指南，迭代检索则参考 Agentic RAG。

先生成主张，再验证引用

引用生成应输出显式的 Claim-Evidence Graph，只在句末添加 [1] 不等于验证。

ALCE 基准将 Fluency、Correctness 与 Citation Quality 分开；TREC 2024 RAG也分别发布检索相关性、信息 Nugget 和 Citation Support 判断。这些设计共同支持一条生产原则：答案质量与引用质量相关，但必须独立评估。

每项事实主张应验证：

1. 有效性：Evidence ID 是否映射到保留的快照？
2. 相关性：引用片段是否讨论当前主张？
3. 蕴含关系：片段是否真正支持主张的完整措辞？
4. 完整性：所有可外部验证的主张是否均有支持？
5. 权威性：来源是否适合该领域和主张类型？
6. 时效性：来源在请求指定时间是否有效？
7. 授权：当前主体是否可以使用该证据生成回答？
8. 冲突：其他权威来源是否给出实质不同结论？

先生成答案再补引用，可能找到一个看起来相关的片段，却掩盖模型生成时并未使用它。优先让模型基于 Evidence ID 生成原子主张，再由独立 Verifier 检查；支持失败时删除、缩小措辞、重新生成或拒答。

不要把隐藏 Chain-of-Thought 当作证明。可审计 Trace 应保留最终主张、Evidence ID、验证决定和原因，而不泄露私有推理 Token。

可运行的引用契约

下面的 Python 示例在语义蕴含评审前验证引用结构，对未知证据、未授权证据、空 Quote、无引用主张和原文中不存在的 Quote 执行失败。

from dataclasses import dataclass
from typing import Iterable


@dataclass(frozen=True)
class Evidence:
    evidence_id: str
    passage: str
    authorized: bool


@dataclass(frozen=True)
class Citation:
    evidence_id: str
    quote: str


@dataclass(frozen=True)
class Claim:
    claim_id: str
    text: str
    citations: tuple[Citation, ...]


def validate_citations(
    claims: Iterable[Claim],
    evidence: Iterable[Evidence],
) -> list[str]:
    evidence_by_id = {item.evidence_id: item for item in evidence}
    errors: list[str] = []

    for claim in claims:
        if not claim.citations:
            errors.append(f"{claim.claim_id}: missing citation")
            continue

        for citation in claim.citations:
            item = evidence_by_id.get(citation.evidence_id)
            if item is None:
                errors.append(
                    f"{claim.claim_id}: unknown evidence {citation.evidence_id}"
                )
                continue
            if not item.authorized:
                errors.append(
                    f"{claim.claim_id}: unauthorized evidence {citation.evidence_id}"
                )
            if not citation.quote.strip():
                errors.append(f"{claim.claim_id}: empty supporting quote")
            elif citation.quote not in item.passage:
                errors.append(
                    f"{claim.claim_id}: quote is absent from {citation.evidence_id}"
                )

    return errors


evidence = [
    Evidence(
        evidence_id="ev-7",
        passage="年度套餐可在首次购买后的 14 天内退款。",
        authorized=True,
    )
]
claims = [
    Claim(
        claim_id="c-1",
        text="年度套餐首次购买后的退款窗口为 14 天。",
        citations=(
            Citation(
                evidence_id="ev-7",
                quote="首次购买后的 14 天内",
            ),
        ),
    )
]

assert validate_citations(claims, evidence) == []
print("structural citation checks passed")

预期输出：

structural citation checks passed

Quote 存在只能证明引用文字来自保留片段，不能证明它蕴含当前主张。生产系统还需增加经过人工标签校准的 NLI 或 LLM Verifier，并把高风险或歧义主张交给人工复核。

按层评测完整流水线

评测必须指出哪一层契约失败，并防止平均分掩盖高风险切片。

RAGChecker 论文强调对 Retriever 和 Generator 做细粒度诊断。生产 AI 搜索可以进一步拆分：

必须加入负控：

• 所有来源都没有答案；
• 正确答案只存在于未授权来源；
• 两个权威来源相互冲突；
• 检索网页包含间接 Prompt 指令；
• 结果 URL 重定向到私有地址；
• 来源在检索后发生变化；
• Citation ID 存在但证据不支持主张；
• Cache Entry 属于其他租户或 Policy Revision。

人工 Relevance 与 Citation Judgment 应与冻结语料快照共同版本化。TREC RAG 数据说明了为什么 Retrieval、Nugget Coverage 与 Citation Support 需要不同判断。

发布阈值应包含最差切片，而不只是总体平均。一个在公开英文事实查询上表现良好，却泄露私有文档或无法处理无答案查询的系统，不具备生产资格。

垂直 AI 搜索如何设计

垂直 AI 搜索改变的是证据与策略契约，而不只是 Prompt 或模型。

领域微调模型不会自动让垂直搜索更好。只有经过筛选的证据、Schema、排序信号、策略和专家评测确实改善目标任务时，垂直化才产生优势。应与纯词法、纯语义、非生成式和通用 AI 搜索基线比较。

法律或医疗等高风险搜索还需区分信息发现与专业决策。系统应保留权威来源、版本、法域、日期和限制条件，不能让答案合成抹去出处与适用范围。

运营版本化发布

AI 搜索结果属于完整发布身份，因为任意一层变化都可能改变结果。

release:
  answerModel: provider/model@immutable-revision
  plannerPrompt: planner-v5
  synthesisPrompt: cited-answer-v8
  verifier: claim-support-v3
retrieval:
  lexicalIndex: web-2026-08-23
  embeddingModel: provider/embed@revision
  vectorIndex: corpus-v14
  reranker: provider/reranker@revision
fetch:
  policy: web-fetch-v6
  parser: document-parser-v11
policy:
  sourcePolicy: sources-v4
  authorizationPolicy: authz-v9
  cachePolicy: evidence-cache-v3
evaluation:
  dataset: ai-search-eval-v7
  judgmentRevision: judgments-2026-08-20

Trace 与 Cache Key 都应使用这组身份。安全 Cache Key 至少包含归一化 Query、语言、回答模式、Principal Policy Scope、Corpus 或 Web Snapshot、Source Policy 和全部相关组件 Revision。不能因为文本 Query 相同就在租户之间共享回答缓存。

以下情况应失效缓存或重新评测：

• 来源被删除、撤回、取消授权或发生实质变化；
• Index、Embedding、Reranker、Parser、Prompt、Model 或 Verifier 变化；
• 来源策略或用户授权变化；
• 新增 Query Class、语言或高风险领域；
• Citation、Abstention、安全、延迟或成本发生回归。

可观测性应保留 Query Plan、来源决策、Evidence ID、验证结果、耗时和发布版本，同时尽量减少敏感正文。日志本身也需要授权、保留与删除控制。

常见问题

所有 AI 搜索引擎都使用同一种 RAG 架构吗？

不是。RAG 是连接检索与生成的重要架构家族，但产品还可能混合生成答案、直接链接、结构化数据、计算器、缓存结果和模型记忆。不能把“所有产品都使用同一流水线”当作可验证的设计前提。

AI 搜索应该生成多少子查询、使用多少来源？

没有通用数字。应根据代表性 Query Class 上的证据覆盖、Rewrite Drift、延迟、成本和来源多样性选择限制。简单事实可能只需要一个权威来源，复杂比较则可能需要多个独立来源和迭代检索。

内联引用足以消除幻觉吗？

不足。引用可以增强可检查性，但模型仍可能引用不相关片段，或只为句子的一部分提供依据。答案正确性、Citation Entailment、Citation Completeness、来源权威性与拒答必须独立评测。

AI 搜索是否应该用 Vector Search 替代 BM25？

不应该默认替代。Dense Retrieval 擅长改写，Lexical Retrieval 仍擅长名称、编号、引文和新词。应在同一标注集上比较纯词法、纯 Dense、Hybrid 和 Reranked Pipeline。

来源相互冲突时应如何处理？

系统应保留冲突，在领域存在正式规则时应用 Authority 与时间优先级，并展示无法解决的分歧。Generator 不能静默平均矛盾事实，也不能选择最方便的来源。

总结

AI 搜索是生产级证据系统。架构必须控制查询规划、来源访问、安全抓取、检索、排序、Context Assembly、主张生成、引用验证、拒答、缓存与可观测性。每一层都应使用版本化契约并独立及端到端评测；证据不足或授权不明确时必须 Fail-Closed。

相关资源

• 语义搜索工程指南
• RAG 指南
• Agentic RAG 架构
• RAG 无依据回答治理
• Prompt Injection 攻防指南
• 语义搜索术语
• 引用术语
• Grounding 术语
• ALCE 引用评测论文
• TREC 2024 RAG 评测数据
• OWASP RAG Security Cheat Sheet