# 开放平台智能问答建设方案
# 项目背景
open.seeyoncloud.com是致远互联推出的开放平台，主要面向开发者、技术运维、合作伙伴和第三方，提供技术/运维资料支持，以及常见问题解决方案，是交付侧最重要的一个知识分享平台。
开放平台提供了丰富的技术资料，也提供了FAQ全文检索能力供大家查找资料，但传统的检索方法在NLP自然语言处理上面表现并不好，以至于同一个问题不同表达就导致匹配不到正确答案。随着ChatGpt、DeepSeek的爆火，我们发现大模型在NLP方面表现很好，基于大模型的智能检索已经成为各企业优先落地的项目。
2025年初，为了提升开放平台检索准确率，我们拟定基于大模型的最佳实践构建自己的智能问答应用！
# 现状分析
在立项前，我们进行了现状分析：
目前市面的大模型在NLP自然语言处理能力上表现都不错，相同问题不同表达都能被模型敏锐识别成一个问题。但大模型存在一个严重局限性：无法回答企业私域问题！在询问“V5产品线有哪些？”、“A8N 9.0信创部署手册在哪里？”这类问题时，大模型并没有对我们的知识进行预训练，以至于最终答非所问。
用户：V5的产品线有哪些？
大模型：以“V5”直接命名的产品线主要集中在智能手机和智能搬运机器人领域。如HONOR Magic V5、米豆智运V5系列、跨越星V5。
我们了解到，大模型不会记忆用户的问题---给模型喂再多知识也不会自我进化。为了解决大模型“知识脱轨”的问题，可以通过微调或RAG方案来处理：
- 模型微调（Fine-Tuning）是指在预训练的大语言模型（如DeepSeek、Qwen等）基础上，使用特定领域数据（如开放平台知识库）进行二次训练，使模型掌握开放平台的知识。这种方案需要不少的成本，并且知识更新时需要再次微调训练，不适合知识问答快速落地。
- RAG检索增强生成 ，采用外挂知识库，在进行query前先从外挂知识库提取相似性答案，随提示词推送给大模型，以便让大模型的回复准确。这种方案不对模型进行任何训练，所需成本较低，只要准备好知识就能快速落地，知识更新也非常容易。
用户：V5的产品线有哪些？ 请结合参考资料作答：致远协同管理软件V5产品线有A6、A8、G6、A8N、G6N多条产品线。
大模型：您好，根据您提供的信息，贵公司V5产品线具体包括以下型号：A6、A8、G6、A8N、G6N。
基于以上现状分析，再结合网上智能问答解决方案，我们初步拟定使用RAG+智能体的方案进行开放平台智能问答应用的落地。
× [用户] → [大模型]
√ [用户] → [RAG智能体Agent] → [大模型]
# 适配策略
# 架构策略
RAG的落地实现，需要完成两个核心场景：
- 场景一，知识存储：准备好资料文档，通过代码将文档进行拆分，拆分后的文档通过Embedding模型转换为高维向量，将数据存储到向量数据库
- 场景二，知识检索：用户提问时，将用户问题向量化并从场景一的知识库检索出语义相关的知识，最后交由大模型进行汇总分析，给出结果
如按行业主流架构实现RAG，需要进行代码开发，以及结合Embedding Model、向量数据库等一系列组件才能实现，开发周期长，所需开发资源高。如需快速完成智能问答应用，直接选择开箱即用的RAG智能体应用是最快实现路径！
在选型之初，国内比较主流的智能体应用有FastGPT、Dify、Coze等，各有特色：
Coze：适合快速搭建聊天机器人，无需/少量需要编程，适合 C 端用户或轻量级企业应用。
Dify：适合开发者构建复杂 AI 应用，支持多模型切换和私有化部署。
FastGPT：适合企业知识库管理，需高效问答系统，且IT团队具备本地化运维能力。
回归选型本质，我们需要建设智能问答应用，其中FastGPT在知识库的存储和检索技术方面都表现突出，故最终选择此平台。
注：为什么没有选择公司的CoMi作为智能问答的平台？在2025年初还没有CoMi，当时公司有开箱即用的智能问答，但可配置性不足。
# 部署维护策略
公司信息中心正在统建AI智能平台，部署形态为FastGPT本地化商业版。FastGPT提供了本地部署社区版、本地部署商业版和在线Saas版本，为了知识库数据安全，肯定采用本地化部署，并且商业版功能全面，有官方技术支持，是不错的选择。
我们只需向信息中心申请独立账号维护我们的智能体即可。
# 实施步骤
按照RAG运行原理，我们需要先建设知识库，再设计可用的智能问答智能体。
# 1、知识库建设
建设知识库对于开放平台非常容易，开放平台自2022年改版以来建设维护了几千份技术资料：开发组件类手册、安装部署类手册一应俱全，交付过程中遇到的小问题和解决方案均有录入开放平台FAQ库中。FastGPT应用程序完成了文档的切割、文本向量化和向量数据存储，只需要选择合适的Embedding模型，即可开箱即用。
第一期，我们将开放平台资料导出为文本文件，并导入FastGpt知识库，由FastGpt自动进行向量化存储。
第二期，我们完成了代码开发接入FastGpt知识库，开放平台侧任何增删改查资料都会通过接口的形式同步更新FastGpt，这样就彻底实现了知识的自动化更新。
FastGpt提供了知识库创建（
/api/core/dataset/create）、删除等Rest接口，按规范执行调用即可达成自动接入
开放平台原始资料采用Markdown格式，这类文本格式可以很容易被FastGpt切割并向量化存储，从切割文本发现FastGpt会根据Markdown的段落切分，这种切分方法质量非常高：
第三期，人工补进知识库：对于一些零碎、高价值的交付方案文档，我们持续整理并导入。同时，针对后台日志中高频未命中的提示词，我们将问题正确答案进行持续更新补齐。通过以上思路，智能问答知识库得以进一步完善。
# 2、智能体建设
知识库准备完毕后，就可以开始建设智能问答智能体，最简单的智能问答智能体只需要完成提示词编写、知识库应用和LLM大模型选择：
第一期，我们通过搭建“简易应用”进行智能问答的设计：设置好提示词、大模型、关联上一步的知识库即可使用。配置看似简单，实际提示词工程“玄之又玄”，为了让大模型理解并且正确执行我们的需求，需要编写清晰的执行条款，并不断修正。
在FastGPT官方技术支持下，我们完成了第一期的提示词建设：
你作为问题解决专家，需要严格遵循以下要求：
1.仔细分析用户的问题，明确其核心需求或问题现象。如果问题涉及具体现象或具体错误描述，要提取关键词或关键描述，优先从知识库中查找标题或问题现象匹配度较高的知识，没有则查找近似的知识，在对应知识中查找并输出问题分析和解决方案。
2.如果知识中有图片，必须获取完整的图片地址，包括图片地址中的参数，并且以图片的形式展示在回答中，不要返回图片的URL链接。
3.如果用户提问的是广泛且通用问题，必须优先从知识库中查找。如果知识库中无匹配内容，委婉告知用户“未找到相关解决方案”，并回答通用的解决方案。
4.你不能解析图片，不能要求用户提供截图。
5.知识库中的英文信息不需要翻译。
6.在回复中，如果有账号角色信息，最好明确为：谁可以通过什么样的操作，完成什么样的功能。
7.委婉拒绝用户的闲聊，不要回答知识库内容以外的问题。
格式:输出以可初化的标准格式输出，图表以markdown的格式输出出来
第二期，增加推荐链接：在运营过程中，我们发现向智能问答获得部署方案时，受限于大模型返回上下文长度，模型往往无法回复网站的部署手册内容。
此时，我们考虑一种RAG优化方案：提供相关性推荐！虽然RAG已经在最后提供了相关性答案，但那些答案都是片段。如果能在回答中直接返回手册的在线链接，那么对于提问者将带来巨大帮助！
要实现以上逻辑，我们需要做两件事：1、调用FastGPT接口写入知识库时，将开放平台手册的在线链接顺带写入；2、优化提示词输出结构，让模型给出推荐的链接。
同样，得益于开放平台在线化能力，所有手册、FAQ均有固定URL地址，我们只需要推送接口时带上平台的URL。
最后是完善提示词，在原始提示词基础上让大模型输出参考链接：
你作为问题解决专家，需要严格遵循以下要求：
1.仔细分析用户的问题，明确其核心需求或问题现象。如果问题涉及具体现象或具体错误描述，要提取关键词或关键描述，优先从知识库中查找标题或问题现象匹配度较高的知识，没有则查找近似的知识，在对应知识中查找并输出问题分析和解决方案。
2.如果知识中有图片，必须获取完整的图片地址，包括图片地址中的参数，并且以图片的形式展示在回答中，不要返回图片的URL链接。
3.如果用户提问的是广泛且通用问题，必须优先从知识库中查找。如果知识库中无匹配内容，委婉告知用户“未找到相关解决方案”，并回答通用的解决方案。
4.你不能解析图片，不能要求用户提供截图。
5.知识库中的英文信息不需要翻译。
6.在回复中，如果有账号角色信息，最好明确为：谁可以通过什么样的操作，完成什么样的功能。
7.委婉拒绝用户的闲聊，不要回答知识库内容以外的问题。
格式:输出以可初化的标准格式输出，图表以markdown的格式输出出来
你必须在输出时，如果知识库中有对应的参考链接，则输出引用知识库的链接，如果没有对应的参考链接，就不输出参考文档!!
例如：> 参考文档：[OA集群环境从节点无法启动](https://*.seeyoncloud.com/#/faq/faq/v1/share?url=*)
同时请最终输出时请校验输出的引用知识库文档的链接是否正确，是否为：(https://*.seeyoncloud.com/#/faq/faq/v1/share?url=*)
第三期，简易应用转工作流编排：简单的Agent只能依托详细的提示词引导大模型按照ReAct模式运转并最终给出解决方案。但如果多轮对话后，模型可能会出现失忆，导致输出结果大打折扣。此时我们需要拆解任务，逐步有序执行，利用FastGPT的Workflow工作流编排能力来建设智能问答，工作流编排能让下一步都承接上一步的上下文，确保记忆不会丢失，步步为营、环环相扣，最终输出效果得以保障。
# 3、开放用户访问
前期建设都是后台设计阶段，当问答智能应用建设完成后，我们需要将其开放给用户使用，我们同样可以通过小步快跑、快速迭代的形式来做应用的发布。
第一期，使用FastGPT原生WebUI灰度验证。FastGPT本身提供了免登录的UI页面，前期我们可以将页面地址直接发布出去，供项目上快速试用、试错。
第二期，开发带身份验证的自主式WebUI。无登录权限的地址无法统计使用情况，不做鉴权还易被外部爆破攻击。FastGPT本身也提供了调用指定智能应用的API，我们可以自己开发问答交互页面，同时独立管控鉴权逻辑，真正实现了前后端分离。本步骤的落地实现由公司信息中心技术团队完成。
开放平台首页智能搜索入口：
开放平台FAQ智能搜索按钮：
信息中心技术团队开发的移动端UI自适应页面：
第三期，CoMi集成FastGPT：CoMi是公司研发的智能平台，在经过半年多的沉淀，CoMi在公司系统内已经推广使用，我们同样可以在公司协同系统通过CoMi直接接入FastGPT的智能体。 具体接入方法在《CoMi如何集成第三方智能平台 (opens new window)》一文中已经有陈述。
# 获得效果
根据后台日志显示：
- 智能问答在2025年8月最后一周进行了2031次新对话（对话框下多轮提问只算1次对话）
- 2025年7月一个月进行了6169次新对话
- 2025年8月一个月进行了7254次新对话，使用量稳步攀升
根据后台分析，开放平台智能问答在标准产品交付部署等方面回复命中率能达到70%，通过自动自动推送解决方案，切切实实减少了人力支持成本。
# 挑战和对策
在建设智能问答应用时，我们面对了诸多挑战，需要根据现状分析并解决问题，以下问题在其它智能问答项目可能都会遇到，相关思路供参考：
问题一：知识库不足！ “RAG的重心是知识建设” 这句话并非空穴来风，没有充足、系统、准确无误的文档资料，只能让智能体回复质量大打折扣，这个需要一群主动总结、整理优化知识文档的人才能完成。 得益于开放平台完善的后台内容建设机制，研发和总部支持人员能持续、快速录入常见问题，让知识库持续增长。 知识整理是长期的过程！
问题二：知识库内容不准确！ 文档多固然重要，文档错漏百出会让智能体变成一个不受信任的平台。针对回复错漏不准确的问题，我们会定期查看对话日志，梳理问题列表，并做出改进。通过持续迭代优化，提升知识库的准确率。
问题三：检索质量问题！ 第一期RAG检索技术纯粹依赖向量数据库的语义检索能力，这种单一检索模式存在召回不足、缺乏歧义消解等问题。目前网上衍生了非常多的提高检索准确率的方案，其中多路召回（混合检索）是比较容易落地的方案：通过语义检索+全文检索（甚至工具检索）多路检索出相似性问题，再通过RRF或ReRank重排来进一步提升相关性检索质量。 我们也是在FastGPT技术支持下完成了检索质量的优化。
问题四：提示词优化问题！ 大模型极度依赖提示词进行任务分解：提示词过于简单会让大模型随意发挥，频繁幻觉；提示词过于复杂会让大模型在进行多轮任务执行后，因为上下文过长等问题，突然“失忆”，最终无法连贯完成最终的任务。针对提示词简单的问题，我们需要完善成清晰、明了的提示词，并且严格约束大模型的任务范围。 针对提示词任务执行过多问题，需要考虑从单一的智能体应用向Workflow工作流编排转型，通过编排来进行多步骤任务分解。
# 优化案例
# 案例一：消除重叠知识
我们通过后台日志分析发现几乎每天都有人问“协同https如何配置？”，然后智能体的回复多数情况下存在错误，并且伴随随机性！
正确答案应该是： 引导提问者通过Nginx配置HTTPS，在协同OA侧不做任何调整，参考文档应该是《Nginx配置协同HTTPS (opens new window)》。
实际回复情况是： 一会儿推荐Apache配置HTTPS这类过时的方案；一会儿提供在OA侧增加配置HTTPS的过时方案；一会儿甚至给的是分析云配置HTTPS的方案。
原因分析： RAG有个好处是，在提供方案时，智能体会顺带把参考文档显示出来。我们可以基于参考文档溯源分析，经过分析我们发现：在8.0、8.1、8.2等老版本的部署手册中都有HTTPS的相关配置说明（但已经过时），每一次相同提问，智能体似乎会随机从这些版本中取一个HTTPS的文本块做解答。我们评估：这是 知识内容之间存在高相似度 引起的，检索系统返回了多个版本的高度相似内容极易引起了 版本混淆 。
优化过程：
- 最初，我们是新增了一个FAQ知识库内容：
如何进行https配置？优先通过《Nginx配置协同HTTPS》这份文档给解决方案。 实测，结果好了一点点，但稍微换个问法（比如OA如何配置https？https配置V5？）又会出现推荐历史版本的问题。 - 随后，我们尝试在提示词中直接增加：
如询问协同配置https问题，优先通过《Nginx配置协同HTTPS》这份文档给解决方案。实测，有效果，但这种方案我们未采用，如果靠提示词去精调，会导致大量冗余规则，毫无通用性，后面很可能会导致大模型解析混乱。 - 最后，我们把所有历史版本的Nginx配置章节删除（已确认历史版本的https配置本身就是过时的）。实测，有明显改善。但从参考资料里面看，历史客户BUG和讨论知识库等还留存了传统的https配置方案，这种只需后续持续优化。
实际这类过度相似的案例还有很多，只要存在多个版本相似的手册，就极易产生相似性检索问题。开放平台智能问答知识库后续还针对相似性检索问题进行改进，按AI给的建议，可以考虑如下几个方向：
- 每份版本手册文档增加版本元数据：版本号、发版日期、适用范围
- 提示词增加通用要求：在没有明确指明版本的情况下，优先回复最新版本 10.0 的解决方案
- 使用ReRank重排模型，重排序能有效提升检索准确性，但涉及额外token支出
- 修正历史文档错误信息，文档质量非常重要
# 案例二：知识检索指代消解
通过后台发现有人提问“comi 1.1支持哪些oa版本”，然而智能体回复未找到相关知识！ 换一句话提问“comi 1.1支持哪些协同版本”，就能获得正确答案。
我们尝试向知识库直接写入一条FAQ：问题“comi 1.1支持哪些oa版本”，答案“xxx”，发现依然没有效果，问题可能出在向量库检索BUG上面。
为了解决这个问题，我们采用了类似大模型“指代消歧”的理论，即告诉向量库：关键字中“oa”也叫“协同”、“V5”。
具体实现方式采用了FastGPT检索中的“问题优化”能力，其实现原理为：在对用户提问进行相关性检索前，先让AI对提问进行美化完善（问题带oa关键字时，追加协同、V5关键字）。
这种方案确实能很大程度消除提示词不清晰等问题，但代价是解析时间更久（需要多一次模型请求），更消耗Token。
未使用问题优化场景：
[用户问题] →问题：comi 1.1支持哪些oa版本→ [向量库检索] → 未命中答案
----------------------------------
使用问题优化场景：
[用户问题] →问题：comi 1.1支持哪些oa版本→ [大模型问题优化] → 问题：comi 1.1支持哪些oa版本？comi 1.1支持哪些协同版本？comi 1.1支持哪些V5版本？ → [向量库检索] → 命中答案
# 项目总结
智能问答建设并非简单几天就能完成，需要多方持续优化才能有较好的效果。如项目上进行智能问答建设，我们有如下建议：
1、实施人员需要掌握AI智能应用基础理论，知其然知其所以然，才能知道什么问题如何切入。参考学习资料《AI技术基础概念赋能 (opens new window)》。
2、实施人员已经亲手搭建过智能相关的Agent，比如CoMi后台、FastGPT云服务、Dify云服务、Coze、阿里百炼平台的智能体应用等任意一款。
3、初期不要预期过高，前期能跑起来，能用就算初步成功，这个需要持续迭代。
4、大模型回复均是基于相关性概率统计，故幻觉不可避免。对于智能问答要求高精度的行业（如金融、医疗），一定要提醒客户：不建议使用AI做主推荐系统，最多能将其当作辅助参考。
5、知识文档建设是重中之重，建议用户提前准备，Word、PDF（非扫描件）、Markdown这类文本文件均可以被切割转换存储，文档质量由客户做好管控，质量差搜索结果肯定也差。
6、知识文档是持续调优的过程，不是一次完成就结项，需要定期从后台观察、分析问答日志，去寻找未命中的问题解决方案。我们经过了几个月的间歇性优化才让命中率有所提升。
7、多路召回（混合检索）能提升检索质量，但一般多路召回需要ReRank重排模型，这个是额外开支
8、如果使用公有模型，注意关注下模型的百万token费用，选择便宜又好用的模型
9、不要把智能问答当作“通才”，需要提醒客户将其设置成“专才”，一个Agent完成一个专业方向的问题，比如客开问答、运维问答、售前问答、实施问答分开维护，如果要一个入口也需要通过Workflow编排区分用户的问题，然后路由到对应智能体。
10、知识宁缺毋滥，过渡泛滥会导致AI无法找到最新最合适的知识
一个Agent进行“通才”设计的风险：知识库中涵盖售前、开发、运维、实施所有资料，会遇到“知识内容之间存在高相似度”的问题，误导模型选择了错误的答案！
# 团队组合
信息中心团队：提供FastGPT本地化部署维护、前端WebUI支持 交付总部：朝军完成FastGPT知识库接入、家莉完成智能体设计 研发、总部：提供开放平台海量知识库的建设
# 扩展-CoMi智能问答
CoMi经过这么久的迭代，截至2025年9月已经具备智能问答建设能力：提示词、知识库、多路召回、LLM/Embedding/ReRank模型接入均可配置。
- CoMi默认内置了开箱即用的“智能问答”应用，提示词等已经封装好，项目上可以导入知识文档，测试智能问答的效果。
- 同时CoMi即将推出协同知识问答应用，将协同文档中心的文件自动装载到CoMi向量知识库中，开箱即用，后续项目上只需要维护文档中心文件即可。
CoMi的优势是结合协同产品特性完成了智能应用的封装，可以较快速地让用户看到效果。不过根据开放平台智能问答建设经验，要让智能问答好用、易用、尽量准确是任重而道远的事，需要持续建设、分析、优化、试错、再优化的过程。
另外，经过实测，CoMi具备集成第三方智能平台的能力，相关方案可参考《CoMi如何集成第三方智能平台 (opens new window)》。
快速跳转
