# 开放平台智能问答（CoMi一搜）建设方案
# 项目背景
open.seeyoncloud.com是致远互联推出的开放平台，主要面向全区域同事、开发者、技术运维、合作伙伴和第三方，提供技术/运维资料支持，以及常见问题解决方案，是交付侧最重要的一个知识分享平台。
开放平台提供了丰富的技术资料，也提供了FAQ全文检索能力供大家查找资料，但传统的检索方法在NLP自然语言处理上面表现并不好，以至于同一个问题不同表达就导致匹配不到正确答案。随着ChatGpt、DeepSeek的爆火，我们发现大模型在NLP方面表现很好，基于大模型的智能检索已经成为各企业优先落地的项目。
2025年初，为了提升开放平台检索准确率，我们拟定基于大模型的最佳实践构建自己的智能问答应用！内部代号：CoMi一搜。
# 立项和选型
# 现状分析
在立项前，我们进行了现状分析：
目前市面的大模型在NLP自然语言处理能力上表现都不错，相同问题不同表达也能被模型敏锐识别成一个问题。
但大模型存在一个严重局限性：无法回答企业私域问题！在询问“A8N 9.0信创部署手册在哪里？”这类问题时，大模型并没有对我们的知识进行训练，以至于最终答非所问。
为了解决大模型无法回复私域问题，市面已有解决方案---可以通过微调或RAG方案来处理：
- 模型微调（Fine-Tuning）是指在预训练的大语言模型（如DeepSeek、Qwen等）基础上，使用特定领域数据（如开放平台知识库）进行二次训练，使模型掌握开放平台的知识。这种方案需要不少的成本，并且知识更新时需要再次微调训练，不适合知识问答快速落地。
- RAG检索增强生成 ，采用外挂知识库，在进行query前先从外挂知识库提取相似性答案，随提示词推送给大模型，以便让大模型的回复准确。这种方案不对模型进行任何训练，所需成本较低，只要准备好知识就能快速落地，知识更新也非常容易。
鉴于RAG外挂知识库方案实施更新成本低、落地快、知识更新灵活、答案可追溯可审计、试错门槛低等特点。我们拟定使用RAG+智能体的方案进行开放平台智能问答应用落地！
× [用户] → [大模型]
√ [用户] → [RAG智能体Agent] → [大模型]
# 系统选型
如按行业主流架构实现RAG，需要进行代码开发，以及结合Embedding Model、向量数据库等一系列组件才能实现，开发周期长，所需开发资源高。如需快速完成智能问答应用，选择开箱即用的RAG智能体应用是最快实现路径！
在选型之初，国内比较主流的智能体应用有FastGPT、Dify、Coze等，各有特色：
- Coze：适合快速搭建聊天机器人，无需/少量需要编程，适合 C 端用户或轻量级企业应用。
- Dify：适合开发者构建复杂 AI 应用，支持多模型切换和私有化部署。
- FastGPT：适合企业知识库管理，需高效问答系统，且IT团队具备本地化运维能力。
回归选型本质，我们需要建设智能问答应用，其中FastGPT (opens new window)在知识库的存储和检索技术方面都表现突出，故最终选择此平台。
公司信息中心正在统建AI智能平台，部署形态为FastGPT本地化商业版。FastGPT提供了本地部署社区版、本地部署商业版和在线Saas版本，为了知识库数据安全，肯定采用本地化部署，并且商业版功能全面，有官方技术支持，是不错的选择。我们只需向信息中心申请独立账号维护我们的智能体即可。
注：为什么没有选择公司的CoMi作为智能问答的平台？在2025年初还没有CoMi智能体平台。
# 从0到1原型定版
为了快速获得效果，项目组计划先做出第一版原型效果，
# 1、学习和理解RAG原理
为了完成RAG智能检索应用落地，一定要理解什么是RAG，其运行原理，才能做好智能应用。RAG的落地实现，需要完成两个步骤：
- 步骤一，知识存储：准备好资料文档，通过Agent将文档进行拆分，拆分后的文档通过Embedding模型转换为多维向量，将数据存储到向量数据库
- 步骤二，知识检索：创建检索Agent，用户提问时，将用户问题向量化并从步骤一的知识库检索出语义相关的知识，最后交由大模型进行汇总分析，给出结果
# 2、原型知识库建设
建设知识库对于开放平台非常容易，开放平台自2022年改版以来建设维护了几千份技术资料：开发组件类手册、安装部署类手册一应俱全，交付过程中遇到的小问题和解决方案均有录入开放平台FAQ库中。FastGPT应用程序完成了文档的切割、文本向量化和向量数据存储，只需要选择合适的Embedding模型，即可开箱即用。
第一期，我们将开放平台资料导出为文本文件，并导入FastGpt知识库，由FastGpt自动进行向量化存储。
# 3、检索智能体建设
知识库准备完毕后，就可以开始建设智能问答智能体，最简单的智能问答智能体只需要完成提示词编写、知识库应用和LLM大模型选择：
第一期，我们通过搭建“简易应用”进行智能问答的设计：设置好提示词、大模型、关联上一步的知识库即可使用。配置看似简单，实际提示词工程“玄之又玄”，为了让大模型理解并且正确执行我们的需求，需要编写清晰的执行条款，并不断修正。
在FastGPT官方技术支持下，我们完成了第一期的提示词建设：
你作为问题解决专家，需要严格遵循以下要求：
1.仔细分析用户的问题，明确其核心需求或问题现象。如果问题涉及具体现象或具体错误描述，要提取关键词或关键描述，优先从知识库中查找标题或问题现象匹配度较高的知识，没有则查找近似的知识，在对应知识中查找并输出问题分析和解决方案。
2.如果知识中有图片，必须获取完整的图片地址，包括图片地址中的参数，并且以图片的形式展示在回答中，不要返回图片的URL链接。
3.如果用户提问的是广泛且通用问题，必须优先从知识库中查找。如果知识库中无匹配内容，委婉告知用户“未找到相关解决方案”，并回答通用的解决方案。
4.你不能解析图片，不能要求用户提供截图。
5.知识库中的英文信息不需要翻译。
6.在回复中，如果有账号角色信息，最好明确为：谁可以通过什么样的操作，完成什么样的功能。
7.委婉拒绝用户的闲聊，不要回答知识库内容以外的问题。
格式:输出以可初化的标准格式输出，图表以markdown的格式输出出来
# 4、原型应用发布上线
前期建设都是后台设计阶段，当问答智能应用建设完成后，我们需要将其开放给用户使用，我们同样可以通过小步快跑、快速迭代的形式来做应用的发布。
第一期，使用FastGPT原生WebUI灰度验证。FastGPT本身提供了免登录的UI页面，前期我们可以将页面地址直接发布出去，供项目上快速试用、试错。
# 5、原型定版总结
第一期主要以展现基本能力为主，先将骨架搭建完成，然后进行灰度用户验证，不断迭代修正智能问答Agent能力。
# 正式上线后迭代优化
完成从0到1原型验证后，智能问答投放到生产环境，随后就是长达近一年的迭代优化，我们从各个层面进行了智能问答的完善，具体修改经验如下。
# 1、知识库迭代优化
第一期-人工导入文档：我们只是完成了知识库的手动导入。
实际开放平台的文档每天都在新增、修改、删除，如果通过人工（从开放平台）导出再导入（FastGPT知识库），时效性低，并且无法分辨哪些文档做过增删改，每次都是全量替换，对FastGPT平台知识的训练压力非常大，并且会耗费很多Embedding模型tokens费用。
FastGpt提供了知识库创建（/api/core/dataset/create）、删除等Rest接口，按规范执行调用即可达成自动接入。
第二期-接口自动化更新： 我们完成了代码开发接入FastGpt知识库，开放平台侧任何增删改查资料都会通过接口的形式同步更新FastGpt，这样就彻底实现了知识的自动化更新。
开放平台原始资料采用Markdown格式，这类文本格式可以很容易被FastGpt切割并向量化存储，从切割文本发现FastGpt会根据Markdown的段落切分，这种切分方法质量非常高：
第三期-人工补充知识库： 对于一些零碎、高价值的交付方案文档，我们持续整理并导入。同时，针对后台日志中高频未命中的提示词，我们将问题正确答案进行持续更新补齐。通过以上思路，智能问答知识库得以进一步完善。
第四期-删除冗余知识： 由于我们的产品是按版本迭代发布，每个版本都会留存一份部署手册，随着产品的发展，新版本某些特性改动很大。由于语义检索不具备区分新、旧知识的能力，会导致有时候给出的解决方案是过时的方案。
以协同OA配置HTTPS为例，早期版本是基于Apache + SeeyonConfig + server.xml配置HTTPS，而V8.1版本之后，主流方案变成了Nginx+SSL的形式配置HTTPS。我们分析发现：老版本的部署手册中都有HTTPS的相关配置说明（但已经过时），每一次相同提问，智能体似乎会随机从这些版本中取一个HTTPS的文本块做解答。这是 知识内容之间存在高相似度 引起的，检索系统返回了多个版本的高度相似内容极易引起了 版本混淆 。
经过多轮验证，最终我们采用的方案是：把所有历史版本相似的文本删除（如上面的Nginx配置章节）。实测，有明显改善。但从参考资料里面看，历史客户BUG和讨论知识库等还留存了传统的https配置方案，这种只需后续持续优化。
第五期-文档增加版本标识： 接上一期删除冗余知识的问题，实际这类过度相似的案例还有很多，只要存在多个版本相似的手册，就极易产生相似性检索问题。开放平台智能问答知识库后续还针对相似性检索问题进行改进，按AI给的建议，可以考虑如下几个方向：
- 每份版本手册文档增加版本元数据：版本号、发版日期、适用范围
- 提示词增加通用要求：在没有明确指明版本的情况下，优先回复最新版本 （如协同V10.0） 的解决方案
- 使用ReRank重排模型，重排序能有效提升检索准确性，但涉及额外token支出
- 修正历史文档错误信息，文档质量非常重要
第六期-增加在线链接： 开放平台存放了很多长篇幅的部署手册，而用户在询问xx如何部署的时候，受限于大模型输出上下文限制，无法输出完整的方案，如何引导用户直接访问开放平台指定文档成为关键技术难点。
经过研究，我们发现只需要通过API接口向FastGPT知识库推送文档时，在标题中增加开放平台对应文档的在线链接，知识库会给每个chunk分块都带上标题和链接。随后我们只需要在搜索Agent的系统提示词中增加一句“如果知识库中有在线链接，则必须输出参考链接地址。”，大模型大多数情况就会在回复区域贴上手册的在线链接。
第七期-知识分类存储： 我们发现随着开放平台文档越来越多，FastGPT存放开放平台的知识库也越来越臃肿，语义检索效率开始降低（有时候要10秒），对知识的分类存储迫在眉睫。目前我们将知识拆分成客开开发、产品问题、运维环境三个分类，在开放平台后台每份文档标注当前文档归属那一个（或多个）分类，程序再根据对应分类推送至对应数据库。
AI智能体我们也进行了拆分：由原来一个大而全的“万能”智能体，拆分成开发、产品、运维三个智能体。
智能体由1拆分为N是一把双刃剑：
- 不拆分会让智能体越来越臃肿，由于分不清是开发问题还是产品本身问题导致回复错误，并且Agent检索效率会越来越慢
- 拆分则会存在文档重新标注的工作量：什么文档归属什么分类是一个大工程，并且回复准确率还需要持续调优，拆分之初智能体肯定没有大而全的Agent强
基于以上，建议在立项之初就对文档按（客户的业务）类型进行标注以及分类存放，以便后续按分类创建Agent。
知识库其它优化经验： 关于知识库的维护还有很多小经验可供参考：
- 1）要将企业的知识问答做好、做深，需要投入很大的功夫，搜索Agent搭建2周完成，而知识库维护要断断续续投入半年甚至持续迭代！
- 2）知识库采用Markdown存储，MD是非常友好的文本格式，很多模型默认也是以MD格式输出
- 3）图片预览问题：为了确保全网用户能查看到知识库中的图片，我们是将图片存放在OBS对象存储公共服务中，开放平台智能问答可以回复图片信息，友好性很高
- 4）尽量不做人工导入知识库工作（PDF这类版式文件除外），为了确保数据可追溯、可维护性，我们都是通过开放平台增删改数据，再启动同步到FastGPT知识库，以达成一致性
- 5）关于知识不全的问题：如果企业内没有提前准备系统、清晰、规范的知识文档，那么Agent回复一定是不准确的，这种只能投入企业内专职人员编撰、维护，并且需要时间沉淀。比如我们的V8产品线，迭代很快，缺乏完整的沉淀，就需要持续投入一边解决问题、一边总结到开放平台。
# 2、智能体迭代优化
第一期-采用自规划简易应用Agent： 通过构建简易应用智能体，Agent的职责、执行顺序、执行规范全部都在系统提示词中维护，这种方法易于快速上线。但天生会带来模型交互次数增多的问题，如果进行带记忆的多轮对话甚至会导致上下文丢失，而忘记进行检索的问题。如下运行图，Agent必须依赖模型的意图识别来判别是否检索知识库，这个直接让模型交互次数增多，并且效率下降：
用户提问 → Agent[意图识别] → 大模型[意图识别] → Agent[语义检索] → 大模型[分析结果] → 输出答案
第二期-简易应用转工作流编排： 介于第一期简易应用Agent的问题，我们进行了Agent的改造：转型为工作流编排，无论什么问题进来就先进行语义检索，随后再将内容推送大模型分析,最终输出效果得以保障。基于工作流编排，搜索Agent的业务流转变成了如下运行图（少了第一期意图识别动作）：
用户提问 → Agent[语义检索] → 大模型[分析结果] → 输出答案
第三期-系统提示词优化： 为了让模型按照我们的要求输出，还需要定期检查并优化工作流中的系统提示词。
比如，知识库中的图片是公有云的OBS地址，那么完全可以让模型直接输出图片：
比如，拒绝闲聊、拒绝进行长文本方案输出，让模型专注于做智能问答：
比如，为了让模型能输出知识库中的参考链接，我们需要在系统提示词中增加相关说明：
比如，部分人拿智能搜索来做考试题，我们需要添加对应系统提示词来做限制：
可以说：系统提示词就是Agent的编程语言，需要设计师通过清晰、明确的自然语言命令来规范模型的行为，才能保证模型按预期效果输出！
第四期-使用混合检索： 传统的向量知识库检索方式为语义检索，利用向量数据库本身的余弦相似度等算法来捕获与问题语义相似的知识，这种方式可以将相似概念（如 “安装” 与 “部署”）给召回，确实是目前行业最推荐的方法。 基于这种基础模式，网上出现了语义检索+全文检索多路召回的概念：即语义检索和全文检索并行执行，最后通过RRF算法或ReRank进行重排序。
混合检索这种模式下，全文检索提供了精准匹配的能力，让更加匹配的文档排在前面，避免了语义检索只关注语义不关注关键词匹配的问题，最终实现 “既懂用户，又找得准、找得全、跑得稳” 的检索效果。
注意：重排序不仅可以使用FastGPT自带的RRF算法，还可以使用ReRanker模型重排序能力，理论召回排序会更精准。但我们内部测试不知道使用的ReRank模型过旧还是什么原因，开启ReRank后排序反而更差了，这种情况需要项目上根据实际召回率来做选型。
第五期-增加问题优化模型： 虽然语义检索能让知识库检索出与词语相近的数据（如问“部署手册”可以检索出“安装手册”），这个是因为Embedding模型知道“部署”和“安装”具有相似性。但模型不是万能的，模型在面对企业内部的专业术语时无法分辨出相似性：
- 模型并不清楚企业内的专业术语相似性，比如：
协同等于OA等于V5，我们需要让模型清楚这几个词的关系 - 模型也不知道企业的版本信息，用户问问题时不提及版本号，一般都特指最新版本，我们需要让模型知道用户问的最新版本号是多少才能更精准去匹配
此时，我们可以利用“问题优化”功能，专业术语叫“指代消解”。即让AI根据用户的问题再结合企业内部的专业术语规范去补全问题缺失的信息。比如告诉AI “问题中的“协同”、“V5”、“OA”、“oa”都是一个意思” ，以及 问OA就默认追加最新V10.0SP1版本，配置如下：
最终我们调试Agent会发现：当用户询问“CoMi支持集成OA哪些版本”时，通过AI的问题优化就能优化成几句话“集成协同OA哪些版本”、“集成协同OA的版本要求是什么”，通过这种形式去覆盖语义检索范围，实测效果非常好：
第六期-一个智能体拆分成N个： 按照单一职责Agent设计原则，Agent可以按领域职责解耦、模块化协作，我们目前将一个交付智能体拆分成了开发、产品、运维三个智能体。短期内观察，这种拆分会导致Agent没有原来那么聪明，还需要一定时间做优化和适应。从长期看，这样的拆分能让智能体回复问题更聚焦。
检索Agent其它优化经验： 关于Agent的维护还有一些小经验可供参考：
- 1）选择合适的基座大模型：问答是要消耗模型Tokens的，这个都是成本，推荐选择公有云Tokens价格便宜旗舰模型，我们目前一直跟着DeepSeek（非思考模式）最新版本走，效果还不错
- 2）企业专属智能问答尽量不要用AI问题分类：你希望AI根据用户问题自动分类走开发、产品还是运维Agent，这种不现实，AI不知道企业的专业术语。比如提问“如何检查达梦数据库驱动jar与当前达梦数据库版本相匹配?”，这本身是一个运维环境类问题，但AI会认为带“驱动”都属于开发，最后将其错误引导到开发Agent里。
- 3）要定期查看后台的“对话日志”，看一下用户是怎么问问题的，并且评估AI回复准确率，如不准确就需要定期优化
- 4）活用后台的调试功能，智能体后台可以直接提问调试Agent运行过程，通过“查看详情”可以知道当前对话的每一步运行过程，以及输入输出，以此来评估问题出在什么环节
# 3、用户访问UI优化
前期建设都是后台设计阶段，当问答智能应用建设完成后，我们需要将其开放给用户使用，我们同样可以通过小步快跑、快速迭代的形式来做应用的发布。
第一期，使用FastGPT原生WebUI灰度验证。FastGPT本身提供了免登录的UI页面，前期我们可以将页面地址直接发布出去，供项目上快速试用、试错。
第二期，开发带身份验证的自主式WebUI。无登录权限的地址无法统计使用情况，不做鉴权还易被外部爆破攻击。FastGPT本身也提供了调用指定智能应用的API，我们可以自己开发问答交互页面，同时独立管控鉴权逻辑，真正实现了前后端分离。本步骤的落地实现由公司信息中心技术团队完成。
开放平台首页智能搜索入口：
开放平台FAQ智能搜索按钮：
信息中心技术团队开发的移动端UI自适应页面：
第三期，CoMi集成FastGPT：CoMi是公司研发的智能平台，在经过半年多的沉淀，CoMi在公司系统内已经推广使用，我们同样可以在公司协同系统通过CoMi直接接入FastGPT的智能体。 具体接入方法在《CoMi如何集成第三方智能平台 (opens new window)》一文中已经有陈述。
# 获得效果
根据后台日志显示，开放平台智能问答自上线以来用户使用量飞速攀升，用户反馈良好：
- 截止2025年6月18日，开放平台的AI知识库有 5194 条对话记录
- 截止2025年10月9日，开放平台的AI知识库有 27957 条对话记录
- 截止2025年12月17日，开放平台的AI知识库有 50391 条对话记录
根据后台分析，开放平台智能问答在标准产品交付部署等方面回复命中率能达到70%，通过自动自动推送解决方案，切切实实减少了人力支持成本。
# 项目总结
智能问答建设并非简单几天就能完成，需要多方持续优化才能有较好的效果。如项目上进行智能问答建设，我们有如下建议：
1、实施人员需要掌握AI智能应用基础理论，知其然知其所以然，才能知道什么问题如何切入。参考学习资料《AI技术基础概念赋能 (opens new window)》。
2、实施人员已经亲手搭建过智能相关的Agent，比如CoMi后台、FastGPT云服务、Dify云服务、Coze、阿里百炼平台的智能体应用等任意一款。
3、初期不要预期过高，前期能跑起来，能用就算初步成功，这个需要持续迭代。
4、大模型回复均是基于相关性概率统计，故幻觉不可避免。对于智能问答要求高精度的行业（如金融、医疗），一定要提醒客户：不建议使用AI做主推荐系统，最多能将其当作辅助参考。
5、知识文档建设是重中之重，建议用户提前准备，Word、PDF（非扫描件）、Markdown这类文本文件均可以被切割转换存储，文档质量由客户做好管控，质量差搜索结果肯定也差。
6、知识文档是持续调优的过程，不是一次完成就结项，需要定期从后台观察、分析问答日志，去寻找未命中的问题解决方案。我们经过了几个月的间歇性优化才让命中率有所提升。
7、多路召回（混合检索）能提升检索质量
8、如果使用公有模型，注意关注下模型的百万token费用，选择便宜又好用的模型
9、不要把智能问答当作“通才”，需要提醒客户将其设置成“专才”，一个Agent完成一个专业方向的问题，比如客开问答、运维问答、售前问答、实施问答分开维护，如果要一个入口也需要通过Workflow编排区分用户的问题，然后路由到对应智能体。
10、知识宁缺毋滥，过渡泛滥会导致AI无法找到最新最合适的知识
一个Agent进行“通才”设计的风险：知识库中涵盖售前、开发、运维、实施所有资料，会遇到“知识内容之间存在高相似度”的问题，误导模型选择了错误的答案！
# 团队组合
协同云团队：提供FastGPT本地化部署维护、前端WebUI支持
交付总部：朝军完成FastGPT知识库接入、家莉完成智能体设计
研发、总部：提供开放平台海量知识库的建设
快速跳转
