1. 从一条新闻说起为什么“可信新闻AI”是个真需求前阵子刷到一条消息NewsGuard 推出了一款 AI 聊天机器人定位很明确——专门用来提供“可信新闻”。这个标题乍一看像是又一个套壳大模型的新闻聚合工具但仔细琢磨它切中的其实是一个被很多人忽略的痛点当所有人都在用 AI 生成内容的时候谁来保证你读到的东西是真的我自己做 AI 应用开发这几年接触过不少内容类项目。说实话大部分团队在做 AI 问答产品时第一优先级永远是“回答得像不像人”而不是“回答得对不对”。这导致一个很尴尬的局面用户问一个新闻事件AI 能洋洋洒洒写五百字语气专业、结构完整但里面一半的事实是编的。这不是模型能力问题是产品设计思路的问题。NewsGuard 这个产品的核心逻辑我理解下来大概是这样的它不是一个通用聊天机器人而是一个以可信信源为约束条件的新闻问答系统。用户问它某个事件的来龙去脉它不会直接让大模型自由发挥而是先从经过审核的新闻源里检索相关内容再基于检索结果生成回答并且会标注信息来源。这套思路在技术圈其实不算新鲜RAG检索增强生成已经是很成熟的方案了但把它专门用在“新闻可信度”这个场景上并且做成面向普通用户的聊天产品这个切入点值得聊一聊。这篇文章我会从几个角度拆解这个产品背后的技术逻辑和工程实践它到底解决了什么问题、核心技术方案怎么选、如果要自己搭一个类似的系统需要哪些步骤、以及在实际操作中会遇到哪些坑。不管你是做 AI 应用的开发者还是对可信内容产品感兴趣的产品经理应该都能从中找到一些可参考的东西。2. 核心问题拆解新闻场景下的大模型到底差在哪2.1 大模型做新闻问答的三个致命短板先说清楚问题才能理解方案。我用过不少大模型做新闻类问答总结下来有三个绕不过去的短板。第一个是事实幻觉。大模型本质上是概率模型它生成的是“最像正确答案的文本”而不是“经过验证的事实”。你问它“某公司上个月发布了什么产品”它可能会根据训练数据里的模式编出一个听起来很合理但根本不存在的东西。在新闻场景下这种幻觉的破坏力极大因为用户往往没有能力去核实。第二个是时效性缺失。大模型的训练数据有截止日期之后发生的事情它一概不知。新闻恰恰是时效性极强的内容今天发生的事用户今天就要问。你不可能每天重新训练一次模型成本扛不住而且训练本身也需要时间。第三个是信源不可追溯。就算模型答对了用户也不知道这个信息是从哪来的。是某个权威媒体的报道还是某个论坛的帖子还是模型自己编的没有信源标注用户就无法判断信息的可信度。这在新闻场景下是致命的因为新闻的核心价值就在于“可核实”。2.2 为什么传统搜索不够用有人可能会说那用户直接去搜索引擎不就行了问题是搜索引擎返回的是一堆链接用户需要自己点进去、自己读、自己判断哪个可信。这个过程的认知成本很高而且对于复杂事件用户往往需要综合多个来源才能形成完整理解。AI 聊天机器人的价值在于它可以把“检索、筛选、综合、表达”这几个步骤一次性完成用户只需要问一个问题就能得到一个结构化的回答。但前提是这个回答必须是可信的。这就是 NewsGuard 这类产品要解决的核心矛盾用 AI 的便利性但不能牺牲新闻的可信度。2.3 可信新闻 AI 的三个设计原则基于上面的分析我认为一个可信新闻 AI 产品必须满足三个设计原则。第一回答必须有据可查。每一条事实性陈述都应该能追溯到具体的信源而且信源本身需要经过可信度评估。这不是说 AI 不能做总结和归纳而是说总结和归纳必须基于真实的、可核实的材料。第二信源质量要有分级。不是所有新闻源都同等可信。通讯社、老牌媒体、官方发布渠道的可信度和自媒体、匿名爆料的可信度显然不一样。系统需要对信源进行分级并且在回答中体现这种分级。第三不确定的事情要说不确定。如果检索到的信息不足以回答用户的问题AI 应该明确告诉用户“目前没有找到可靠的信息”而不是硬编一个答案。这一点说起来简单做起来很难因为大模型天生就有“把话说圆”的倾向。3. 技术方案选型RAG 为什么是当前最优解3.1 从“重新训练”到“检索增强”的思路转变早期做新闻问答很多团队的第一反应是微调模型。收集大量新闻数据标注问答对然后 fine-tune 一个大模型。这个方案的问题很明显成本高、周期长、更新慢。新闻每天都在变你不可能每天都重新训练。RAG 的思路完全不同。它不改模型本身而是在模型之外挂一个“知识库”。用户提问时系统先从知识库里检索相关内容然后把检索结果和用户问题一起塞给模型让模型基于这些材料来回答。这样知识库可以随时更新模型本身不需要动。打个比方微调模型像是让学生把整本教材背下来再考试RAG 像是开卷考试——学生不需要背但需要知道去哪本书的哪一页找答案。对于新闻这种时效性强、更新频繁的场景开卷考试显然是更合理的选择。3.2 RAG 系统的四个核心模块一个完整的 RAG 系统通常包含四个模块文档处理、向量化存储、检索、生成。文档处理负责把各种格式的新闻内容网页、RSS、API 返回的 JSON清洗成统一的文本格式并且切分成合适大小的片段。向量化存储负责把文本片段转换成向量存进向量数据库。检索模块负责根据用户问题找到最相关的片段。生成模块负责把检索结果和用户问题一起交给大模型生成最终回答。这四个模块里最容易出问题的是文档处理和检索。文档处理不好检索出来的内容就是垃圾检索不准生成的内容就会跑偏。后面我会详细讲这两个环节的实操要点。3.3 信源可信度评估怎么融入 RAG 流程NewsGuard 这类产品的特殊之处在于它需要在 RAG 流程中融入信源可信度评估。我的做法是在文档处理阶段就给每个信源打一个可信度分数然后在检索阶段把这个分数作为排序的一个因子。具体来说可信度分数可以基于几个维度信源的历史准确率、是否有明确的编辑规范、是否标注了作者和发布时间、是否被其他可信信源引用过。这些维度可以量化成 0 到 1 之间的分数然后在检索时用加权的方式影响排序结果。这样做的好处是当用户问一个争议性话题时系统会优先返回高可信度信源的内容而不是被低质量信源带偏。4. 实操过程从零搭建一个可信新闻问答原型4.1 环境准备与工具选型先说环境。我用的技术栈是 Python FastAPI PostgreSQL pgvector 一个大模型 API。选 pgvector 而不是专门的向量数据库比如 Pinecone、Weaviate是因为新闻问答场景的数据量通常不会特别大几万到几十万条文档片段PostgreSQL 完全扛得住而且省去了维护额外服务的麻烦。大模型 API 的选择上我建议用支持长上下文至少 32K tokens的模型因为新闻问答往往需要综合多个来源的内容上下文太短会丢信息。具体用哪家就不展开了市面上主流的几家都能满足需求。依赖安装很简单pip install fastapi uvicorn psycopg2-binary pgvector sentence-transformers httpxEmbedding 模型我用的是sentence-transformers里的多语言模型因为新闻内容可能涉及多种语言。如果你只做中文新闻可以用专门的中文 embedding 模型效果会更好。4.2 新闻数据的采集与清洗数据采集是第一步也是最脏最累的一步。新闻源通常有几种获取方式RSS、API、网页抓取。RSS 最省事但很多媒体已经不提供完整的 RSS 了。API 最规范但通常需要付费。网页抓取最灵活但需要处理反爬、动态加载、格式不统一等问题。我的建议是优先用 RSS 和公开 API实在不行再上网页抓取。抓取的时候注意遵守网站的 robots.txt控制请求频率不要给人家服务器造成压力。清洗环节要做几件事去掉 HTML 标签、去掉广告和导航栏等噪音内容、统一日期格式、提取标题和正文。这里推荐用trafilatura这个库它在新闻正文提取方面做得相当不错比 BeautifulSoup 手写规则省事很多。import trafilatura def extract_article(html): result trafilatura.extract(html, include_commentsFalse, include_tablesFalse) return result清洗完之后每条新闻应该是一个结构化的对象包含标题、正文、来源、发布时间、URL 等字段。4.3 文本切分与向量化入库文本切分是个技术活。切得太碎检索出来的片段缺乏上下文切得太长检索精度会下降。我的经验是新闻类内容按 300 到 500 字切分比较合适同时保留一定的重叠比如 50 字避免关键信息被切断。切分的时候最好按语义边界切而不是机械地按字数切。比如按段落切如果某个段落太长再按句子切。这样能保证每个片段都是语义完整的。向量化就是用 embedding 模型把每个文本片段转成一个向量。这个过程比较耗时建议批量处理并且把结果缓存起来避免重复计算。入库的时候除了向量本身还要存原始文本、来源、发布时间、可信度分数等元数据。这些元数据在检索时可以用来做过滤和排序。import psycopg2 from pgvector.psycopg2 import register_vector conn psycopg2.connect(dbnamenews userpostgres) register_vector(conn) cur conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS news_chunks ( id SERIAL PRIMARY KEY, content TEXT, source VARCHAR(255), publish_date TIMESTAMP, credibility FLOAT, embedding vector(768) ) )4.4 检索策略不只是向量相似度很多人做 RAG 只用了向量相似度检索这在实际场景中往往不够。向量检索擅长语义匹配但对关键词匹配不敏感。比如用户问“某公司 CEO 是谁”向量检索可能会返回一堆关于这家公司的内容但不一定包含 CEO 的具体信息。我的做法是混合检索向量相似度 关键词匹配BM25 元数据过滤。先用元数据过滤掉明显不相关的内容比如时间范围不对的然后用向量和 BM25 分别检索最后用加权的方式合并结果。权重的设置需要根据实际效果调。一般来说向量检索权重 0.6BM25 权重 0.4 是个不错的起点。如果用户的问题包含明确的关键词比如人名、地名可以适当提高 BM25 的权重。4.5 生成环节的提示词设计生成环节的核心是提示词。一个好的提示词应该包含几个要素角色设定、任务说明、约束条件、输出格式。角色设定让模型知道自己是“新闻问答助手”而不是“创意写作助手”。任务说明告诉模型要基于提供的材料回答问题。约束条件包括“不要编造信息”“如果材料不足就说不知道”“标注信息来源”。输出格式可以指定用分点的方式方便用户阅读。我常用的提示词模板大概长这样你是一个新闻问答助手。请基于以下材料回答用户的问题。 要求 1. 只使用材料中提供的信息不要编造任何事实。 2. 如果材料不足以回答问题请明确说明。 3. 每条事实性陈述后面标注来源编号。 4. 用简洁的中文回答分点列出关键信息。 材料 {context} 用户问题{question}这个模板看起来简单但实际效果比那些花里胡哨的提示词好很多。关键是要把约束条件写清楚尤其是“不要编造”和“材料不足就说不知道”这两条。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。排查思路是从后往前查先看检索出来的片段是不是真的不相关再看 embedding 模型是不是适合你的数据最后看切分策略是不是有问题。如果检索出来的片段明显跑题大概率是 embedding 模型的问题。不同的 embedding 模型在不同领域的效果差异很大。新闻类内容建议用在大规模新闻语料上训练过的模型。如果找不到专门的新闻 embedding 模型可以用通用的多语言模型但效果会打折扣。如果检索出来的片段部分相关但不完整可能是切分策略的问题。试着调整切分粒度或者增加重叠长度。5.2 模型还是会产生幻觉即使给了材料模型有时候还是会编。这种情况通常有两个原因一是材料本身不够明确模型在“填空”二是提示词的约束不够强。解决办法是在提示词里加更严格的约束比如“如果材料中没有明确提到某个信息不要根据常识推断”。另外可以在生成之后加一个校验步骤用另一个模型调用检查生成的内容是否都能在材料中找到依据。这个步骤会增加成本但对可信度要求高的场景是值得的。5.3 信源可信度分数怎么定这是个主观性很强的问题。我的做法是先用一个简单的规则系统官方通讯社和知名媒体给 0.9一般媒体给 0.7自媒体给 0.4匿名来源给 0.2。然后根据实际使用中的反馈逐步调整。不要试图一开始就做一个完美的可信度评估系统先跑起来再迭代。用户反馈是最好的调参依据。5.4 性能优化响应太慢怎么破RAG 系统的响应时间主要花在三个地方检索、embedding、生成。检索和 embedding 通常很快几百毫秒生成是大头几秒到十几秒。优化生成速度有几个办法用更快的模型、减少上下文长度、流式输出。流式输出是最有效的用户看到第一个字的时间可以缩短到一秒以内体验会好很多。检索方面确保向量索引建好了。pgvector 支持 IVFFlat 和 HNSW 两种索引HNSW 查询更快但建索引更慢数据量大的话建议用 HNSW。5.5 常见问题速查表问题现象可能原因排查方向检索结果不相关embedding 模型不匹配换用新闻领域模型回答内容不完整切分粒度过细增大切分长度或重叠模型编造事实提示词约束不足加强约束条件响应时间过长生成模型太慢换模型或流式输出信源排序不合理可信度权重设置不当调整权重系数重复内容太多数据源去重不彻底加去重逻辑6. 这个方向还能怎么扩展搭完原型之后我一直在想这个方向还能怎么往下走。几个我觉得有意思的扩展方向。一个是多信源交叉验证。当多个可信信源对同一事件的描述一致时可以提高回答的可信度当信源之间有矛盾时系统应该把矛盾点指出来让用户自己判断。这个功能在争议性话题上特别有价值。另一个是个性化信源偏好。不同用户对“可信”的定义可能不一样。有人更信任官方媒体有人更信任独立记者。系统可以允许用户配置自己的信源偏好检索时按偏好加权。还有一个是时间线自动生成。对于持续发展的事件用户可以问“给我梳理一下这件事的时间线”系统自动从多个信源中提取关键节点生成一条清晰的时间线。这个功能对新闻追踪场景很实用。技术上这些扩展都不难实现核心还是那套 RAG 流程只是在检索和生成环节加一些逻辑。难的是产品层面的设计怎么让用户理解系统的可信度评估逻辑怎么在“给用户自由”和“保证信息质量”之间找到平衡。我自己在实际操作中的体会是做可信新闻 AI技术只占三成七成是对“可信”这个概念的深入理解和产品化表达。模型可以换架构可以调但如果你自己都不清楚什么叫“可信”做出来的东西就很难让用户信任。 
长河君 · 2026/10/26 7:13:17 · 阅读 1.2k 基于RAG的可信新闻AI问答系统：从技术原理到工程实践
1. 从一条新闻说起为什么“可信新闻AI”是个真需求前阵子刷到一条消息NewsGuard 推出了一款 AI 聊天机器人定位很明确——专门用来提供“可信新闻”。这个标题乍一看像是又一个套壳大模型的新闻聚合工具但仔细琢磨它切中的其实是一个被很多人忽略的痛点当所有人都在用 AI 生成内容的时候谁来保证你读到的东西是真的我自己做 AI 应用开发这几年接触过不少内容类项目。说实话大部分团队在做 AI 问答产品时第一优先级永远是“回答得像不像人”而不是“回答得对不对”。这导致一个很尴尬的局面用户问一个新闻事件AI 能洋洋洒洒写五百字语气专业、结构完整但里面一半的事实是编的。这不是模型能力问题是产品设计思路的问题。NewsGuard 这个产品的核心逻辑我理解下来大概是这样的它不是一个通用聊天机器人而是一个以可信信源为约束条件的新闻问答系统。用户问它某个事件的来龙去脉它不会直接让大模型自由发挥而是先从经过审核的新闻源里检索相关内容再基于检索结果生成回答并且会标注信息来源。这套思路在技术圈其实不算新鲜RAG检索增强生成已经是很成熟的方案了但把它专门用在“新闻可信度”这个场景上并且做成面向普通用户的聊天产品这个切入点值得聊一聊。这篇文章我会从几个角度拆解这个产品背后的技术逻辑和工程实践它到底解决了什么问题、核心技术方案怎么选、如果要自己搭一个类似的系统需要哪些步骤、以及在实际操作中会遇到哪些坑。不管你是做 AI 应用的开发者还是对可信内容产品感兴趣的产品经理应该都能从中找到一些可参考的东西。2. 核心问题拆解新闻场景下的大模型到底差在哪2.1 大模型做新闻问答的三个致命短板先说清楚问题才能理解方案。我用过不少大模型做新闻类问答总结下来有三个绕不过去的短板。第一个是事实幻觉。大模型本质上是概率模型它生成的是“最像正确答案的文本”而不是“经过验证的事实”。你问它“某公司上个月发布了什么产品”它可能会根据训练数据里的模式编出一个听起来很合理但根本不存在的东西。在新闻场景下这种幻觉的破坏力极大因为用户往往没有能力去核实。第二个是时效性缺失。大模型的训练数据有截止日期之后发生的事情它一概不知。新闻恰恰是时效性极强的内容今天发生的事用户今天就要问。你不可能每天重新训练一次模型成本扛不住而且训练本身也需要时间。第三个是信源不可追溯。就算模型答对了用户也不知道这个信息是从哪来的。是某个权威媒体的报道还是某个论坛的帖子还是模型自己编的没有信源标注用户就无法判断信息的可信度。这在新闻场景下是致命的因为新闻的核心价值就在于“可核实”。2.2 为什么传统搜索不够用有人可能会说那用户直接去搜索引擎不就行了问题是搜索引擎返回的是一堆链接用户需要自己点进去、自己读、自己判断哪个可信。这个过程的认知成本很高而且对于复杂事件用户往往需要综合多个来源才能形成完整理解。AI 聊天机器人的价值在于它可以把“检索、筛选、综合、表达”这几个步骤一次性完成用户只需要问一个问题就能得到一个结构化的回答。但前提是这个回答必须是可信的。这就是 NewsGuard 这类产品要解决的核心矛盾用 AI 的便利性但不能牺牲新闻的可信度。2.3 可信新闻 AI 的三个设计原则基于上面的分析我认为一个可信新闻 AI 产品必须满足三个设计原则。第一回答必须有据可查。每一条事实性陈述都应该能追溯到具体的信源而且信源本身需要经过可信度评估。这不是说 AI 不能做总结和归纳而是说总结和归纳必须基于真实的、可核实的材料。第二信源质量要有分级。不是所有新闻源都同等可信。通讯社、老牌媒体、官方发布渠道的可信度和自媒体、匿名爆料的可信度显然不一样。系统需要对信源进行分级并且在回答中体现这种分级。第三不确定的事情要说不确定。如果检索到的信息不足以回答用户的问题AI 应该明确告诉用户“目前没有找到可靠的信息”而不是硬编一个答案。这一点说起来简单做起来很难因为大模型天生就有“把话说圆”的倾向。3. 技术方案选型RAG 为什么是当前最优解3.1 从“重新训练”到“检索增强”的思路转变早期做新闻问答很多团队的第一反应是微调模型。收集大量新闻数据标注问答对然后 fine-tune 一个大模型。这个方案的问题很明显成本高、周期长、更新慢。新闻每天都在变你不可能每天都重新训练。RAG 的思路完全不同。它不改模型本身而是在模型之外挂一个“知识库”。用户提问时系统先从知识库里检索相关内容然后把检索结果和用户问题一起塞给模型让模型基于这些材料来回答。这样知识库可以随时更新模型本身不需要动。打个比方微调模型像是让学生把整本教材背下来再考试RAG 像是开卷考试——学生不需要背但需要知道去哪本书的哪一页找答案。对于新闻这种时效性强、更新频繁的场景开卷考试显然是更合理的选择。3.2 RAG 系统的四个核心模块一个完整的 RAG 系统通常包含四个模块文档处理、向量化存储、检索、生成。文档处理负责把各种格式的新闻内容网页、RSS、API 返回的 JSON清洗成统一的文本格式并且切分成合适大小的片段。向量化存储负责把文本片段转换成向量存进向量数据库。检索模块负责根据用户问题找到最相关的片段。生成模块负责把检索结果和用户问题一起交给大模型生成最终回答。这四个模块里最容易出问题的是文档处理和检索。文档处理不好检索出来的内容就是垃圾检索不准生成的内容就会跑偏。后面我会详细讲这两个环节的实操要点。3.3 信源可信度评估怎么融入 RAG 流程NewsGuard 这类产品的特殊之处在于它需要在 RAG 流程中融入信源可信度评估。我的做法是在文档处理阶段就给每个信源打一个可信度分数然后在检索阶段把这个分数作为排序的一个因子。具体来说可信度分数可以基于几个维度信源的历史准确率、是否有明确的编辑规范、是否标注了作者和发布时间、是否被其他可信信源引用过。这些维度可以量化成 0 到 1 之间的分数然后在检索时用加权的方式影响排序结果。这样做的好处是当用户问一个争议性话题时系统会优先返回高可信度信源的内容而不是被低质量信源带偏。4. 实操过程从零搭建一个可信新闻问答原型4.1 环境准备与工具选型先说环境。我用的技术栈是 Python FastAPI PostgreSQL pgvector 一个大模型 API。选 pgvector 而不是专门的向量数据库比如 Pinecone、Weaviate是因为新闻问答场景的数据量通常不会特别大几万到几十万条文档片段PostgreSQL 完全扛得住而且省去了维护额外服务的麻烦。大模型 API 的选择上我建议用支持长上下文至少 32K tokens的模型因为新闻问答往往需要综合多个来源的内容上下文太短会丢信息。具体用哪家就不展开了市面上主流的几家都能满足需求。依赖安装很简单pip install fastapi uvicorn psycopg2-binary pgvector sentence-transformers httpxEmbedding 模型我用的是sentence-transformers里的多语言模型因为新闻内容可能涉及多种语言。如果你只做中文新闻可以用专门的中文 embedding 模型效果会更好。4.2 新闻数据的采集与清洗数据采集是第一步也是最脏最累的一步。新闻源通常有几种获取方式RSS、API、网页抓取。RSS 最省事但很多媒体已经不提供完整的 RSS 了。API 最规范但通常需要付费。网页抓取最灵活但需要处理反爬、动态加载、格式不统一等问题。我的建议是优先用 RSS 和公开 API实在不行再上网页抓取。抓取的时候注意遵守网站的 robots.txt控制请求频率不要给人家服务器造成压力。清洗环节要做几件事去掉 HTML 标签、去掉广告和导航栏等噪音内容、统一日期格式、提取标题和正文。这里推荐用trafilatura这个库它在新闻正文提取方面做得相当不错比 BeautifulSoup 手写规则省事很多。import trafilatura def extract_article(html): result trafilatura.extract(html, include_commentsFalse, include_tablesFalse) return result清洗完之后每条新闻应该是一个结构化的对象包含标题、正文、来源、发布时间、URL 等字段。4.3 文本切分与向量化入库文本切分是个技术活。切得太碎检索出来的片段缺乏上下文切得太长检索精度会下降。我的经验是新闻类内容按 300 到 500 字切分比较合适同时保留一定的重叠比如 50 字避免关键信息被切断。切分的时候最好按语义边界切而不是机械地按字数切。比如按段落切如果某个段落太长再按句子切。这样能保证每个片段都是语义完整的。向量化就是用 embedding 模型把每个文本片段转成一个向量。这个过程比较耗时建议批量处理并且把结果缓存起来避免重复计算。入库的时候除了向量本身还要存原始文本、来源、发布时间、可信度分数等元数据。这些元数据在检索时可以用来做过滤和排序。import psycopg2 from pgvector.psycopg2 import register_vector conn psycopg2.connect(dbnamenews userpostgres) register_vector(conn) cur conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS news_chunks ( id SERIAL PRIMARY KEY, content TEXT, source VARCHAR(255), publish_date TIMESTAMP, credibility FLOAT, embedding vector(768) ) )4.4 检索策略不只是向量相似度很多人做 RAG 只用了向量相似度检索这在实际场景中往往不够。向量检索擅长语义匹配但对关键词匹配不敏感。比如用户问“某公司 CEO 是谁”向量检索可能会返回一堆关于这家公司的内容但不一定包含 CEO 的具体信息。我的做法是混合检索向量相似度 关键词匹配BM25 元数据过滤。先用元数据过滤掉明显不相关的内容比如时间范围不对的然后用向量和 BM25 分别检索最后用加权的方式合并结果。权重的设置需要根据实际效果调。一般来说向量检索权重 0.6BM25 权重 0.4 是个不错的起点。如果用户的问题包含明确的关键词比如人名、地名可以适当提高 BM25 的权重。4.5 生成环节的提示词设计生成环节的核心是提示词。一个好的提示词应该包含几个要素角色设定、任务说明、约束条件、输出格式。角色设定让模型知道自己是“新闻问答助手”而不是“创意写作助手”。任务说明告诉模型要基于提供的材料回答问题。约束条件包括“不要编造信息”“如果材料不足就说不知道”“标注信息来源”。输出格式可以指定用分点的方式方便用户阅读。我常用的提示词模板大概长这样你是一个新闻问答助手。请基于以下材料回答用户的问题。 要求 1. 只使用材料中提供的信息不要编造任何事实。 2. 如果材料不足以回答问题请明确说明。 3. 每条事实性陈述后面标注来源编号。 4. 用简洁的中文回答分点列出关键信息。 材料 {context} 用户问题{question}这个模板看起来简单但实际效果比那些花里胡哨的提示词好很多。关键是要把约束条件写清楚尤其是“不要编造”和“材料不足就说不知道”这两条。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。排查思路是从后往前查先看检索出来的片段是不是真的不相关再看 embedding 模型是不是适合你的数据最后看切分策略是不是有问题。如果检索出来的片段明显跑题大概率是 embedding 模型的问题。不同的 embedding 模型在不同领域的效果差异很大。新闻类内容建议用在大规模新闻语料上训练过的模型。如果找不到专门的新闻 embedding 模型可以用通用的多语言模型但效果会打折扣。如果检索出来的片段部分相关但不完整可能是切分策略的问题。试着调整切分粒度或者增加重叠长度。5.2 模型还是会产生幻觉即使给了材料模型有时候还是会编。这种情况通常有两个原因一是材料本身不够明确模型在“填空”二是提示词的约束不够强。解决办法是在提示词里加更严格的约束比如“如果材料中没有明确提到某个信息不要根据常识推断”。另外可以在生成之后加一个校验步骤用另一个模型调用检查生成的内容是否都能在材料中找到依据。这个步骤会增加成本但对可信度要求高的场景是值得的。5.3 信源可信度分数怎么定这是个主观性很强的问题。我的做法是先用一个简单的规则系统官方通讯社和知名媒体给 0.9一般媒体给 0.7自媒体给 0.4匿名来源给 0.2。然后根据实际使用中的反馈逐步调整。不要试图一开始就做一个完美的可信度评估系统先跑起来再迭代。用户反馈是最好的调参依据。5.4 性能优化响应太慢怎么破RAG 系统的响应时间主要花在三个地方检索、embedding、生成。检索和 embedding 通常很快几百毫秒生成是大头几秒到十几秒。优化生成速度有几个办法用更快的模型、减少上下文长度、流式输出。流式输出是最有效的用户看到第一个字的时间可以缩短到一秒以内体验会好很多。检索方面确保向量索引建好了。pgvector 支持 IVFFlat 和 HNSW 两种索引HNSW 查询更快但建索引更慢数据量大的话建议用 HNSW。5.5 常见问题速查表问题现象可能原因排查方向检索结果不相关embedding 模型不匹配换用新闻领域模型回答内容不完整切分粒度过细增大切分长度或重叠模型编造事实提示词约束不足加强约束条件响应时间过长生成模型太慢换模型或流式输出信源排序不合理可信度权重设置不当调整权重系数重复内容太多数据源去重不彻底加去重逻辑6. 这个方向还能怎么扩展搭完原型之后我一直在想这个方向还能怎么往下走。几个我觉得有意思的扩展方向。一个是多信源交叉验证。当多个可信信源对同一事件的描述一致时可以提高回答的可信度当信源之间有矛盾时系统应该把矛盾点指出来让用户自己判断。这个功能在争议性话题上特别有价值。另一个是个性化信源偏好。不同用户对“可信”的定义可能不一样。有人更信任官方媒体有人更信任独立记者。系统可以允许用户配置自己的信源偏好检索时按偏好加权。还有一个是时间线自动生成。对于持续发展的事件用户可以问“给我梳理一下这件事的时间线”系统自动从多个信源中提取关键节点生成一条清晰的时间线。这个功能对新闻追踪场景很实用。技术上这些扩展都不难实现核心还是那套 RAG 流程只是在检索和生成环节加一些逻辑。难的是产品层面的设计怎么让用户理解系统的可信度评估逻辑怎么在“给用户自由”和“保证信息质量”之间找到平衡。我自己在实际操作中的体会是做可信新闻 AI技术只占三成七成是对“可信”这个概念的深入理解和产品化表达。模型可以换架构可以调但如果你自己都不清楚什么叫“可信”做出来的东西就很难让用户信任。