FastGPT 是一个基于大语言模型（LLM，即 Large Language Model，指 GPT、ChatGLM 等通过海量文本训练出的对话式 AI 模型）的开源知识库问答平台，把“上传文档 → 向量化入库 → 检索召回 → 生成回答”这一整套 RAG（检索增强生成，Retrieval-Augmented Generation，让模型先从知识库检索相关内容再生成回答的技术路线）流程做成了可视化编排界面。它解决的核心问题是：通用大模型不懂企业私有知识，而自己从零搭建 RAG 管道需要同时处理文档解析、向量化、检索策略、提示词工程、应用发布等多层技术栈，工程量大且难维护。FastGPT 将上述环节封装为可拖拽的工作流节点，配合内置的向量数据库和多模型接入层，让团队能在数小时内上线一个带引用溯源的知识库问答应用。本篇教程按“速览 → 安装 → 上手 → 核心能力 → 生产部署”的顺序展开，覆盖从单机部署到生产配置的完整路径，并在文末给出同类工具对比、常见误区与面试题，帮助读者快速建立可落地的操作认知。
对 AI 从业者而言，掌握 FastGPT 意味着能以最低工程成本交付知识库问答类项目，同时理解可视化 RAG 工作流的编排思想，这在企业数字化场景中是高频刚需技能。
目录
速览卡是工具类内容的固定首屏模块：30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 FastGPT：自建 RAG 管道太重，可视化编排是解药
传统知识库问答的搭建方式有两种：一是直接调用大模型 API 做“裸问答”，模型只能凭训练记忆回答，企业文档、产品手册等私有知识完全无法覆盖，回答错误率极高；二是基于 LangChain 等框架自建 RAG 管道，开发者需要自己处理文档解析（PDF/Word/Markdown 多种格式）、文本切片策略、Embedding（把文本转换成向量，即数字数组，让计算机能计算文本之间的相似度）模型选型、向量数据库部署、检索与重排、提示词模板、多轮对话记忆等一系列问题。这些环节每个都有独立的技术选型和调参空间，一个生产级管道从零搭建往往需要数周时间，且后续维护成本集中在代码层面，业务人员无法参与调整。
FastGPT 把上述流程拆解成“知识库管理”和“工作流编排”两个核心模块。知识库侧，它内置了文档解析与向量化入库流程，支持 PDF、Word、Excel、Markdown、网页链接等常见格式，切片和索引策略通过界面配置即可完成。工作流侧，它提供可视化的节点拖拽画布，每个节点对应一个功能单元（用户输入、知识库检索、AI 对话、问题分类、条件判断等），节点之间连线即形成完整的问答链路。这样做的直接收益是：搭建一个带知识库引用溯源、多轮对话、多模型切换的问答机器人，从“写代码”变成了“画流程图”。
相比 Dify 这类通用 LLM 应用平台，FastGPT 的差异化在于知识库问答场景的纵深打磨，例如细粒度的引用溯源（每条回答标注来源文档与段落）、多种检索模式（语义检索、全文检索、混合检索）的直观切换、以及对中文文档解析的针对性优化。相比 LangChain 的纯代码方案，FastGPT 牺牲了一定的灵活性，换来了交付速度和可维护性。
安装与环境配置：3 步就绪
步骤一·安装 Docker 环境。 FastGPT 的官方推荐部署方式是 Docker Compose。如果服务器尚未安装 Docker，需要先完成 Docker 与 Docker Compose 插件的安装，建议使用 Ubuntu 22.04 或 Debian 12 等主流 Linux 发行版，内存不低于 4GB（生产环境建议 8GB 以上）。
步骤二·下载部署文件并配置环境变量。 FastGPT 官方仓库的 deploy/fastgpt 目录下提供了完整的 docker-compose.yml 和 config.json 模板。克隆仓库后将这两个文件复制到服务器的独立部署目录，按需修改 config.json 中的模型配置（如 OpenAI 接口地址、API Key、模型名称列表）和 docker-compose.yml 中的端口映射。
步骤三·启动并验证。 执行 docker compose up -d 启动全部容器（包括 FastGPT 主服务、MongoDB、PostgreSQL（用于存储知识和应用数据）、Sandbox 服务（用于执行工作流中的代码节点））。首次启动需等待 1-3 分钟完成初始化。启动完成后通过浏览器访问 http://服务器IP:3000，使用默认管理员账号 root 登录，进入控制台即部署成功。
# 安装 Docker（Ubuntu/Debian 示例）curl -fsSL https://get.docker.com | bashsudo systemctl enable --now docker # 克隆 FastGPT 仓库并进入部署目录git clone https://github.com/labring/FastGPT.gitcd FastGPT/deploy/fastgpt # 按需编辑 config.json（配置模型 API 地址与密钥）和 docker-compose.yml（端口/存储路径） # 启动全部服务docker compose up -d # 查看服务状态docker compose ps # 查看日志（排查启动问题）docker compose logs -f fastgpt
快速上手：10 分钟跑通第一个知识库问答
最小可用流程的思路是：先建一个知识库并上传文档，系统会自动完成切片和向量化；然后创建应用关联该知识库，即可在对话窗口提问并验证检索效果。整个过程不涉及一行代码，核心操作分为三个步骤。
步骤一·创建知识库并导入文档。 登录 FastGPT 控制台后，进入“知识库”页面，点击“新建知识库”，选择索引模型（如 text-embedding-ada-002 或 FastGPT 内置的 m3e 模型，用于将文本向量化）。创建完成后进入知识库详情页，点击“导入”，支持上传单个或多个文件（PDF、Word、Markdown、TXT 等），或输入网页链接。系统会自动完成文本提取和切片，导入完成后可在“数据”标签页查看切片数量与内容，切片是检索的最小单位，可通过“分段设置”调整切片长度与重叠。
步骤二·创建应用并关联知识库。 回到“应用”页面，点击“新建应用”，选择“简易模板”（FastGPT 会生成一个包含用户输入、知识库检索、AI 对话三个节点的基础工作流）。在应用编辑页中点击“知识库检索”节点，将刚创建的知识库加入关联列表，可设置检索条数（Top K，即返回给模型的相关片段数量）和相似度阈值。保存后应用即构建完成。
步骤三·测试对话并验证引用溯源。 点击应用编辑页右上角的“预览”或“对话测试”，输入一个与文档内容相关的问题。如果文档已正确入库，AI 回答下方会展示引用来源的文档片段，点击片段可查看原文位置。若回答质量不佳，优先调整切片方式和检索阈值，而不是修改提示词。进阶技巧：在 AI 对话节点中自定义提示词模板，要求模型“仅基于引用内容回答，若引用内容不含答案则明确说明不知道”，可显著降低幻觉（模型编造不存在的信息）概率。
核心能力详解：4 大支柱
支柱一·知识库全生命周期管理。 FastGPT 的知识库模块覆盖从导入、切片、向量化到后续更新的完整链路。支持多格式文档解析，包括 PDF 的文字层与扫描版 OCR（光学字符识别，将图片中的文字转为可编辑文本）、Word、Excel、Markdown、CSV 及网页链接。向量化完成后，运维人员可随时查看、编辑或删除任意切片，并支持一键触发全库重新向量化（当更换 Embedding 模型、Embedding 指将文本映射为向量的模型时）。针对企业场景，还提供“多库多集合”结构，一个知识库可包含多个集合，不同集合可有独立的切片策略，便于隔离不同来源的数据。
支柱二·可视化工作流编排。 FastGPT 的工作流画布是核心生产力工具。节点类型包括：用户输入、AI 对话、知识库检索、问题分类、内容提取、条件判断、代码执行、HTTP 请求、文本拼接等 20 余种。节点通过连线传递变量，前面的节点输出可作为后续节点的输入。以常见的企业客服问答场景为例，流程为：用户输入 → 问题分类（判断是售前咨询还是售后问题）→ 分别路由到不同知识库检索 → 拼接上下文 → AI 对话 → 输出回答。整个流程可在半小时内拖拽完成，且每次修改后可通过“预览”实时调试变量传递是否正确。
支柱三·多模型接入与自动路由。 FastGPT 不绑定单一模型供应商，支持 OpenAI、Azure OpenAI、国产大模型（如通义千问、文心一言、智谱 GLM、DeepSeek）、以及本地部署的 Ollama 等。在 config.json 或管理后台中配置模型后，运行中的工作流节点可按需选择不同模型，例如用轻量模型做问题分类、用强模型做最终回答，形成成本与质量的平衡。部分版本还支持“模型自动路由”功能，可按可用性将请求自动切换至备用模型，减少单点故障。需要注意，不同版本的模型接入方式有差异，4.6 及以上版本统一在后台“模型设置”中管理。
支柱四·引用溯源与对话管理。 面向企业真实使用场景，FastGPT 在每次 AI 回答中自动携带引用来源片段，回答框中可展开查看“引用了哪些文档、命中了哪些段落”，这为内容可信度提供了基础保障。对话管理侧，支持多轮上下文传入、对话历史持久化（存于 MongoDB）、以及通过 API 对外提供问答接口供业务系统集成。管理员还可以查看单次对话的完整日志与 token 消耗，用于成本核算与效果分析。
生产部署与监控：从上线到运维
部署方式一·单机 Docker Compose（中低流量）。 生产环境建议将 docker-compose.yml 中的 MongoDB、PostgreSQL 数据目录映射到宿主机独立磁盘，定期备份这两个数据库目录。配置 HTTPS 反向代理（如 Nginx 或 Caddy），并启用 WebSocket 支持，因为 FastGPT 对话接口采用 WebSocket 长连接。单机模式下需要给 Docker 配置资源限制（如 mem_limit），防止模型请求并发时内存溢出。
部署方式二·Kubernetes 集群（高可用）。 官方提供 Helm Chart（Kubernetes 的打包部署方式），支持多副本横向扩展。FastGPT 主服务为无状态服务，可水平扩容；有状态组件为 MongoDB、PostgreSQL 和向量数据库（生产建议单独托管，如使用云厂商的 MongoDB Atlas 或自建副本集）。扩容的核心瓶颈在向量检索层，需根据并发量预估 MongoDB 的 IOPS 与内存。注意 config.json 配置需要挂载为 ConfigMap，升级时避免覆盖。
可观测性。 FastGPT 的运维可观测性依赖基础设施层：服务日志输出到 stdout，接入 Loki 或 ELK 即可收集；“对话日志”持久化在 MongoDB 中，可通过管理后台的日志页面按应用、按用户维度检索对话记录与 token 消耗；模型 API 的错误率与延迟可从模型供应商侧监控，若使用 OpenAI 等云服务，建议在供应商控制台配置用量告警。自建场景下，可在 Nginx 层记录接口响应时间与状态码，用 Prometheus + Grafana 做基础监控。
<p class="para-label">避坑清单：</p>
<ul class=“dash-list“><li>坑 1：生产环境禁用默认账号与默认端口。FastGPT 初始管理员账号为 root/123456，部署后必须立即在”账号设置”中修改密码；3000 端口不要直接暴露公网，务必套 HTTPS 反向代理，否则存在未授权访问风险。</li><li>坑 2：升级前不备份数据库，轻则丢数据、重则无法回滚。FastGPT 版本间数据库结构可能变化，升级前必须备份 MongoDB 与 PostgreSQL 数据目录，并阅读官方升级文档确认是否需要执行数据迁移脚本。</li><li>坑 3：Embedding 模型不可随意更换。已入库的向量是用旧模型生成的，切换模型后旧向量失去可比性，必须重新向量化全部知识库数据，否则检索结果会严重失真。</li><li>坑 4：知识库问答效果差先查切片，不要急着调提示词。文档内容被切碎或切片过长是检索不准的首要原因，先用界面调试功能观察命中片段是否合理，再决定调整分段设置。</li><li>坑 5：高并发下 Mongo 成为瓶颈。向量检索在 Mongo 中执行，单机 Mongo 在数千级并发下表现不佳，生产规模应用应尽早将 Mongo 迁移至副本集或云托管实例。</li></ul>
| 维度 | FastGPT | Dify | RagFlow | LangChain + 自建管道 |
|---|---|---|---|---|
| 定位 | 知识库问答深度优化的 RAG 平台 | 通用 LLM 应用开发平台 | 深度文档理解的 RAG 引擎 | 通用 LLM 应用开发框架 |
| 编排范式 | 可视化工作流拖拽 | 可视化工作流拖拽 | 可视化配置（流程相对固定） | 纯代码编写 Pipeline |
| 类型约束 | 配置为主，支持少量代码节点 | 配置为主，支持代码节点 | 配置为主，重文档解析 | 完全代码化，灵活度最高 |
| 学习曲线 | 中：先理解 RAG 概念即可上手 | 中：偏应用搭建，概念较少 | 中高：文档解析配置项多 | 高：需熟悉 LangChain API 与部署 |
| 生态集成 | 内置多模型接入、API 开放 | 内置多模型、插件市场丰富 | 依赖模型配置，偏单机 | 依赖社区包，集成无上限 |
| 生产部署 | Docker Compose / K8s，部署简单 | Docker Compose / K8s，部署简单 | Docker Compose，GPU 加速可选 | 自建服务与依赖，运维成本高 |
| License | Apache 2.0 | Apache 2.0（部分功能商业版） | Apache 2.0 | MIT |
| 适合谁 | 企业知识库、客服问答、文档问答 | 需要 Agent、多应用搭建的团队 | 深度文档解析场景（扫描件、复杂版式） | 需要完全定制 RAG 管道的算法团队 |
选型建议：如果核心诉求就是“企业文档/知识库问答”且希望快速交付，FastGPT 是综合成本最低的选择；若还需要搭建 Agent、工具调用等通用 LLM 应用，Dify 面更广；对复杂版式 PDF、扫描件等深度文档理解有强需求，优先评估 RagFlow；算法团队需要集成到自有系统或做精细调参时，才值得走 LangChain 自建路线。
版本迭代
FastGPT 从 2023 年的简易知识库问答工具起步，历经 v3/v4 两代架构，v4.x 阶段完成从对话式知识库到可视化工作流编排平台的转型（截至训练数据，可能已有更新版本）。版本演进主线是“知识库能力加固 → 工作流能力开放 → 多模型与生产化增强”。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v3 | 2023 年 | 知识库问答基础版 | 文档导入、向量检索、对话式回答，定位为可私有化部署的客服问答工具 |
| v4.0 | 2023-11 | 工作流编排上线 | 引入可视化流程编排，对话式与工作流式两种应用类型并存 |
| v4.6 | 2024 年上半年 | 模型管理与 UI 重做 | 新增模型统一管理后台，前端界面重构，对话日志模块完善 |
| v4.8 | 2024 年下半年 | 知识库结构与编排优化 | 知识库集合结构调整、工作流节点补全、多轮对话变量能力增强 |
| v4.9（最新正式版） | 2024 年底至 2025 年初 | 商业化与生产化收尾 | 对话测试分享、更细粒度的权限与审计、部署/升级体验优化（以官方 Release 为准） |
| 基准 | v4.6 | v4.8 | v4.9 | |
|---|---|---|---|---|
| GitHub Stars | 10k+ | 15k+ | 20k+ | 社区热度持续增长，反映真实采用度（截至 2025 年数据显示） |
| 官方文档观测 | 部署依赖手动改配置较多 | 新增配置项说明 | 文档明确标注迁移与升级路径 | 版本间配置兼容性逐步改善 |
| 知识库格式支持 | PDF/Word/Markdown 等 | 新增网页导入与 OCR 选项 | 沿用并优化解析稳定性 | 官方 Changelog 披露的格式扩展记录 |
v4.x 系列的整体趋势是从“能用的知识库工具”进化为“可生产化的 RAG 平台”。功能增长同时带来配置复杂度上升，但官方文档与社区教程数量同步增长，降低了学习门槛。选型时建议直接使用 v4.9 及更新版本，旧版 v4.6 及以下在模型接入和界面操作性上明显落后。
AI 应用场景
企业产品手册与客服问答机器人
阶段：RAG 知识库构建 → 多轮对话问答
解决的问题：企业产品手册动辄数百页，客服人员新人培训周期长、答复口径不一致；传统关键词搜索只能定位页面，无法直接回答“这个功能怎么开启”这类组合问题。FastGPT 将产品手册向量化入库后，配合客服话术提示词，每个问题自动从手册中检索相关章节并生成回答，同时附上引用出处，客服可一键核对原文。
具体案例：某 SaaS 公司客服团队将 200 页产品帮助中心文档导入 FastGPT，上线 AI 辅助客服后，单条咨询的平均处理时长从 8 分钟降至 3 分钟以内，且 AI 给出答案后客服仅需做引用复核即可发送。负责人反馈“新人培训周期缩短了一半”。
企业内部制度与政策问答助手
阶段：多知识库管理 → 分类路由 → 精准引用
解决的问题：集团企业制度文件分散在 OA、邮箱、共享盘，员工查询差旅报销标准、请假流程时“找不到、问不到、答不准”。FastGPT 可建立“人事制度”“财务制度”“行政制度”等多个知识库，并通过问题分类节点自动路由，员工在统一入口提问即可获得附有制度原文出处的答复，减少 HR/财务的重复咨询。
具体案例：某制造企业将 300+ 份制度文档分库导入，上线一个季度后，HR 部门的重复性咨询量下降约 40%，员工侧给出的满意度评分中“查找效率”项提升明显。IT 团队仅投入一周完成部署与知识库清洗。
面向开发者的 API 接入与嵌入式问答
阶段：API 开放 → 业务系统集成
解决的问题：FastGPT 每个应用可生成独立的 HTTP 接口（支持 GET/POST）与 WebSocket 对话接口，开发者无需在前端实现复杂的对话状态管理，直接将问答能力嵌入现有 Web 应用、企业微信、钉钉或飞书机器人。
具体案例：某教育机构将课件知识库接入教务系统，学生在课程页面直接提问“这门课的考试范围是什么”，答案自动引用课件原文；上线后答疑高峰期的 70% 基础问题由机器人承接，教师可聚焦个性化辅导。API 集成日均调用量 2000+ 次。
常见误区
误区“它是可视化拖拽工具，我作为业务人员也应该能直接搭出可上线的知识库机器人，不需要任何开发能力。”
正解可视化编排解决的是“流程组织”问题，但底层仍依赖技术理解：你需要理解切片与 Embedding 向量化的概念，才能判断检索为什么不准；需要能读懂 config.json 和 docker-compose.yml 才能完成部署和模型接入；排障时需要查看日志与 API 报错。真正让业务人员上手的前提，是运维人员先把部署、模型配置这些“地基”打好。
为何常见：产品界面把 AI 对话节点、知识库检索节点做成可视化卡片，掩盖了背后的技术复杂度，容易让非技术用户把“拖拽完成”误当成“全流程完成”。
误区“我把 100 份 PDF 传上去了，模型应该能回答里面的一切问题，如果答不出就是 FastGPT 不行。”
正解RAG 效果依赖全链路质量：文档解析是否正确（扫描版 PDF 需 OCR）、切片是否合理（过短丢上下文，过长引入噪声）、Embedding 模型与检索维度是否匹配、提示词是否约束了模型“只依据引用回答”。FastGPT 只是管道载体，不保证任何文档导入即获得完美效果。上线前应在预览模式逐条验证命中片段，反复调优切片和检索参数。
为何常见：用户将“大模型很聪明”等同于“知识库问答很聪明”，忽略了 RAG 中“检得准”是“答得对”的前提，而检索质量由数据工程决定。
误区“我先用 root/123456 登录，端口就开 3000 裸奔，反正服务器有防火墙，等正式上线再改。”
正解FastGPT 作为管理后台，默认账号使用内置公网 IP 扫描即可被爆破，数据泄露风险极高。正确做法是部署后立即改密，3000 端口只在内网或经反向代理暴露，并配置 HTTPS。同时 MongoDB 和 PostgreSQL 不应暴露公网端口。安全加固应视为部署步骤的一部分而非可选项。
为何常见：本地测试环境与生产环境同用一套配置，心态上“先跑通再说”，加上 Docker 部署的便利性掩盖了默认值的安全隐患。
误区“我换了个更便宜的 Embedding 模型，向量库重新生成太慢，直接删掉原来的向量、保留旧数据凑合用吧。”
正解不同 Embedding 模型产生的向量分布空间完全不同，新模型生成的查询向量与旧模型生成的文档向量无法直接比较，相似度计算会全部失真。更换模型后必须对全部知识库数据执行重新向量化，否则检索结果无异于随机抽取。FastGPT 后台提供了“重新向量化”的可视化入口，操作上正确步骤是先重建索引再开放问答。
为何常见：向量是“看不见的”内部表示，用户容易把它类比为数据库索引，以为只是速度差异，忽略了空间分布不一致的数学事实。
误区“FastGPT 是无状态服务，用 K8s 多开几个副本，QPS（每秒请求数）就上去了。”
正解FastGPT 应用的请求会打向下游的向量检索（MongoDB）和模型 API。应用副本确实可水平扩展，但 MongoDB 的 CPU 和 IOPS 往往先成为瓶颈；模型供应商侧的限流（Rate Limit）也可能压制整体吞吐。正确的扩容顺序是：先评估 Mongo 性能并配置副本集/云托管，再对模型 API 做预算和限流评估，最后才是弹性伸缩应用副本。
为何常见：从传统 Web 服务迁移而来的工程师容易把“无状态服务随便扩”套用到 RAG 系统，忽略了检索、模型两类外部依赖。
面试题
Q1. FastGPT 的核心定位是什么？
- A.通用大模型训练框架
- B.知识库问答与 RAG 可视化编排平台← 正确答案
- C.向量数据库中间件
- D.模型推理加速引擎
答案：B。FastGPT 的产品定位是面向知识库问答场景的 RAG 应用平台，核心卖点是可视化工作流编排与知识库管理。它不是训练框架（排除 A）、不是纯中间件（排除 C），也不以推理加速为目标（排除 D），B 准确描述其本质。
Q2. FastGPT 官方推荐的部署方式是？
- A.直接运行 Python 源码
- B.npm 全局安装
- C.Docker Compose← 正确答案
- D.二进制免安装包
答案：C。FastGPT 的官方部署模板位于仓库 deploy/fastgpt 目录，采用 Docker Compose 编排多个容器（主服务、MongoDB、PostgreSQL、Sandbox）。源码运行和 npm 安装均非官方推荐路径，二进制包同样不存在，因此 C 正确。
Q3. 在 FastGPT 中，“切片”（Chunk）指的是？
- A.对服务器磁盘进行分区
- B.将长文档按规则切分为多个文本块，作为检索最小单位← 正确答案
- C.对图片进行裁剪处理
- D.将模型权重切分为多份加速推理
答案：B。RAG 流程中，文档入库前需要按固定长度加上重叠区切分成文本块（Chunk），检索时以块为单位计算相似度。切片大小直接影响检索精度，与磁盘、图片、推理加速均无关，故选 B。
Q4. 更换 Embedding 模型后，正确的操作是？
- A.无需任何操作，直接继续使用
- B.只需要重新测试相似度阈值
- C.修改提示词即可避免影响
- D.对全部知识库数据执行重新向量化← 正确答案
答案：D。不同 Embedding 模型的向量空间不同，新旧向量无法直接比较相似度。重新向量化是唯一正确路径，后台提供可视化入口。选项 A、B、C 都绕开了向量空间不一致的根本问题，均不正确。
Q5. FastGPT 对话接口采用的通信方式是？
- A.HTTP 短轮询
- B.WebSocket 长连接← 正确答案
- C.FTP 文件传输
- D.UDP 数据报
答案：B。FastGPT 的对话接口基于 WebSocket，用于支持流式输出和多轮对话的实时交互。HTTP 短轮询不是其主要机制，FTP/UDP 与 Web 对话无关。故选 B。
Q6. 知识库问答效果差时，最优先排查的环节是？
- A.修改 AI 对话节点提示词
- B.更换更贵的对话模型
- C.检查检索命中的切片是否合理，调优切片与检索参数← 正确答案
- D.升级 FastGPT 到最新版本
答案：C。RAG 中“检得准”是“答得对”的前提。命中切片不合理时，提示词和模型再强也无法生成好答案。因此应先用预览调试观察命中片段，再调整切片长度与 Top K 参数。A、B、D 都不是根因解。
Q7. FastGPT 中“问题分类”节点的主要作用是？
- A.将问题翻译成多国语言
- B.对用户输入进行情感分析并回复
- C.判断问题类型，将不同问题路由到不同下游节点← 正确答案
- D.自动生成 FAQ 列表
答案：C。问题分类节点通过一次模型调用判断输入问题所属类别，并结合条件判断节点将不同类别问题路由到不同知识库或处理逻辑，是构建多部门客服系统的基础能力。其目的不是翻译、情感回复或生成 FAQ，故选 C。
Q8. 生产环境中需要 HTTPS 反向代理，主要是因为？
- A.容器不能直接处理 HTTP 协议
- B.直接暴露 3000 端口存在安全风险，且 WebSocket 也需要规范代理← 正确答案
- C.反向代理可以提升模型推理速度
- D.这是 Docker 部署的硬性要求
答案：B。3000 端口为服务默认管理端口，暴露公网会面临未授权访问风险；对话接口的 WebSocket 在代理层也需要正确配置 Upgrade 头。反向代理解决的是安全传输与入口规范化，与容器协议（A）、推理速度（C）无关，且 Docker 本身不强制（D），故选 B。
Q9. 以下哪些属于 FastGPT 的典型应用场景？
- A.企业产品手册客服问答机器人← 正确答案
- B.企业内部制度政策问答助手← 正确答案
- C.通过 API 嵌入业务系统的知识问答← 正确答案
- D.大规模图像生成与风格迁移
答案：ABC。FastGPT 的能力边界是知识库问答与 RAG，企业手册问答、制度查询、API 嵌入问答都是其典型落地场景。图像生成与风格迁移不在其能力范围内，故 D 排除。
Q10. 关于 FastGPT 生产部署，正确的说法有哪些？
- A.部署后应立即修改默认管理员密码← 正确答案
- B.升级前需备份 MongoDB 与 PostgreSQL 数据← 正确答案
- C.高并发场景下可直接无限制扩容应用副本解决一切问题
- D.生产环境建议使用 HTTPS 反向代理保护入口← 正确答案
答案：ABD。默认账号密码、升级备份、HTTPS 代理都是生产加固的关键项，A、B、D 正确。C 错误，因为向量检索依赖 MongoDB，模型 API 有限流，应用副本扩容不能解决全部瓶颈。故答案为 [0,1,3]。
参考来源
- webpageFastGPT GitHub 仓库源码、Release 与部署模板