低成本搭建CustomGPT：API+RAG+Function Calling实战

这次我们来看一个非常实际的主题如何用尽量低的成本做出一个可用的 CustomGPT。很多人以为 CustomGPT 就一定要开 ChatGPT Plus然后在官方 GPTs 后台里传几个文件、写一句 system prompt 就算完成。其实这只适合个人轻量使用。一旦你希望把它接到自己的业务系统里做知识库问答、工具调用、批量任务甚至给团队内部做一个统一的 AI 助手最稳的路径不是依赖官方 GPTs而是自己用 API 和开源组件搭一套“平价 CustomGPT”。这篇文章不是概念普及而是按“能不能落地”来组织。核心关注点是模型怎么选、知识库怎么做、工具调用怎么接、API 怎么暴露、批量任务怎么跑、成本怎么压、常见问题怎么排。看完之后你可以根据自己的场景选一条路线从零开始搭出第一个可用的 CustomGPT 服务。先给一个整体结论平价 CustomGPT 的常规做法是“API 模型 RAG 知识库 Function Calling 工具调用 异步队列”。如果不想写代码可以用开源平台做私有化部署如果对数据安全要求很高可以用开源模型完全本地跑。这三种路线不冲突可以先用开源平台验证效果再把核心模块替换成自己写的服务。1. 核心能力速览这个主题并不是某个单一开源项目而是一套建设路线。为了让你快速判断哪种方式适合自己我先把三种常见方案的核心能力整理成一张表。方案路线技术形态主要功能硬件门槛启动方式接口能力批量任务成本模式纯 API 自建Python/FastAPI 模型 API对话、知识库问答、工具调用、业务集成无 GPU 要求命令行启动自定义 HTTP 接口可结合队列实现按 Token 付费开源平台托管Docker Compose 部署可视化知识库、对话应用、工作流编排低普通服务器可跑Web UI 容器启动平台自带 API多数平台支持服务器费用 模型费用本地开源模型LLM 向量库私有化问答、离线推理、敏感数据隔离需要 GPU命令行或 WebUI 启动视方案而定可结合脚本实现硬件一次性投入 电费从这张表能看到三种方案的主要区别在于成本结构和技术控制力。如果你的团队已经有后端开发能力API 自建是上限最高的一条路如果你只是想快速给业务加一个带知识库的 AI 助手开源平台的人工成本和迭代速度会好很多如果你的业务对数据隐私非常敏感那本地开源模型几乎是唯一选择。需要注意的是这里的“平价”不是“免费”。即便用最便宜的小模型也会产生 Token 费用或服务器费用。所谓平价是把每一块钱花在真正用得上的地方小任务用小模型大任务才上大模型知识库避免把整篇文档塞进上下文重复问题走缓存。这样整体成本能比无脑订阅、无脑用大模型低一个数量级。2. 为什么需要平价的 CustomGPT 方案2.1 官方 GPTs 的现状和限制官方 GPTs 是 OpenAI 在 ChatGPT 产品里提供的定制入口。它的优点是创建门槛低不需要写代码上传文档、写一条 system prompt、发布一个链接就能分享。对于个人学习和轻量试用这个方案很直观。但从工程化角度来看它有几点现实限制。首先是账号和订阅门槛。创建和长期使用 GPTs 依赖 ChatGPT 账号部分高级能力在 Plus 订阅下开放这本身是一笔固定月费。如果团队里有多个成员都要用不同职责的助手账号成本会随人数增长。其次是接口封闭性。官方 GPTs 本身并不提供公开的 HTTP API 让外部业务系统直接调用如果你想把定制助手嵌进自己的后台、CRM 或工单系统需要另寻出路。第三是知识库和上下文有配额限制上传文件的大小和数量都受平台约束不适合大规模私有知识库。还有一个被讨论很多的现象就是用户感知的“GPT 降智”。从工程角度看这通常不是模型本身退化而是负载均衡、上下文变长导致注意力被稀释、或模型路由发生变化的结果。如果你把长文档直接塞进对话前面几百条历史消息也没有清理任何大模型都会出现回答质量下降。这恰恰说明把知识库、上下文管理和模型路由做在系统层面比堆一个超长 prompt 更可靠。2.2 平价路线的三种选择第一种是 API 自建你只买模型能力对话逻辑、知识库、权限控制和工具调用全部自己写。优点是完全可控能按业务需求定制不会受第三方产品界面限制缺点是需要一些后端开发量并且要自己处理请求日志、限流、异常重试等问题。第二种是开源平台托管Dify、FastGPT、MaxKB 这类开源项目已经把知识库上传、文档解析、检索、Prompt 编排、API 发布都做成了可视化界面。你可以部署到自己的服务器上接上云端模型 API也可以接本地模型。优点是交付快非开发人员也能配置知识库和对话流程缺点是深度定制时还是要改源码或写插件而且平台本身也在持续迭代版本升级时需要预留时间。第三种是本地开源模型选择 Qwen、DeepSeek、Llama 系列等开放权重的模型在自己的 GPU 服务器上跑推理。优点是数据不离开内网适合有严格合规要求的业务缺点是需要评估显存和算力模型的综合能力通常不如云端顶级模型需要做针对性的 prompt 和微调。这三种路线可以混用先用开源平台把流程跑通再逐步把高频模块下沉成自建服务或者把敏感数据走本地模型非敏感任务走云端 API。3. 整体架构设计平价 CustomGPT 的核心不是某一个模型而是一套可组合的架构。我通常会把它拆成四个层次。接入层负责接收用户请求包括 Web 对话页面、企业微信/钉钉机器人、HTTP API 接口等。它只做参数校验、身份认证和请求转发不关心后端的模型是哪个。编排层是大脑负责决定当前请求应该调用什么工具、检索哪部分知识、用哪个模型回答。系统级 prompt 在这一层拼装知识库检索结果在这一层注入Function Calling 的工具列表也在这里维护。这一层写得越干净后续加新功能越容易。知识层负责把文档变成可检索的内容。原始文件经过解析、清洗、切分后写入向量库同时保留原文 ID 和元数据。每次用户提问时先用相似度检索取回最相关的片段再把这些片段作为上下文交给模型。知识层要重点处理的是切分粒度、检索相关性和结果去重。模型层负责最终生成。模型可以是一个或多个 API 服务也可以本地部署。我的建议是不要在所有场景里都用一个模型意图识别、标题生成、数据提取这类简单任务用便宜小模型复杂推理、长文写作、代码生成这类任务才用更强的大模型。这样能把成本压得很低同时保证重要任务的效果。4. 模型层选型与接入4.1 云端 API 模型云端 API 模型的最大优势是开箱即用不需要准备 GPU也不需要维护推理服务。OpenAI 的轻量级模型比如 gpt-4o-mini、gpt-4.1-mini 这类特别适合做高频低成本的对话和分类任务更强的大模型适合做复杂推理和内容生成。具体可用模型名称和定价以模型服务商当前文档为准不要凭印象写死在配置文件里。接入云端模型时建议把服务地址、模型名称、API Key 都放到环境变量或配置中心管理不要硬编码在代码里。这样后续切换模型、调整版本成本会低很多。另外云端 API 有速率限制生产环境要处理 429 限流错误和超时重试。4.2 本地开源模型本地开源模型的价值不是“便宜”而是“可控”。对于合同审核、内部知识库、客户数据问答这类场景数据不出内网是硬性要求。选择本地模型时第一件事不是对比榜单而是先看自己的显卡显存能跑多大参数量的模型。一般来说7B 到 14B 级别的量化模型可以用普通消费级显卡或单张专业卡运行更大的模型需要更充裕的显存和多卡方案。不同模型的显存占用差异很大实际部署时要以推理框架的官方建议为准。本地模型部署完成后建议先用一个固定的测试集做一轮效果回归记录回答质量、生成速度和显存峰值形成基线数据。后续只要换了模型版本、改了量化参数、调整 prompt就把新结果和基线对比避免“模型变笨了”却不知道是哪个改动引起的。4.3 模型路由与降级模型路由是平价方案里性价比最高的一环。简单做法是先让一个便宜小模型判断用户意图根据意图决定使用哪个模型和哪些工具。复杂做法是把路由规则写进配置中心不同业务线、不同用户等级使用不同模型高峰期自动降级到更便宜的小模型。降级策略要注意可观测性。每次降级都要记录原始请求、实际使用的模型、返回内容和延迟情况否则降级后出了问题很难定位。最稳妥的降级顺序是大模型不可用 - 小模型小模型仍然不可用 - 返回缓存结果缓存也没有 - 返回明确错误提示不要出现假成功。5. 用 API 快速搭建 CustomGPT 服务5.1 最小 API 调用示例先从最基础的聊天补全接口开始。假设你已经拿到可用的 API Key并安装了 openai 客户端库。pip install openai下面这个 Python 示例展示了一次带系统提示词的对话调用系统提示词就是 CustomGPT 行为规则的核心。import os from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) ) system_prompt ( 你是企业知识库助手。 你只能根据检索到的知识库内容回答问题。 如果检索结果不足以回答明确告诉用户暂时没有相关资料。 ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_prompt}, {role: user, content: 介绍一下 API 接入流程} ], temperature0.3, timeout60 ) print(response.choices[0].message.content)这个示例有两个关键点时间超时一定要设置避免请求长时间挂起temperature 在知识库问答场景建议调低减少模型自由发挥。实际项目中system_prompt 应该从配置中心读取而不是硬编码在代码里。5.2 函数调用Function CallingCustomGPT 和普通聊天机器人的最大区别在于它能调用工具。比如查询订单状态、获取工单详情、查询天气、读写数据库都可以通过函数调用暴露给模型。tools [ { type: function, function: { name: get_order_status, description: 查询订单当前状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } } ] response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是订单查询助手。}, {role: user, content: 帮我查一下订单 20250601 的状态} ], toolstools, tool_choiceauto ) message response.choices[0].message if message.tool_calls: print(message.tool_calls)当模型返回 tool_calls 后你的代码需要真正执行对应的函数把结果作为一条 roletool 的消息追加给模型模型才会根据工具结果生成最终回答。这个循环要处理异常工具本身执行失败时要返回明确错误而不是让模型瞎猜。5.3 流式输出与超时控制对话体验上流式输出几乎是必须的。它能让用户第一时间看到模型开始回复减少等待焦虑。使用 streamTrue 后逐块处理响应即可。stream client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_prompt}, {role: user, content: 写一段 200 字的商品介绍} ], streamTrue ) for chunk in stream: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)流式模式下的超时控制和普通模式不同。普通模式是“整次请求必须结束”流式模式则要改成“两次返回之间不能超过 N 秒”。实现时可以用一个后台线程定期刷新最后活动时间超过阈值就断开连接避免客户端卡死。5.4 暴露成 HTTP 接口要让其他系统调用你的 CustomGPT最直接的方式是用 FastAPI 写一个 HTTP 服务。以下是最小可运行的服务模板。pip install fastapi uvicornfrom fastapi import FastAPI from pydantic import BaseModel from openai import OpenAI app FastAPI() client OpenAI() class ChatRequest(BaseModel): message: str session_id: str default class ChatResponse(BaseModel): reply: str app.post(/chat, response_modelChatResponse) def chat(req: ChatRequest): messages [ {role: system, content: 你是定制业务助手。}, {role: user, content: req.message} ] resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, timeout60 ) return ChatResponse(replyresp.choices[0].message.content) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务后用下面的 curl 命令验证接口是否可用。curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {message: 你好} \ --max-time 60这里需要注意生产环境不要把服务直接绑定 0.0.0.0 并暴露到公网必须加认证和限流。最简单的做法是在中间件里校验请求头中的 token并按用户维度做速率限制。6. 知识库与 RAG 设计6.1 文档切分知识库问答的基础是文档切分。切分质量直接决定检索效果。常见的切分维度有时间、章节、段落和固定 token 长度。最推荐的做法是优先按 Markdown 标题或文档结构切分保留一个“大块”作为上下文完整性的锚点再在这个大块内按固定窗口滑动切分。比如先按二级标题切出章节再把章节按每 500 到 800 token 切成子块相邻子块之间保留 50 到 100 token 的重叠。这样既能保证单块内容不过长又能避免关键词刚好落在切分边界上导致检索不到。切分完成后每个片段要保存文档来源、章节路径、页码等元数据。这样检索结果可以溯源回答时也能把参考资料一并返回给用户。6.2 向量化与检索把切分好的文本片段向量化后写入向量数据库。向量化可以用模型服务商提供的 Embedding 接口也可以用本地嵌入模型。选择嵌入模型时重点看检索效果而不是追求高维数或大模型。下面是一个最小可用的检索逻辑示例先对用户问题做向量化再和知识库片段计算相似度。from openai import OpenAI client OpenAI() def get_embedding(text: str): resp client.embeddings.create( modeltext-embedding-3-small, inputtext ) return resp.data[0].embedding # 实际项目中向量库和相似度计算应使用向量数据库完成 def search_chunks(question: str, chunks: list) - list: q_vec get_embedding(question) scored [] for idx, chunk in enumerate(chunks): score sum(a * b for a, b in zip(q_vec, chunk[vector])) scored.append((score, idx)) scored.sort(reverseTrue) return [chunks[i] for _, i in scored[:5]]生产环境不要自己写余弦相似度循环直接用具备向量索引能力的数据库或检索服务。检索时建议用“召回 20 条、重排取 5 条”的思路先靠向量检索快速度召回再用语义重排模型或关键信息过滤让真正相关的片段排在前面。6.3 检索增强生成RAG 的关键不在于“把检索到的内容塞给模型”而在于如何拼装提示词避免模型把知识库内容当成自己的臆想。给模型的内容块要包含明确的来源标记和引用编号并在 system prompt 里要求模型只依据这些内容回答。def build_prompt(question: str, contexts: list) - list: context_text \n\n.join( f[{i 1}] {chunk[text]}\n来源{chunk[source]} for i, chunk in enumerate(contexts) ) return [ { role: system, content: ( 你是一个知识库问答助手。 只能依据下方【参考资料】回答不能使用你自己的常识补充。 如果资料中没有答案就说当前资料库中未找到相关内容。 ) }, { role: user, content: f【参考资料】\n{context_text}\n\n【问题】\n{question} } ]这种拼接方式有两个好处第一模型看到的是带编号的参考资料生成时容易按引用说话第二检索不到相关内容时模型被明确要求说“未找到”而不是强行编造。实际落地时还可以再加一层校验检查回答中是否引用了资料编号如果没有引用就提示用户补充资料。6.4 会话记忆会话记忆是 CustomGPT 体验里最容易失衡的部分。直接无脑把历史消息全部送给模型会迅速撑爆上下文窗口还会让模型被早期错误回答带偏。推荐的做法是每一轮只保留最近的 6 到 10 条消息摘要并单独维护一个“用户画像”字段记录用户偏好和当前任务目标。上下文压缩可以交给模型完成比如每隔几轮把历史对话压缩成一段结构化摘要再作为下一轮系统消息的一部分。对检索类会话每次回答前都重新执行检索不要把上一轮的检索结果作为历史消息继续传下去。7. 开源平台托管方案7.1 常见平台选择如果你不想从零写代码可以直接部署开源平台。目前社区里比较活跃的有 Dify、FastGPT、MaxKB 等。这类平台通常提供以下能力知识库文档上传与解析、可视化 Prompt 编排、模型供应商接入、对话日志查看、API 发布。它们的共同优势是快速上线缺点是深度定制时需要改代码并且平台升级可能带来配置迁移成本。选平台时不要只看 star 数要看你需要的功能是否齐全知识库是否支持多种文档格式、是否支持混合检索、工作流是否支持条件分支、API 是否可以按应用维度隔离权限、日志是否完整可回溯。这些比单纯的功能列表更重要。7.2 Docker Compose 部署模板多数开源平台都提供 Docker Compose 方式部署。下面的模板是通用形式具体目录结构和启动脚本要以所选平台的官方仓库为准。# 先创建项目目录 mkdir customgpt-platform cd customgpt-platform # 以下为通用模板实际需要下载对应平台的 docker-compose.yml docker compose pull docker compose up -d启动后在浏览器打开平台管理页面按流程创建应用。第一次部署最容易踩的坑是端口冲突和持久化目录未挂载。端口冲突时修改 compose 文件里的宿主机端口数据卷必须挂载到宿主机目录否则容器重建后知识库和配置就丢了。7.3 配置模型与上传知识库登录平台后首先在模型供应商设置里添加可用的模型服务商填入 API Key 和模型名称。接着创建知识库上传文档平台会自动完成解析、切分和向量化。最后创建一个对话应用把知识库绑定到应用并配置系统提示词。配置完成后建议先在平台内置的对话界面里测试两轮确认回答质量、引用来源展示、文档解析是否正常然后再开启 API 访问。平台生成的 API 地址和密钥需要保存好并设置访问白名单或限流策略。这里要多说一句知识库文件里如果包含用户隐私或版权内容上传前必须确认授权边界避免把不该公开的内容发布到内部系统之外。8. 成本控制与批量任务8.1 Token 成本优化平价 CustomGPT 的成本大头几乎都来自模型 Token 消耗。优化手段包括五个方面。第一能用小模型就不用大模型用路由把简单请求分流到最便宜的模型。第二控制上下文长度知识库只传入检索后的片段不用整篇文档。第三系统提示词尽量精简但不要压缩到影响行为规则效果。第四对固定格式任务使用结构化输出减少模型重复回答的冗余内容。第五所有结果做缓存相同或类似问题直接命中缓存不再调用模型。在实现时每次模型返回都要解析 usage 字段把 prompt_tokens、completion_tokens、total_tokens 写进日志。有了这批数据才能知道每个功能模块的真实成本。成本超出预期时按模块定位是提示词太长、知识库片段太多还是调用次数过多再针对性优化。8.2 结果缓存结果缓存最适用于两类请求一类是完全相同的问题适合用精确哈希匹配另一类是语义相近的问题适合用向量相似度匹配。精确缓存可以用 Rediskey 是问题加模型版本的哈希语义缓存用向量库查到一个相似度足够高且固定时间内的旧结果就直接返回缓存内容。缓存要设置过期时间因为知识库会更新模型版本也会替换。知识库更新后最好把相关问题的缓存主动清理避免回答内容与最新资料不一致。缓存命中率要单独监控如果长期低于 10%说明用户问题重复度低再考虑关闭语义缓存以节省查询开销。8.3 批量任务队列需要批量生成内容的场景比如商品描述、标签提取、工单分类不适合用同步接口一次处理几千条。正确做法是引入任务队列接收文件或列表拆分成单条消息进入队列由消费者逐个调用模型处理结果写回数据库或输出目录。任务队列可以用 Redis Stream、RabbitMQ也可以用简单的数据库任务表加轮询。每条任务要记录状态待处理、处理中、成功、失败。失败任务要设置重试次数上限超过上限后进入死信队列由人工检查。批量任务还要设置每秒请求数上限避免触发模型服务商的速率限制。import time import json def process_batch(tasks): for task in tasks: try: resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: task[system_prompt]}, {role: user, content: task[content]} ], timeout60 ) task[result] resp.choices[0].message.content task[status] success except Exception as e: task[status] failed task[error] str(e) time.sleep(0.5) # 控制请求速率这个示例只展示了单机顺序处理。生产环境建议把任务消费做成并发 worker并记录每个 task 的耗时、Token 消耗和重试次数方便统计整批任务完成时间与成本。9. 性能观察与资源占用9.1 API 调用延迟与 Token 统计API 方案不需要关心 GPU 显存但要重点关注延迟和 Token 消耗。每次调用模型响应体里会包含 usage 字段把它解析并写入日志是最基本的性能观测手段。延迟方面需要区分“首 token 时间”和“总生成时间”。首 token 时间主要受网络和模型排队影响总生成时间主要由输出长度决定。如果用户觉得回答慢打开日志看首 token 时间是否异常再判断是网络问题还是模型负载问题。如果输出内容普遍偏长可以在系统提示词中要求更精简的回答或者在请求参数中设置 max_tokens 上限。9.2 本地模型资源观察本地部署模型时资源观测的重点是显存、内存、GPU 利用率和温度。启动推理服务后用 nvidia-smi 可以持续监控显存占用。如果显存接近上限需要降低模型量化精度、减少并发数或者换更小的模型。watch -n 1 nvidia-smi运行一段时间后记录稳定状态下的显存峰值和平均生成速度。模型量化会明显影响显存占用和生成速度但也可能带来回答质量下降因此每次切换量化参数后都要做效果回归。除了显存还要关注 CPU 内存是否足够因为输入文档切分、向量检索等模块在 CPU 上运行内存不足会导致进程被系统杀掉。9.3 降低延迟和占用的手段云端 API 方案降低延迟的主要方式是减少请求轮次。一次请求内完成多轮函数调用会显著增加延迟能并行执行的工具调用尽量让模型一次返回多个。本地模型方案降低延迟的主要方式是调整量化精度、请求批处理和推理参数。生成长度越长等待越久所以业务场景要严格控制 max_tokens。从资源占用角度看最大的坑是一次性把整个知识库加载到内存或者把向量搜索和模型推理放在同一台机器上互相抢资源。更稳妥的做法是模型推理节点和知识库检索节点分开部署前者吃 GPU后者吃 CPU 和内存。如果预算有限必须合设至少要限制并发数并给检索服务和推理服务各自设置资源上限。10. 常见问题与排查方法问题现象可能原因排查方式解决方案API 返回 401/403API Key 错误或权限不足检查请求头 Authorization 和环境变量重新生成 Key确认权限范围API 返回 429触发速率限制查看响应头 Retry-After 和调用日志降低并发增加退避重试开启缓存超时或连接中断网络不稳定、服务端负载高查看超时日志区分首 token 和总耗时设置合理超时失败重试降级到小模型回答质量明显下降上下文过长、知识库检索到无关内容打印实际发送给模型的 messages清理历史消息限制检索片段数量重排检索不到相关内容切分粒度过大或过小、向量模型不匹配抽样检查切分片段测试不同 query 的检索结果调整切分策略更换嵌入模型增加重叠函数调用不生效tools 参数格式错误或模型版本不支持打印原始响应检查 tool_calls 字段确认 API 版本简化 tools 定义批量任务卡住队列消费异常、限流触发查看任务状态和消费日志增加失败重试设置死信队列监控存活本地模型显存不足模型参数或量化精度超出 GPU 显存运行 nvidia-smi 观察显存占用降低量化精度缩小 batch换小模型平台容器重启后配置丢失数据卷未挂载到宿主机检查 docker inspect 的 Mounts 字段重新挂载持久化目录迁移数据库排查问题的第一原则是看日志不要靠猜。接入层、编排层、模型层、知识库层各自保存结构化日志日志里至少要有请求 ID、用户 ID、模型名称、Token 消耗、耗时和错误信息。有了完整日志大多数问题都能在几分钟内定位到具体模块。11. 最佳实践与合规使用第一个建议是第一次上线前先压一套最小测试集。准备 20 到 50 条真实业务问题覆盖正常问题、模糊问题、无答案问题和需要工具调用的问题每次改版后都拿同一套问题回归。这样能快速发现回答质量退化而不是等用户投诉后才反应过来。第二个建议是模块化配置。系统 prompt、模型名称、温度、知识库路径、缓存开关全部放到配置文件或环境变量里。不要因为改一个 prompt 就重新发布整个服务。配置变更后要留出旧的配置快照方便回滚。第三个建议是接口安全。对外提供的 API 必须做身份认证、请求频率限制和请求体大小限制。内部的模型 API Key 只存放在服务端环境变量中不要打印到日志不要发到前端。知识库内容如果涉及版权、个人信息或未公开数据必须在数据采集、存储和输出环节都做好权限控制。第四个建议是合法合规。CustomGPT 的最终输出内容要加人工复核机制特别是用于客服回复、合同摘要、医疗建议、金融分析等场景。工具调用如果涉及修改数据库、发送消息、触发支付等高风险操作必须加二次确认。使用用户上传的数据时要确认拥有合法的处理与存储授权。人脸、声音、身份信息等敏感数据更要严格遵守相关法规并明确告知用户数据用途。第五个建议是监控与告警。每个请求的失败率、延迟、Token 消耗、成本都要有指标。失败率突然升高、延迟变长、成本异常增长时要能及时收到告警。批量任务要设置进度通知处理完一批给到汇总报告而不只是静默完成。12. 总结与下一步平价 CustomGPT 的核心思路并不复杂小模型与路由控制成本RAG 解决知识库问题Function Calling 打通工具调用异步队列支撑批量任务完整日志保证可观测性。如果你从零开始我建议的顺序是先利用开源平台跑通一个最简单的知识库问答应用确认模型和知识库效果然后抽一两个高频接口用 FastAPI 自己实现掌握 API 调用和提示词拼接的核心逻辑最后再逐步加入函数调用、任务队列和缓存形成一个真正能支撑业务的自建服务。最值得优先验证的功能是知识库检索质量。因为模型能力通常不是瓶颈瓶颈在于用户的问题能否检索到正确的资料片段。先拿 20 条真实问题测一遍你就知道这个方案值不值得继续投入。最容易踩的坑有三个一是把长文档整篇塞进上下文导致质量和成本同时失控二是没有限流和重试批量任务一跑就触发速率限制三是不看 usage 字段不知道成本花在哪里。这三个坑都能通过日志和监控发现前提是在第一天就把日志建好。下一步可以继续做三件事接入更多的工具调用场景比如查工单、查库存、读取内部数据把知识库能力从文档问答扩展到数据库问答建立基于历史日志的效果评估集持续用数据驱动优化模型提示词。这样你的 CustomGPT 就不再只是“一个聊天机器人”而是真正嵌入业务系统的智能助手入口。