精炼回答
RAG中的幻觉问题主要源于三个层面：检索质量低导致喂给模型的上下文就是错的、上下文与问题不匹配产生的理解偏差、以及LLM自身倾向于用预训练知识"自作聪明"地填补空白。缓解策略需要从检索和生成两端同时入手，建立分层防御体系。
在检索侧，核心是提升召回精度。可以采用混合检索策略，让稠密向量处理语义理解，稀疏检索和关键词匹配补足专有名词、数字、日期这类精确匹配的短板。比如用户问"iPhone 15 Pro Max的电池容量"，纯向量检索可能召回所有iPhone的续航讨论，但加上关键词过滤就能精准定位到具体型号的参数文档。重排序模型是第二道防线，用cross-encoder对粗筛结果做深度交互打分，把最相关的top-k文档留下来。chunk切分的粒度也很关键,按段落或固定token数切分时保留一定overlap，避免关键信息被割裂在边界上。
在生成侧，prompt工程是核心武器。不是简单写一句"别瞎编"，而要包含明确的角色定位、严格的回答边界、以及输出格式要求。比如角色定位用"你是一个严谨的知识库助手"而不是"AI助手"，能激活模型更保守的生成模式。回答边界要明确写"仅根据以下上下文回答，如果上下文中没有相关信息，请明确回复'根据现有信息无法回答'"。配合降低temperature到0.1-0.3，让模型更倾向于选择高概率token，减少天马行空的发挥。
引用溯源的实现思路是让模型在生成答案时标注信息来源，让整个过程变得可追溯、可验证。最直接的方法是在检索到的文档块中添加唯一标识，在prompt里要求模型引用这些标识。更精细的做法是在后处理阶段做验证，提取模型答案中的关键语句与原始文档做相似度匹配，自动补充引用链接或高亮原文位置。在法律问答、医疗咨询这类高风险场景，把引用的原文片段直接展示给用户，既增强可信度又方便人工审核。
扩展分析
问题根源与解决框架
要彻底解决幻觉问题，得先搞清楚它是怎么产生的。第一种情况是检索环节就失败了，用户问的是A产品的退货政策，结果召回的都是B产品的文档，这时候模型再聪明也没用，巧妇难为无米之炊。第二种情况是上下文理解出现偏差，检索到的文档可能包含正确信息，但被切分得支离破碎，或者多个chunk之间存在矛盾，模型在拼接理解时就会产生歧义。第三种情况是模型自身的固有倾向，它在预训练时学到了大量通用知识，有时候会用这些知识填补空白，而不是老实说"我不知道"。
针对这三个来源，业界形成了一套分层防御的体系。检索层是第一道防线，这里面试官最想听的不是你知道哪些技术，而是你为什么选择这些技术。稠密向量擅长语义理解，但对专有名词、数字、日期这类精确匹配的内容不敏感，这时候稀疏检索和关键词匹配就能补足短板。实际应用中，我会让向量检索召回更多候选（比如top-k的3倍），然后结合关键词过滤和BM25分数做融合排序。
重排序模型的作用容易被低估，但它确实能显著提升精度。初筛召回可能返回几十上百个文档，但真正喂给LLM的上下文窗口有限，这时候需要重排序模型对相关性做二次打分。重排序通常用cross-encoder架构，它会把query和每个文档拼在一起做深度交互，比bi-encoder的向量点积更准确，当然代价是速度慢，所以才需要先用向量做粗筛。具体实现上可以这样设计：
publicclassHybridRetriever{
privatefinalVectorSearchService vectorSearch;
privatefinalKeywordSearchService keywordSearch;
privatefinalRerankerService reranker;
publicList<DocumentChunk>retrieve(String query,int topK){
// 向量检索召回3倍候选
List<SearchResult> vectorResults = vectorSearch.search(query, topK *3);
// 关键词检索作为补充
Set<String> keywords =extractKeywords(query);
List<SearchResult> keywordResults = keywordSearch.search(keywords, topK);
// 合并去重
Map<String,SearchResult> merged =newHashMap<>();
vectorResults.forEach(r -> merged.put(r.getDocId(), r));
keywordResults.forEach(r -> merged.merge(r.getDocId(), r,
(v1, v2)->newSearchResult(v1.getDocId(),
Math.max(v1.getScore(), v2.getScore()), v1.getContent())));
// 重排序取top-k
List<DocumentChunk> chunks = merged.values().stream()
.map(SearchResult::toChunk)
.collect(Collectors.toList());
return reranker.rerank(query, chunks, topK);
}
privateSet<String>extractKeywords(String query){
Set<String> keywords =newHashSet<>();
// 正则提取数字、日期、产品型号
Pattern numberPattern =Pattern.compile("\\d+");
Matcher matcher = numberPattern.matcher(query);
while(matcher.find()){
keywords.add(matcher.group());
}
// 可以接入NER模型识别实体
keywords.addAll(nerService.extractEntities(query));
return keywords;
}
}chunk切分的重要性常被忽视，但这恰恰是影响检索质量的关键因素。切分粒度直接影响信息完整性，切太大会引入噪声，切太小会破坏语义连贯性。实践中比较好的做法是按段落或固定token数切分，同时保留一定的overlap。比如切500 tokens时让相邻chunk重叠50 tokens，这样能避免关键信息被割裂在边界上。如果是表格或列表这种结构化内容，还需要特殊处理，保持结构的完整性。
生成层的控制是第二道防线，这里核心是通过prompt工程来约束模型行为。prompt需要包含三个关键要素：明确的角色定位、严格的回答边界、以及输出格式要求。角色定位可以是"你是一个严谨的知识库助手"，这会激活模型更保守的生成模式。回答边界要明确写"仅根据以下上下文回答，如果上下文中没有相关信息，请明确回复'根据现有信息无法回答'"，这比简单说"不知道就说不知道"要有效得多。
温度参数的调整也是个可以深入的点。温度控制生成的随机性，降低temperature到0.1-0.3能让模型更倾向于选择高概率的token，减少天马行空的发挥。不过要注意平衡，温度太低会让回答变得僵硬重复。如果系统支持，还可以调整top-p参数，控制累积概率阈值，进一步收紧生成范围。
一个完整的prompt模板应该这样设计：
String promptTemplate ="""
你是一个严谨的知识助手，负责根据提供的文档回答用户问题。
【重要规则】
仅使用下方参考文档中的信息回答，不得使用你的预训练知识。如果文档中没有相关信息，必须明确回复"根据现有文档无法回答该问题"。回答时必须在每个关键信息后标注来源，格式为[doc_X]。保持回答简洁准确，不要过度推理或猜测。
【参考文档】
%s
【用户问题】
%s
【回答要求】
请按以下JSON格式输出：
{
"answer": "你的回答内容",
"confidence": 0.0-1.0的置信度分数,
"citations": ["doc_1", "doc_2"]
}
""";这个模板有几个设计巧思：角色定位用"严谨的知识助手"而不是"AI助手"，能降低模型自由发挥的倾向。规则部分用自然语言表述而非数字列表，让指令更清晰。要求结构化输出有两个好处，一是便于程序解析，二是强迫模型在生成时就考虑引用和置信度。
Citation机制的设计原理要从用户视角来理解。假设你问一个RAG系统"这个商品支持7天无理由退货吗"，它回答"支持"，你敢直接下单吗？答案显然是不敢，因为你不知道这个"支持"是来自官方政策文档，还是模型瞎编的。这时候Citation的价值就体现出来了，它不是可选项，而是生产环境RAG系统的必需品，尤其是在法律咨询、医疗问答、金融政策解读这些高风险场景。
实现Citation的关键是建立从生成内容到原始文档的映射关系。最基础的做法是在每个chunk上打标签，在检索文档准备阶段这样处理：
publicclassDocumentChunkService{
publicDocumentChunkprepareChunk(Document doc,String content,int index){
DocumentChunk chunk =newDocumentChunk();
chunk.setContent(content);
chunk.setSourceId(doc.getId());
chunk.setChunkIndex(index);
// 预埋引用标识
Map<String,Object> metadata =newHashMap<>();
metadata.put("citation_id",String.format("[%s_%d]", doc.getId(), index));
metadata.put("source_title", doc.getTitle());
metadata.put("source_url", doc.getUrl());
metadata.put("created_at", doc.getTimestamp());
chunk.setMetadata(metadata);
return chunk;
}
}然后在构造prompt时，把这些标识插入到上下文中：
publicclassPromptBuilder{
publicStringbuildPrompt(String query,List<DocumentChunk> chunks){
StringBuilder context =newStringBuilder();
for(DocumentChunk chunk : chunks){
String citationId =(String) chunk.getMetadata().get("citation_id");
context.append(String.format("%s %s\n\n", citationId, chunk.getContent()));
}
returnString.format(promptTemplate, context.toString(), query);
}
}这种方法简单直接，但依赖模型的指令遵循能力，有时候它会"忘记"标注引用。更可靠的进阶做法是用few-shot示例来教会模型固定的输出格式，在prompt中加入几个标准示例，展示正确的引用格式。最精细的实现需要在后处理阶段做验证和补充，把模型生成的答案按句子切分，然后用embedding模型计算每个句子和原始chunk的相似度，找出最可能的来源：
publicclassCitationVerifier{
privatefinalEmbeddingService embeddingService;
publicList<Citation>verifyCitations(String answer,List<DocumentChunk> chunks){
List<String> sentences =splitIntoSentences(answer);
List<Citation> citations =newArrayList<>();
for(String sentence : sentences){
float[] sentenceEmbed = embeddingService.encode(sentence);
float maxSimilarity =0;
DocumentChunk bestMatch =null;
for(DocumentChunk chunk : chunks){
float[] chunkEmbed = embeddingService.encode(chunk.getContent());
float similarity =cosineSimilarity(sentenceEmbed, chunkEmbed);
if(similarity > maxSimilarity){
maxSimilarity = similarity;
bestMatch = chunk;
}
}
if(maxSimilarity >0.75){// 相似度阈值
citations.add(newCitation(
sentence,
bestMatch,
maxSimilarity
));
}
}
return citations;
}
privatefloatcosineSimilarity(float[] a,float[] b){
float dotProduct =0.0f;
float normA =0.0f;
float normB =0.0f;
for(int i =0; i < a.length; i++){
dotProduct += a[i]* b[i];
normA += a[i]* a[i];
normB += b[i]* b[i];
}
return dotProduct /(float)(Math.sqrt(normA)*Math.sqrt(normB));
}
}实践应用与工程落地
具体到落地实现，可以拿文档助手这个场景来说，用户可能会问"这份技术方案中关于数据库选型的建议是什么"，这种问题既需要精准定位到文档的特定章节，又要求答案必须有据可查。或者在客服问答场景，用户问"我买的这款手机支持多少瓦快充"，这种问题需要从产品参数库里精确召回，而不能靠模型的通用知识来猜。再比如知识库问答，员工查询"公司的年假政策中关于工龄计算的规则"，这类问题涉及内部制度文档，必须做到零幻觉，因为任何错误信息都可能引发劳资纠纷。
整个系统的流程可以用这张图来表示：
Citation的展示形式有三种主流方案，分别适用于不同场景。第一种是inline标注，就是答案中直接嵌入引用标记，像维基百科那样用上标数字[1][2]，这种方式最直观，适合长篇幅的答案。第二种是脚注引用，答案末尾统一列出参考来源，类似学术论文的参考文献，这种方式适合答案较短但引用较多的场景，用户体验上不会打断阅读节奏。实现时可以在后处理阶段自动整理：
publicclassCitationFormatter{
publicFormattedAnswerformatWithFootnotes(String answer,List<Citation> citations){
StringBuilder result =newStringBuilder(answer);
result.append("\n\n【参考来源】\n");
Set<String> uniqueSources =newLinkedHashSet<>();
for(Citation cite : citations){
String sourceInfo =String.format("[%s] %s - %s",
cite.getId(),
cite.getTitle(),
cite.getUrl());
uniqueSources.add(sourceInfo);
}
uniqueSources.forEach(s -> result.append(s).append("\n"));
returnnewFormattedAnswer(result.toString(), citations);
}
}第三种是高亮关联，把答案中的关键句子和原文档片段做视觉上的关联，用户点击答案中的某句话，侧边栏就会展示对应的原文段落。这种交互体验最好，但实现复杂度也最高，需要前端配合，后端主要做的是相似度匹配，把答案的每个句子映射到最可能的来源chunk。选择哪种方案取决于业务场景，文档助手类产品更适合高亮关联，客服问答适合inline标注，知识库查询适合脚注引用。
评估指标是个常被忽视但很加分的点。这套系统上线后，需要从几个维度建立监控。准确率看的是答案是否正确回答了问题，可以抽样人工标注；召回率关注的是检索环节是否找到了相关文档，这个可以通过检索日志分析；幻觉率是核心指标，需要人工审核一批答案，标记哪些内容是文档中没有的；Citation准确性则要检查标注的来源是否真的支撑答案内容，可以通过相似度阈值来自动化评估一部分。
后处理验证是最后一道保险。即使前面做得再好，还需要一套自动化的质量检测机制。事实核查可以用另一个LLM来做交叉验证，让它判断生成的答案和检索的文档是否一致，输出一个一致性分数。置信度评分则可以综合多个信号：检索文档的相关性分数、模型输出的logits概率、答案和文档的语义相似度，加权计算出一个综合置信度，低于阈值就触发人工审核或者拒绝回答。
publicclassConfidenceEvaluator{
publicdoublecalculateConfidence(
String answer,
List<DocumentChunk> chunks,
GenerationMetrics metrics){
// 检索相关性分数（0-1）
double retrievalScore = chunks.stream()
.mapToDouble(c -> c.getRelevanceScore())
.max()
.orElse(0.0);
// 模型生成概率（从logits计算）
double generationProb = metrics.getAverageTokenProbability();
// 答案与文档的语义相似度
double semanticSimilarity =calculateSemanticMatch(answer, chunks);
// 加权计算综合置信度
return0.3* retrievalScore +
0.4* generationProb +
0.3* semanticSimilarity;
}
privatedoublecalculateSemanticMatch(String answer,List<DocumentChunk> chunks){
float[] answerEmbed = embeddingService.encode(answer);
return chunks.stream()
.mapToDouble(chunk ->{
float[] chunkEmbed = embeddingService.encode(chunk.getContent());
returncosineSimilarity(answerEmbed, chunkEmbed);
})
.max()
.orElse(0.0);
}
}性能优化上有几个实践点值得注意。向量检索可以用HNSW索引加速，这种基于图的近似最近邻算法能在大规模数据集上做到毫秒级响应。重排序如果太慢可以只对top-30做精排，大部分情况下这个范围已经足够。chunk切分时预计算好embedding存储下来避免实时计算，这能显著降低检索延迟。prompt构造时要控制好总token数不要超模型窗口限制，如果上下文太长可以做二次摘要或者只保留最相关的片段。
扩展思考与权衡
准确性和流畅性的权衡是个经典话题。这确实是个trade-off，但我认为不同场景的优先级不同。如果是法律咨询或者医疗问答这种高风险场景，准确性必须是第一位的，用户宁可接受一个机械但正确的答案，也不希望被误导。但如果是面向C端的通用客服，适当的拟人化表达能提升用户体验，这时候可以在保证核心事实准确的前提下，允许模型在措辞上有一定灵活度。实践中可以把回答分成两部分，第一部分严格基于文档给出事实性答案并标注引用，第二部分用更自然的语言做补充说明，这样既保证了可信度又不失友好性。
成本问题是工程化绕不开的话题。成本主要集中在三个地方：向量检索的存储和计算、重排序模型的推理、以及LLM的生成调用。向量检索可以用量化技术把float32压缩到int8，存储成本能降到原来的四分之一，检索速度还能提升。重排序不是每次请求都必须的，可以根据向量检索的置信度分数来决定要不要启动，比如top-1结果的相关性已经超过0.9，就可以跳过重排序直接返回。LLM调用是大头，这里可以用缓存策略，对高频问题预先生成答案，或者用更小的模型处理简单查询，复杂问题才调用大模型。如果用开源的embedding模型加本地部署的向量库，单次检索成本能控制在毫厘级别，真正的成本压力在LLM调用上，通过缓存和模型分级，可以让80%的请求避免调用最贵的模型。
用户体验的考量能体现产品思维。Citation的价值取决于用户的信任成本。对于专业用户，比如法务人员查询法条解读，他们必须看到原文出处才敢采信结果，这时候Citation就是刚需。但对于普通消费者问"这个优惠券怎么用"，他们可能不关心来源，只要答案清晰就行。我会做分层展示，默认给出答案，把引用以小字或折叠形式放在下方，需要验证的用户可以展开查看。这样既不干扰普通用户的阅读体验，又能满足专业用户的溯源需求。至于怎么判断用户是否需要Citation，可以根据问题类型做预判，涉及金额、时间、政策的问题自动展开引用，或者通过AB测试观察不同用户群体的点击率来动态调整。
技术演进的趋势也值得关注。除了前面说的方案，业界其实还在探索一些更前沿的方向。Fine-tuning和RAG结合的思路很有潜力，纯RAG依赖检索质量，但如果能用企业私有数据对模型做轻量级微调，让它学会特定领域的表达习惯和知识结构，再配合RAG做事实增强，效果会更好。比如客服场景，微调后的模型能更准确理解行业黑话，检索召回的准确率就会提升。多模态RAG的趋势也在兴起，现在很多文档不只是纯文本，还包含图表、流程图、产品图片。如果能把这些非文本信息也纳入检索范围，用多模态模型来理解和生成答案，就能覆盖更复杂的场景。比如用户问"这个产品的接口定义是什么"，系统可以召回架构图，直接在图上标注关键信息返回给用户。
监控和迭代的意识是工程成熟度的体现。RAG系统不是部署上线就完事了，更重要的是建立持续优化的机制。需要记录每次查询的检索召回情况、模型生成的置信度、用户的反馈行为，这些数据是后续优化的基础。比如发现某类问题的幻觉率特别高，就要回过头检查是文档覆盖不足，还是检索策略有问题。如果监控发现用户频繁追问同一类问题，说明第一次答案质量不够，这时候可能需要调整chunk切分粒度，或者优化prompt模板。甚至可以把高频bad case标注后用来做few-shot示例，让模型从错误中学习。好的系统不是一开始就完美，而是具备自我诊断和进化的能力，这需要在设计阶段就埋好监控埋点和反馈机制。