AI搜索 常见问题汇总｜附配置文件

随着大模型能力的快速提升，“AI搜索”正在成为企业知识库、个人信息检索、客服问答、研发文档查询、行业研究等场景中的重要入口。相比传统搜索引擎只返回网页链接或关键词匹配结果，AI搜索更强调“理解问题—检索资料—组织答案—引用来源—持续追问”的完整体验。

不过，在实际落地过程中，很多人会遇到类似问题：为什么AI回答不准确？为什么检索不到文档？为什么明明上传了资料却答非所问？向量数据库怎么选？Embedding模型怎么配？知识库切分多大合适？如何减少幻觉？本文将围绕AI搜索的常见问题进行系统梳理，并在文末附上一份可参考的配置文件，方便你快速搭建或优化自己的AI搜索系统。

一、什么是AI搜索？

AI搜索可以简单理解为：在传统搜索能力的基础上，引入大语言模型、向量检索、语义理解、重排序、答案生成等技术，让用户可以用自然语言提问，并获得更直接、更结构化、更接近“答案”的结果。

传统搜索通常依赖关键词匹配，例如用户搜索“如何配置Nginx反向代理”，系统会根据关键词返回包含“Nginx”“反向代理”“配置”的网页或文档。而AI搜索会进一步理解用户意图，检索相关资料后，直接总结出配置步骤、注意事项，甚至给出可复制的配置代码。

常见的AI搜索架构通常包括以下几个部分：

1. 数据源接入：网页、PDF、Word、Markdown、数据库、企业文档、代码仓库等。
2. 文本解析与清洗：提取正文，去除无效内容、页眉页脚、广告、乱码等。
3. 文本切分：将长文档切成适合检索的小片段。
4. 向量化Embedding：将文本转为向量，方便进行语义检索。
5. 向量数据库存储：保存文本片段及其向量。
6. 查询理解：对用户问题进行改写、扩展或拆解。
7. 检索与重排序：召回相关内容，并重新排序提高命中率。
8. 大模型生成答案：结合检索结果生成自然语言回答。
9. 引用与溯源：展示答案来源，提高可信度。
10. 反馈与优化：根据用户点击、点赞、追问持续优化系统。

二、AI搜索和RAG是什么关系？

很多人在了解AI搜索时会听到一个概念：RAG，即 Retrieval-Augmented Generation，中文一般称为“检索增强生成”。

简单来说，RAG是AI搜索中的一种核心技术路线。它的基本思路是：不要让大模型完全依赖自身参数中的知识来回答，而是先从外部知识库中检索相关资料，再让大模型基于这些资料生成答案。

这可以有效解决两个问题：

• 知识过时：大模型训练数据有截止日期，无法实时知道最新内容。
• 事实幻觉：大模型可能编造不存在的信息，而RAG通过引用真实资料降低幻觉概率。

所以，AI搜索可以看作是更完整的产品形态，而RAG是支撑AI搜索的一种技术方法。一个成熟的AI搜索系统，通常会以RAG为核心，同时结合关键词检索、向量检索、重排序、多轮对话、权限控制、日志监控等能力。

三、为什么AI搜索有时回答不准确？

这是最常见的问题之一。AI搜索回答不准确，通常不是单一原因导致，而是多个环节共同影响的结果。

1. 数据源质量不高

如果知识库中的原始资料本身过时、错误、重复或不完整，那么AI搜索很难生成准确答案。AI系统并不会天然知道哪些文档更可信，它往往依赖检索到的内容进行回答。

优化建议：

• 定期清理过期文档；
• 为文档添加发布时间、版本号、作者、部门等元信息；
• 对重要知识设置权威来源；
• 删除重复内容和冲突内容；
• 对制度、产品文档、接口文档等资料建立更新机制。

2. 文档切分不合理

AI搜索通常会将长文档切成多个片段。如果切分太短，片段缺少上下文；如果切分太长，又可能导致检索不精准，或者超出模型上下文窗口。

例如，一份接口文档中“参数说明”和“错误码说明”被切到了不同片段里，用户询问某个接口错误码时，系统可能只检索到参数说明，导致回答不完整。

优化建议：

• 普通知识文档可设置 chunk size 为 500～1000 中文字符；
• 技术文档可适当增大到 800～1500 字符；
• 保留一定重叠区间，通常 overlap 设置为 100～200 字符；
• 对Markdown、HTML文档优先按标题层级切分；
• 对表格、代码块、配置项尽量保持完整，不要随意截断。

3. 检索召回不够准

如果用户问题没有检索到正确资料，后续大模型再强也很难回答正确。检索失败可能来自关键词不匹配、语义向量不准、召回数量太少、过滤条件错误等。

优化建议：

• 使用“关键词检索 + 向量检索”的混合检索；
• 对用户问题进行Query Rewrite，例如补全上下文、同义词扩展；
• 增加 top_k 数量，例如从 3 提升到 8 或 10；
• 引入 rerank 模型对召回结果重新排序；
• 检查文档元数据过滤条件是否过严；
• 对专业领域词汇建立同义词词典。

4. Prompt设计不完善

AI搜索最终需要大模型根据检索结果生成答案。如果系统提示词设计不当，大模型可能会过度发挥，出现编造、跑题或忽略引用资料的问题。

优化建议：

• 明确要求“仅基于检索资料回答”；
• 如果资料不足，应回答“未找到足够信息”；
• 要求列出引用来源；
• 对输出格式进行约束；
• 根据不同场景设计不同提示词，例如客服、技术支持、政策解读等。

四、为什么上传了文档却搜索不到？

很多用户以为“上传文档=马上可以问答”，但实际上文档从上传到可检索，中间要经历解析、切分、向量化、入库等流程。任何一个环节失败，都可能导致搜索不到。

常见原因包括：

1. 文档解析失败

PDF扫描件、图片型文档、复杂表格、加密文件等，都可能导致文本提取失败。如果系统没有OCR能力，扫描PDF可能被当成空文档处理。

解决方法：

• 对扫描PDF启用OCR；
• 检查文档是否加密；
• 对复杂表格单独处理；
• 尽量使用Markdown、TXT、HTML、Word等结构化程度较高的格式；
• 上传后检查解析出的文本预览。

2. 向量化任务未完成

大型文档需要时间进行切分和Embedding。如果任务队列拥堵，用户刚上传就查询，可能尚未入库。

解决方法：

• 在前端展示文档处理状态；
• 为解析、切分、向量化、入库分别记录状态；
• 提供失败重试机制；
• 对批量上传任务设置队列优先级。

3. 元数据过滤错误

很多AI搜索系统支持按部门、权限、标签、时间范围过滤。如果过滤条件配置错误，可能导致用户无法搜索到本应可见的文档。

解决方法：

• 检查文档所属空间、标签、权限组；
• 检查用户角色和访问范围；
• 查询时打印过滤条件日志；
• 为管理员提供“无权限过滤调试模式”。

五、AI搜索如何减少幻觉？

幻觉是大模型应用中不可避免但可以显著降低的问题。AI搜索减少幻觉的关键，是让模型“有据可依、有据必依、无据不答”。

1. 强制基于上下文回答

在系统提示词中明确要求模型只能使用检索上下文回答。如果上下文没有相关信息，必须说明资料不足，而不是凭经验推断。

示例提示词：

你是一个严谨的企业知识库问答助手。
请仅根据提供的参考资料回答用户问题。
如果参考资料中没有答案，请回答“根据当前资料无法确定”。
不要编造不存在的政策、数据、链接、接口或联系人。
回答时请尽量标注引用来源。

2. 提供引用来源

引用不仅能提升用户信任，也方便用户检查答案是否可靠。引用可以包括文档标题、章节、链接、页码、更新时间等。

例如：

根据《员工报销制度V3.2》第四章规定，差旅住宿报销需提供发票和审批单。
来源：员工报销制度V3.2，第4章，更新时间：2024-05-18。

3. 设置置信度阈值

当检索结果分数过低时，不应强行生成答案。可以设置最低相似度阈值，如果没有达到阈值，则提示用户换一种问法或补充信息。

4. 使用重排序模型

Embedding检索适合大范围召回，但排序未必总是最优。Rerank模型可以对“问题—候选片段”进行更精细的相关性判断，从而提升最终上下文质量。

六、向量检索和关键词检索怎么选？

实际项目中，不建议只使用单一检索方式，而是更推荐混合检索。

向量检索适合：

• 用户问题和文档表述不完全一致；
• 需要语义理解；
• 存在同义词、近义表达；
• 用户使用自然语言提问；
• 知识库内容较复杂。

例如用户问“公司请假要提前多久申请”，文档中写的是“员工应至少提前两个工作日提交休假审批”。关键词不完全匹配，但语义相近，向量检索更容易命中。

关键词检索适合：

• 搜索编号、代码、错误码；
• 搜索专有名词；
• 搜索人名、项目名、接口名；
• 精确匹配法规条款或文件标题；
• 搜索日志、报错信息。

例如用户搜索“ERR_AUTH_403”或“GB/T 35273”，关键词检索通常更稳定。

推荐方案：混合检索

混合检索通常会同时执行：

• BM25关键词检索；
• Embedding向量检索；
• 结果合并；
• 去重；
• Rerank重排序；
• 返回Top N上下文给大模型。

这样可以兼顾语义召回和精确匹配，适合绝大多数企业级AI搜索场景。

七、Embedding模型怎么选？

Embedding模型负责将文本转换成向量，是AI搜索质量的基础之一。选择Embedding模型时，需要考虑语言、领域、成本、延迟、部署方式等因素。

选择标准

1. 中文效果：如果主要处理中文资料，应选择中文或多语言表现优秀的Embedding模型。
2. 领域适配：法律、医疗、金融、代码等专业场景可能需要领域模型或微调。
3. 向量维度：维度越高不一定越好，维度高会增加存储和计算成本。
4. 吞吐与延迟：批量文档入库时需要较高吞吐，在线查询时需要低延迟。
5. 部署方式：可选择云API，也可本地部署以满足隐私和合规要求。

常见建议

• 个人项目或原型验证：优先使用云端Embedding API，接入简单。
• 企业内部知识库：可考虑本地部署开源Embedding模型，降低数据外传风险。
• 中英文混合场景：选择多语言Embedding模型。
• 代码搜索场景：选择对代码语义支持较好的模型。

八、知识库切分参数如何配置？

切分参数对AI搜索效果影响非常大，但没有绝对通用的最佳值。一般需要根据文档类型调试。

常见切分策略

1. 按固定长度切分

适合普通文本，简单稳定。

chunk_size: 800
chunk_overlap: 150

优点是实现简单，缺点是可能破坏标题、表格、代码块结构。

2. 按标题层级切分

适合Markdown、HTML、技术文档、制度文档。

例如按 #、##、### 标题结构切分，可以保留章节语义。

3. 按语义段落切分

适合高质量长文档，例如研究报告、论文、产品手册。可以基于段落、句子边界、语义相似度进行切分。

4. 特殊内容保护

对以下内容应尽量保持完整：

• 表格；
• JSON；
• YAML；
• 代码块；
• API参数说明；
• 配置文件；
• 数学公式；
• 合同条款。

如果这些内容被切碎，检索和生成质量都会明显下降。

九、Rerank重排序有必要吗？

如果你只是做一个小型Demo，Rerank不是必需的。但如果要做生产级AI搜索，Rerank通常非常有价值。

Embedding检索的任务是“尽量多召回可能相关内容”，但它对细节相关性的判断不一定准确。Rerank模型会对用户问题和候选文本逐一打分，筛选出最相关的片段。

典型流程：

1. 向量检索召回Top 20；
2. 关键词检索召回Top 20；
3. 合并去重得到候选集；
4. Rerank重新排序；
5. 取Top 5～8作为上下文；
6. 交给大模型生成答案。

这样做的好处是：召回阶段更宽松，最终输入给模型的内容更精准，可以显著减少答非所问和幻觉。

十、AI搜索如何处理权限控制？

企业场景中，权限控制非常重要。AI搜索不能因为“智能问答”就绕过原有权限体系。

常见权限方案包括：

1. 文档级权限

每个文档绑定可访问用户、部门、角色或权限组。查询时根据当前用户身份过滤。

2. 片段级权限

如果同一文档中不同章节权限不同，可以在切分后的chunk级别设置权限。实现复杂度更高，但更精细。

3. 空间级权限

按照知识库空间或项目空间隔离，例如“人事制度库”“研发文档库”“财务制度库”。

4. 查询前后双重控制

• 检索前：只召回用户有权限的内容；
• 生成后：检查答案中是否包含敏感信息；
• 日志中：避免记录明文敏感数据。

建议企业AI搜索必须将权限过滤放在检索阶段，而不是仅靠大模型自行判断。

十一、AI搜索为什么响应慢？

AI搜索响应慢通常来自多个环节：

1. 用户问题改写耗时；
2. 向量检索耗时；
3. 关键词检索耗时；
4. Rerank耗时；
5. 大模型生成耗时；
6. 网络请求耗时；
7. 上下文过长导致模型推理慢。

优化方式：

• 对Embedding查询向量进行缓存；
• 控制Rerank候选数量；
• 控制传给大模型的上下文长度；
• 使用流式输出提升体感速度；
• 对热门问题缓存最终答案；
• 向量数据库建立合适索引；
• 模型选择上平衡质量与速度；
• 对不同场景设置不同链路，例如简单问题不走复杂重排序。

十二、AI搜索如何评估效果？

AI搜索不是“能回答就算完成”，需要建立评估体系。常见评估指标包括：

1. 检索指标

• Recall@K：正确资料是否出现在Top K结果中；
• MRR：正确结果排名是否靠前；
• Hit Rate：是否命中相关文档；
• NDCG：综合考虑排序质量。

2. 生成指标

• 答案准确性；
• 答案完整性；
• 是否引用来源；
• 是否存在幻觉；
• 是否符合格式要求；
• 是否能承认不知道。

3. 用户体验指标

• 首字响应时间；
• 总响应时间；
• 用户点赞率；
• 用户追问率；
• 人工转接率；
• 搜索无结果率；
• 用户反馈问题分类。

建议准备一批标准问答集，覆盖高频问题、边界问题、无答案问题、权限问题、复杂多跳问题，并在每次调整模型、切分、检索参数后进行回归测试。

十三、AI搜索常见问题汇总

Q1：AI搜索一定需要向量数据库吗？

不一定。如果数据量很小，可以直接用内存向量索引，甚至只用关键词检索。但当文档数量增加、需要持久化、过滤、扩展和并发查询时，向量数据库会更合适。

Q2：top_k设置越大越好吗？

不是。top_k越大，召回内容越多，但也可能引入噪声，并增加后续Rerank和大模型处理成本。一般可以从5～10开始调试，如果有Rerank，初始召回可以设为20～50，最终上下文保留5～8条。

Q3：为什么AI回答引用了不相关资料？

可能是检索结果相关性不足，也可能是Rerank效果不好，还可能是Prompt没有要求严格引用。建议检查检索日志，查看进入大模型上下文的具体内容。

Q4：能否让AI搜索联网？

可以，但需要明确联网搜索与内部知识库搜索的优先级。企业场景中通常建议优先使用内部知识库，外部联网结果需要标注来源和可信度，避免把未经验证的信息当成公司制度或内部标准。

Q5：知识库更新后多久生效？

取决于系统设计。理想情况下，增量更新应在几秒到几分钟内完成。大型知识库重建索引可能需要更长时间。建议支持增量索引，而不是每次全量重建。

Q6：如何处理重复文档？

可以在入库前计算文档哈希，识别完全重复内容；也可以对文本片段进行相似度去重。重复内容会影响检索排序，甚至导致旧版本资料覆盖新版本资料。

Q7：AI搜索能不能回答复杂问题？

可以，但复杂问题通常需要查询拆解、多轮检索和多步推理。例如“对比A产品和B产品在权限管理上的差异”，系统可能需要分别检索A、B相关资料，再进行结构化比较。

Q8：如何处理没有答案的问题？

优秀的AI搜索应该能回答“不知道”。如果知识库没有相关资料，系统应提示“当前资料未找到相关信息”，并可建议用户上传文档、联系管理员或换一种问法。

十四、参考配置文件

下面是一份适用于中小型企业知识库AI搜索的参考配置。实际使用时可根据模型、数据库、数据规模和业务要求调整。

app:
  name: ai-search-service
  environment: production
  language: zh-CN
  timezone: Asia/Shanghai

data_source:
  enabled_types:
    - markdown
    - txt
    - docx
    - pdf
    - html
  max_file_size_mb: 50
  enable_ocr: true
  ocr_languages:
    - chi_sim
    - eng
  remove_headers_footers: true
  remove_duplicate_spaces: true

document_processing:
  parser:
    prefer_structure: true
    keep_tables: true
    keep_code_blocks: true
  splitter:
    strategy: hybrid
    chunk_size: 900
    chunk_overlap: 150
    respect_markdown_headers: true
    respect_sentence_boundary: true
    preserve_table: true
    preserve_code_block: true
  metadata:
    required_fields:
      - title
      - source
      - updated_at
      - owner
      - permission_group
    optional_fields:
      - version
      - tags
      - department
      - url

embedding:
  provider: local
  model: bge-m3
  dimension: 1024
  batch_size: 32
  normalize: true
  timeout_seconds: 30

vector_store:
  type: milvus
  host: 127.0.0.1
  port: 19530
  collection: enterprise_knowledge_base
  index:
    type: HNSW
    metric: cosine
    params:
      M: 32
      efConstruction: 200
  search:
    top_k: 30
    score_threshold: 0.35
    params:
      ef: 128

keyword_search:
  enabled: true
  engine: elasticsearch
  index: enterprise_docs
  top_k: 30
  analyzer: ik_max_word

hybrid_search:
  enabled: true
  vector_weight: 0.65
  keyword_weight: 0.35
  merge_strategy: reciprocal_rank_fusion
  rrf_k: 60
  deduplicate: true

rerank:
  enabled: true
  provider: local
  model: bge-reranker-large
  candidate_top_k: 40
  final_top_k: 8
  timeout_seconds: 10

query:
  rewrite_enabled: true
  multi_query_enabled: false
  max_rewrite_count: 2
  enable_synonyms: true
  synonym_dict:
    请假:
      - 休假
      - 假期申请
      - 调休
    报销:
      - 费用报销
      - 差旅报销
      - 发票报销
    权限:
      - 访问控制
      - 角色
      - 权限组

llm:
  provider: openai_compatible
  model: qwen-plus
  temperature: 0.2
  top_p: 0.8
  max_tokens: 1800
  stream: true
  timeout_seconds: 60

prompt:
  system: |
    你是一个严谨、可靠的企业知识库AI搜索助手。
    请仅根据提供的参考资料回答用户问题。
    如果参考资料不足以回答，请明确说明“根据当前资料无法确定”。
    不要编造不存在的制度、数据、链接、接口、联系人或流程。
    回答应结构清晰，必要时使用列表、表格或步骤说明。
    如果使用了参考资料，请在答案末尾列出引用来源。
  citation_format: "[{index}] {title} - {section} - {updated_at}"

security:
  permission_filter_enabled: true
  filter_stage: pre_retrieval
  pii_masking_enabled: true
  log_user_query: true
  log_retrieved_chunks: false
  audit_enabled: true

cache:
  query_embedding_cache: true
  search_result_cache: true
  answer_cache: false
  ttl_seconds: 3600

evaluation:
  enable_feedback: true
  collect_thumbs: true
  collect_badcase: true
  min_recall_at_5: 0.85
  max_hallucination_rate: 0.03

observability:
  log_level: info
  trace_enabled: true
  metrics:
    - query_latency
    - first_token_latency
    - retrieval_latency
    - rerank_latency
    - llm_latency
    - no_answer_rate
    - user_feedback_rate

十五、配置文件说明

这份配置文件可以分为几个关键部分：

• data_source：控制文档类型、OCR、文件大小等。
• document_processing：控制文档解析、切分、元数据要求。
• embedding：配置Embedding模型及批处理参数。
• vector_store：配置向量数据库、索引类型和检索参数。
• keyword_search：配置关键词检索引擎。
• hybrid_search：控制向量检索与关键词检索的融合比例。
• rerank：控制重排序模型及候选数量。
• query：控制问题改写、同义词扩展等。
• llm：配置大语言模型生成参数。
• prompt：约束模型回答边界和引用格式。
• security：处理权限、脱敏、审计。
• cache：提升响应速度。
• evaluation：持续评估检索和生成质量。
• observability：用于日志、链路追踪和性能监控。

如果你刚开始搭建AI搜索系统，可以先采用较简单的配置：文档解析、固定长度切分、Embedding、向量检索、大模型生成。等基础链路跑通后，再逐步加入混合检索、Rerank、权限过滤、评估体系和监控系统。

十六、落地AI搜索的建议路径

对于多数团队来说，AI搜索不建议一开始就追求“大而全”。更合理的路线是分阶段建设。

第一阶段：验证可用性

选择一个小范围知识库，例如内部FAQ、产品说明书、运维手册，搭建最小可用系统。重点验证文档能否被正确解析、问题能否命中相关内容、回答是否基本可用。

第二阶段：提升准确率

引入更合理的切分策略、混合检索、Rerank和Prompt约束。建立测试问题集，对搜索效果进行量化评估。

第三阶段：完善企业能力

加入权限控制、审计日志、数据脱敏、文档版本管理、增量更新、用户反馈系统，逐步接入更多业务知识库。

第四阶段：产品化运营

持续分析用户问题，补充缺失文档，优化高频问题答案，建立知识运营流程。AI搜索不是一次性项目，而是需要长期维护的数据与产品系统。

结语

AI搜索的核心并不只是“接一个大模型接口”，而是围绕数据、检索、生成、权限、评估和运营构建一整套可靠系统。很多回答不准、搜索不到、幻觉严重的问题，往往不是模型本身无法解决，而是文档质量、切分策略、检索链路、提示词和权限配置没有做好。

如果要搭建一个真正可用的AI搜索系统，建议牢记三句话：

1. 数据质量决定上限；
2. 检索质量决定答案基础；
3. 系统约束决定可信程度。

只有让AI搜索建立在高质量知识库、合理检索策略和严格生成约束之上，才能从“看起来很智能”走向“真正可依赖”。