1. 从“幻觉”到“零幻觉”一个阅读器问答系统的核心挑战最近在折腾一个阅读器相关的问答功能目标很明确用户上传一篇文档然后可以针对文档内容进行提问系统需要给出精准、可靠的答案。听起来是不是很像现在流行的RAG检索增强生成应用没错底层逻辑确实类似。但“类似”和“能用”之间隔着一道巨大的鸿沟这道鸿沟的名字就叫“幻觉”。所谓“幻觉”在AI生成内容领域特指模型会生成一些听起来头头是道但实际上在提供的源文档中根本不存在的“事实”。比如你上传了一篇关于2023年新能源汽车销量的报告问“特斯拉Model Y的全年销量是多少”模型可能会自信地告诉你一个数字甚至精确到个位数但这个数字可能是它根据训练数据中的模糊记忆“编造”的而非报告中的真实数据。对于严肃的文档问答场景这种幻觉是致命的它直接摧毁了用户对系统的信任。因此我给自己定的目标不是“降低幻觉率”而是“实现零幻觉”。这当然是一个理想化的表述在工程上我们追求的是无限趋近于零。实现这个目标远不是调用一个现成的API那么简单。它需要一套从文档处理、检索、到生成和验证的完整技术栈设计每一个环节的疏漏都可能导致幻觉的滋生。接下来我就把自己从零搭建这套系统过程中踩过的坑、验证过的方案以及最终沉淀下来的核心经验毫无保留地分享出来。2. 地基工程文档的精细化预处理与向量化很多人一上来就想着怎么调Prompt、怎么优化大模型这其实是本末倒置。我的经验是90%的“幻觉”问题其根源在于糟糕的文档预处理和检索环节。如果给模型的“参考材料”本身就是混乱、割裂或不准确的那模型再怎么“聪明”也难为无米之炊只能靠“编”来完成任务。2.1 文本分割的艺术超越简单的按段落切割最常见的预处理错误就是粗暴地按固定字符数比如500字或者自然段落进行分割。这会导致两种问题语义断层一个完整的论点或事实被硬生生切在两段检索时只能拿到一半信息模型自然无法正确回答。噪声引入一个段落里可能包含表格标题、页眉页脚、无关的图表说明这些噪声会被一并向量化干扰检索精度。我的解决方案是采用基于语义的递归分割。这里我用了LangChain的RecursiveCharacterTextSplitter但关键不在于工具而在于策略。from langchain.text_splitter import RecursiveCharacterTextSplitter # 定义分割符优先级先按双换行通常是大段落再按句号、问号等最后按逗号。 separators [\n\n, \n, 。, , , , , , ] text_splitter RecursiveCharacterTextSplitter( separatorsseparators, chunk_size500, # 目标块大小 chunk_overlap80, # 块间重叠字符数至关重要 length_functionlen, ) chunks text_splitter.split_text(your_document_text)核心参数chunk_overlap的作用设置重叠比如80个字符是为了确保即使分割点落在了某个关键信息的中间相邻的两个文本块也能通过重叠部分保持上下文的连续性。这在检索时系统有机会同时召回这两个相关的块为模型提供更完整的上下文。针对特殊文档的增强处理PDF/扫描件先用OCR如Tesseract或专用解析库如PyMuPDF用于文本型PDFpdfplumber用于表格提取文本并保留原始布局信息如章节标题、列表。我会将提取出的标题结构转化为Markdown格式的标题## H2,### H3这些标题信息会作为元数据附加到文本块上在检索时能提供更强的结构性信号。表格数据表格是幻觉的重灾区。我的做法是将表格转换为两种格式存储结构化描述例如“下表展示了2023年Q1至Q4各品牌销量品牌A: 100, 200, 150, 180品牌B: ...”。这便于向量检索。原始表格数据如CSV或Markdown表格格式作为元数据存储。当问题明显涉及数值对比、排序时如“哪个季度销量最高”在生成答案阶段可以将原始表格数据直接提供给模型让它进行“计算”而非“回忆”极大减少数值幻觉。2.2 向量化与索引选对模型和数据库文本块准备好后需要将它们转换为向量嵌入并建立索引以供检索。这里有两个关键决策点。嵌入模型的选择别再用通用的text-embedding-ada-002了虽然它不错。对于中文场景和追求极致精度我强烈推荐使用专门针对检索优化的双语或中文嵌入模型。我最终采用的是BAAI/bge-large-zh-v1.5。它在中文语义相似度任务上表现卓越并且针对“非对称检索”即短查询到长文档场景做了优化这正是问答系统的典型模式。# 使用Sentence Transformers加载BGE模型 from sentence_transformers import SentenceTransformer embed_model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 记得对查询进行指令前缀处理这是BGE模型的要求 query_instruction 为这个句子生成表示以用于检索相关文章 encoded_query embed_model.encode(query_instruction user_question) encoded_chunks embed_model.encode(list_of_chunks)向量数据库的选型轻量级、高性能、易集成是我的标准。ChromaDB和Qdrant是两大热门选择。我选择了Qdrant原因在于支持过滤我可以轻松地基于元数据如文档ID、章节标题进行过滤检索这在多文档库中非常有用。Payload强大除了向量每个点都可以存储丰富的原始文本和元数据检索时一并返回省去了二次查询的麻烦。云服务/自托管灵活有现成的云服务也可以用Docker轻松自建。建立索引时我会把每个文本块、它的向量、以及丰富的元数据包括原始文本、所属文档、章节标题、是否包含表格等标记一并存入Qdrant。3. 检索环节从“找到一些”到“找到对的”即使有了好的向量检索策略不对依然会功亏一篑。核心思想是不要只依赖一次向量相似度搜索。3.1 混合检索策略向量搜索 关键词搜索单一向量搜索在以下情况会失灵术语精确匹配文档中出现了“LLaMA-3-70B”用户问“LLaMA3 70B的参数”字面稍有不同可能影响向量相似度。数字、日期、代号这些信息在向量空间中的表示可能不敏感。因此我实现了混合检索向量检索使用BGE模型对查询进行编码在Qdrant中进行相似度搜索取前k个结果例如 top 5。关键词检索使用如BM25或TF-IDF算法在文本块中进行全文关键词匹配再取前k个结果。结果融合与重排将两组结果合并去重。然后使用一个交叉编码器Cross-Encoder进行重排。交叉编码器如BAAI/bge-reranker-large会同时接收查询和每一个候选文本块计算一个更精细的相关性分数比单纯的向量点积或BM25分数更准确。# 伪代码展示混合检索流程 def hybrid_retrieval(query, top_k5): # 1. 向量检索 vector_results vector_search(query, top_ktop_k*2) # 多取一些 # 2. 关键词检索 keyword_results keyword_search(query, top_ktop_k*2) # 3. 合并去重 all_candidates merge_and_deduplicate(vector_results, keyword_results) # 4. 使用交叉编码器重排 reranker CrossEncoder(BAAI/bge-reranker-large) pairs [[query, cand.text] for cand in all_candidates] scores reranker.predict(pairs) # 5. 根据重排分数选出最终top_k ranked_candidates [cand for _, cand in sorted(zip(scores, all_candidates), reverseTrue)] return ranked_candidates[:top_k]这个流程确保了召回的文本块既在语义上相关又在关键词上匹配大大提升了检索底座的可靠性。3.2 查询理解与改写用户的提问方式千奇百怪。直接拿原始问题去检索效果可能打折扣。因此我增加了一个查询改写步骤。用一个轻量级的LLM比如Qwen2.5-7B-Instruct的本地部署或者大模型的API对原始查询进行优化。核心思想提取将“帮我总结一下这篇文章讲了啥”改写为“这篇文章的主要内容、核心观点和总结”。指代消解如果对话有历史将“它上面的那个观点”结合上下文改写为具体的观点描述。问题泛化与具体化根据检索结果动态调整。如果首次检索结果太少可以将问题适当泛化如果结果太多且杂乱可以尝试更具体的问法。这个步骤可以作为检索前的预处理也可以作为检索结果不理想时的后处理策略。4. 生成与验证给大模型戴上“紧箍咒”检索到了最相关的上下文终于轮到LLM上场了。这是幻觉产生的最后一道关口也是最需要精心设计的一环。4.1 系统提示词工程设定严格的回答规则Prompt不是越复杂越好而是规则越清晰、越强硬越好。我的系统提示词模板包含以下几个不可妥协的部分你是一个专业的文档分析助手必须严格根据用户提供的上下文来回答问题。 请遵守以下规则 1. 你的所有答案都必须源自上下文中明确陈述的信息。 2. 如果上下文中的信息不足以完整回答问题请明确指出“根据提供的资料无法确定...”。 3. 禁止进行任何超出上下文范围的推理、联想或补充。禁止使用你自身训练数据中的知识。 4. 如果上下文中存在多个相关部分请综合它们进行回答并注明信息来源于上下文的不同部分。 5. 回答时尽量引用上下文中的原话或关键数据并在必要时说明出处例如来自第X段。 上下文 {context} 问题 {question}关键点强调“唯一来源”反复告诉模型上下文是它唯一的知识来源。允许“不知道”明确授权模型在信息不足时说“不知道”这比它胡编乱造要好一万倍。要求引用和溯源这不仅让答案更可信也为后续的验证提供了便利。4.2 后处理与一致性验证即使有了严格的Prompt模型偶尔还是会“溜号”。因此必须增加一个后处理验证层。我的验证方法包括答案与上下文的忠实度检查使用一个经过微调的自然语言推理模型判断生成的答案是否可以被给定的上下文所“蕴含”。例如可以选用一个轻量化的MNLI多类型自然语言推理模型将“上下文”作为前提“生成的答案”作为假设检查其关系是否为“蕴含”。如果关系是“矛盾”或“中立”则触发警报。关键事实抽取与反向验证从生成的答案中抽取出实体、日期、数字等关键事实可以用NER工具。然后将这些事实作为新的“查询”反向在原始的上下文片段中进行精确匹配搜索。如果某个关键事实在上下文中完全找不到匹配或近似匹配那么这个事实就很可能是幻觉。多模型交叉验证可选成本较高对于非常关键的回答可以用另一个不同架构的LLM例如用DeepSeek生成用GPT-4或Claude验证基于同样的上下文和问题判断原答案是否忠实。当两个顶级模型判断不一致时需要人工复核。一旦验证层发现高风险幻觉系统可以采取以下措施直接拒绝回答返回“根据文档我无法确认该信息请核实您的问题或文档内容。”降级回答只输出那些被验证通过的部分对于存疑部分予以省略并说明。触发人工审核在后台标记该次问答供后续分析改进。5. 系统集成与持续迭代构建反馈闭环将上述所有模块串联起来就构成了一个完整的“零幻觉”问答流水线。但系统上线不是终点而是开始。必须建立一个持续的监控与迭代机制。我设计了一个简单的反馈系统日志记录记录每一次问答的原始问题、检索到的上下文及得分、生成的答案、验证结果。用户反馈提供“答案是否有用”的点赞/点踩按钮。点踩时邀请用户标注具体问题如“信息不准确”、“未回答问题”。幻觉样本收集通过验证层的报警和用户点踩收集被判定为“幻觉”或“不满意”的案例。根因分析定期分析这些案例。是检索错了还是分割时丢了关键信息或者是Prompt对某类问题无效针对根因去优化对应的模块如调整分割策略、改进查询改写规则、增强Prompt。A/B测试任何优化都要经过小流量A/B测试用客观指标如答案准确率、用户满意度来衡量效果而不是感觉。实现“零幻觉”的阅读器问答没有银弹。它是一套结合了精细化数据预处理、混合检索策略、严格的生成约束以及多层验证的系统工程。每一个环节都需要精心打磨并且要接受这是一个需要持续优化的过程。我的实践表明通过上述组合拳可以将幻觉率控制在极低的、业务可接受的水平。最终你获得的不仅仅是一个功能而是一个能让用户放心依赖的、真正理解文档内容的智能伙伴。
