当 Grok 的实时搜索开关开启时，其返回的网页摘要可能直接挤占 DeepSeek Agent 原本分配给站内 RAG 的上下文窗口。这种冲突在工程上体现为两种数据源的置信度分数拉锯战，需要从以下三个层面建立防护机制：

一、混合检索的分数融合策略

1. 静态权重分配：对站内知识库 chunk 设置基础权重加成（如 +0.2），这是基于其经过清洗和人工校验的可靠性。但需注意：
2. 站内 chunk 的 embedding 维度须与联网结果对齐（如均采用 bge-m3 生成）

3. 当 Grok 返回的网页权威域名（如 stackoverflow.com）与当前问题领域强相关时，人工定义的正则规则可临时提升其权重

4. 动态衰减因子：对实时搜索结果引入时间衰减系数，例如：

   def time_decay(web_result, half_life_hours=6):
       age_hours = (current_time - web_result.crawl_time).total_seconds() / 3600
       return 0.5 ** (age_hours / half_life_hours)

   超过 24 小时的结果自动降权 90%

5. 跨编码器验证：对分数接近（差值<0.1）的候选结果，调用 DeepSeek-V4 进行重排：

6. 构造 prompt："以下两条信息哪个更符合问题《{query}》？严格按 JSON 格式回答：{'choice':1|2, 'reason':'技术细节'}"
7. 优先选择模型标注技术细节更具体的选项

二、安全防护层设计

• 域名沙盒：Grok 返回的 URL 必须通过预定义的允许列表检查，重点防范：
• 用户生成内容平台（如 pastebin）
• 新注册不满 3 个月的域名
• 非 HTTPS 链接
• 摘要毒性检测：对实时摘要执行：
• 敏感词正则匹配（覆盖漏洞披露、政治敏感词等）
• 用 DeepSeek-V4 进行安全分类（置信度 >0.7 时拦截）
• 缓存污染防护：
• 对频繁变化的网页内容（如新闻、社交媒体）设置最大缓存时间 1 小时
• 当同一 URL 内容哈希值 24 小时内变化超过 3 次时，自动加入临时黑名单

三、用户感知与回退策略

• 来源标记模板：在最终响应中强制插入来源标识，例如：

  [🔗 来自 Stack Overflow] 建议检查 MySQL 的 innodb_buffer_pool_size 参数...
  [📁 内部文档] 我司标准配置值为 12GB

• 熔断规则：当出现以下情况时自动关闭实时搜索：
• 连续 3 次检索的网页结果与用户问题余弦相似度 <0.3
• 实时搜索响应 P99 延迟超过 1500ms
• 人工干预通道：
• 提供 /force_local 命令让用户临时禁用实时搜索
• 管理员可查看冲突案例的历史仲裁日志

四、性能与成本优化

1. 索引预热：
2. 对站内高频访问文档（TOP 100）预生成 embedding 并缓存
3. 使用 GPU 实例批量处理，降低在线推理成本
4. 流量分级：
5. 核心业务问题优先使用站内 RAG
6. 通用技术问题才启用实时搜索
7. 监控看板：
8. 实时追踪「联网结果占比」指标（健康阈值建议 <35%）
9. 当外部 API 调用成本超过 $0.2/query 时触发告警

实施检查清单

1. 在 rag_pipeline.py 中确认混合检索器的 fusion_algorithm=weighted_reciprocal_rank
2. 为站内 chunk 配置 min_score_boost=0.15（需 AB 测试调整）
3. 部署前用历史会话数据验证：
4. 人工标注 100 组「联网 vs 站内」冲突案例
5. 测量仲裁策略的结论通过率（建议 >82%）
6. 压力测试：
7. 模拟 50QPS 的混合查询流量
8. 确保 P99 延迟 <800ms（需 vLLM 动态批处理支持）

边界案例处理

• 矛盾信息：当站内文档与实时搜索结果直接冲突时：
• 展示双方来源
• 用 DeepSeek-V4 生成对比分析（提示词模板："请从时效性、权威性、技术准确性三方面比较以下两段内容"）
• 低质量匹配：对分数均低于 0.4 的结果：
• 丢弃所有检索结果
• 直接调用模型原生知识回答
• 标记为「需要知识库补充」并加入人工审核队列

注：本方案默认假设站内知识库已建立有效索引。若内部文档质量较差，反而应降低其基础权重，避免错误信息优先展示。实际部署时需要根据业务场景调整权重参数，建议通过小流量实验逐步优化。