基本信息

来源摘要/节选

公开展示已截断至最多 800 个字符；请访问原始来源查看完整上下文。

最近很多团队都在尝试把大模型接入到自己的业务里，但真正落地时会发现一个问题：直接和大模型聊天并不等于拥有一个可用的业务助手。 比如我们想让 AI 回答公司产品文档、接口说明、运维手册、售后 FAQ 里的问题，如果只是直接问通用大模型，它很可能并不知道这些内部资料。即使模型能回答，也可能出现信息过期、回答不稳定、甚至凭空补充内容的情况。 这类场景更适合用 RAG 知识库问答来解决：先把自己的文档上传到知识库，用户提问时先从知识库中检索相关内容，再把检索结果交给大模型生成回答。这样模型回答时就有了明确的上下文依据。 本文我会用 Dify 的「知识库 + 聊天机器人」模板，接入蓝耘 MaaS 模型服务，并在 LLM 节点中选择 GLM-5.1 作为知识库问答模型，从 0 搭建一个可以基于文档回答问题的企业知识库助手。 @[toc] 一、为什么选择蓝耘 MaaS + Dify 在这个方案里，Dify 和蓝耘 MaaS 承担的角色并不一样。 Dify 更像是 AI 应用搭建平台。它负责应用创建、知识库管理、工作流编排、节点调试、Prompt 配置和最终对话界面。通过 Dify，我们可以不用从零写后端，就完成一个知识库问答应用的基本链路。 蓝耘 MaaS 则提供大模型调用能力。在知识库问答流程中，模型主要负责理解用户问题、结合检索到的文档内容组织答案，并把结果返回给用户。 两者结合以后，整体链路可以理解为： 用户提问 -> Dify 接收问题 -> 知识库检索相关文档 -> 蓝耘 MaaS 模型生成回答 -> Dify 返回答案 这套组合的优势是比较清晰的： 不需要从零开发完整的 RAG 后端。 Dify 可以可视化管理知识库和工作流。 蓝耘 MaaS 可以作为大模型底座接入到应用链路中。 适合快速验证企业文档助手、产品 FAQ 助手、智能客服、内部运维助手等场景。…

来源说明

当前只保存了公开页面节选，不代表原文全文。请以原始来源为准。

本页只呈现已做哈希绑定的来源证据，不包含基于旧正文或缺失原文的扩展推断。