一、项目过程概述

基于 FastGPT 构建物流数据智能问答系统，核心流程包含两大模块：

1. 知识库搜索（①）
   • 数据来源：本地 CSV 文件手动上传至 FastGPT，作为知识库基础数据。
   • 处理逻辑：通过调用外部索引模型（嵌入模型），将 CSV 中的物流数据转化为向量索引，支持用户查询时的语义相似性检索（RAG 机制）。
2. 预测模型调用（②）
   • 模型基础：基于历史物流数据训练的预测模型（外部语言模型或定制模型）。
   • 响应逻辑：结合知识库搜索结果（①的输出），调用该预测模型生成用户问答的最终响应。

二、当前存在的核心问题

1. 知识库数据更新效率低
   • 新物流数据需手动导入 CSV 文件至 FastGPT，无法实现自动化 / 批量更新，时效性差，且频繁手动操作易出错。
2. 预测模型适应性不足
   • 预测模型基于历史数据训练，当新增物流数据（尤其是分布或特征变化较大的数据）加入时，需重新训练模型才能适配新数据，导致模型维护成本高、迭代周期长，难以快速响应数据动态变化。

三、指导老师提问

1.这个查询这个地方，它是直接用RAG来查询的吗？

解答：

• 在 FastGPT 中，我选择了索引模型、语言模型并上传 CSV 文件后，工作流中调用数据库的查询过程本质上是基于 RAG（检索增强生成）机制的，关键细节：

  ①. CSV 文件的处理：构建检索索引（RAG 的 “检索基础”）

  • 上传 CSV 后，FastGPT 会先对文件内容进行解析（比如按行或按字段拆分数据），然后通过你选择的索引模型（通常是嵌入模型，如 BERT、Sentence-BERT 等）将文本信息转化为向量（Embedding）。
  • 这些向量会被存储到工具内置的向量数据库（或你配置的外部向量库）中，形成可检索的 “知识索引”。这一步是 RAG 的核心前提 —— 将非结构化 / 结构化数据转化为机器可计算相似性的向量，以便后续快速匹配用户查询。

  ②. 查询时的工作流：检索 + 生成（RAG 的 “增强逻辑”）

  当用户发起查询时，工作流的调用过程会遵循 RAG 的经典流程：

  • 检索阶段：用户的查询文本会先被索引模型转化为向量，然后与 CSV 文件生成的向量索引进行相似性匹配（如计算余弦距离），快速筛选出与查询最相关的信息片段（来自 CSV 中的数据）。
  • 增强生成阶段：FastGPT 会将检索到的相关信息片段作为 “上下文”，传递给你选择的语言模型（如 GPT-3.5/4、LLaMA 等），语言模型基于这些上下文内容生成回答，确保输出的结果既符合用户查询意图，又能结合 CSV 中的具体数据（避免 “幻觉”）。

  ③. 与传统数据库查询的区别：更依赖语义匹配

  虽然工作流中会 “调用数据库”，但这里的 “数据库” 本质是存储向量索引的向量数据库（而非传统结构化数据库）。其查询逻辑不是基于 SQL 的精确字段匹配（如 “SELECT * WHERE id=1”），而是基于语义相似性检索—— 这正是 RAG 区别于传统数据库查询的核心：它不要求用户的查询与数据格式严格匹配，而是通过向量相似度理解 “语义相关性”，更适合处理自然语言查询。

四、指导老师任务

1.测试 FastGPT 中 RAG 查询的准确率，重点验证复杂场景表现

具体要做的事：

• 先测试单表查询的准确率，看简单问题能否正确响应；
• 再测试多表关联查询、数据统计计算这类复杂场景，验证是否能得出正确结果；
• 根据测试结果判断：如果复杂查询准确率达标，就不用调整现有配置；若不达标，再考虑优化。

1
2

原文：
检索的查询可能不太准确。比如说你回头可以测一下，我们回去回头测一下，就是让他比如说单表的查询，它的准确率怎么样。然后如果是多表的案或者说是一些统计数据的统计，看能不能统计的出来。就是按照我们以前的经验，他可能对一个比较简单的问题他能够想做得到。但如果稍微复杂一点，或者说涉及到多表，或者说是到统计计算的，他可能就没有能来做。还是要看一下他是复杂查询的这个准确程度。如果说他准确性可以，他能够对那就对他的不感就不用改

2.封装模型重训练 + 重部署接口，实现状态监控并对接前端与 FastGPT

具体要做的事：

• 编写脚本，封装模型重训练 + 重部署接口，支持从业务系统数据库获取数据用于重训练，训练完成后自动完成模型重部署；
• 实现重训练 + 重部署的状态监控功能，实时跟踪流程进度（如数据获取中、训练中、部署中、完成 / 失败）；
• 提供两个对接前端的接口：一个用于触发重训练重部署的命令接口，另一个用于向前端推送 / 供前端获取状态的通知接口；
• 确保重部署完成后，FastGPT 工作流调用的四个预测 API（进口价格 / 进口数量 / 出口价格 / 出口数量）能使用最新训练的模型进行预测。

1
2
3
4
5
6

原文：
预测模型（代码就是上面提到的）你现在要做的事情就是第一个封装重训练的接口，这样能够取到那个业务系统的数据库里边的这些数据。取得这些数据之后，要把这些数据能够用到去做重训练。重训练完了之后，这个模型进行重部署。然后再放到fastgpt的工作流中
这个预测模型得要有个接口封装出来，那你要写个脚本，里面要重新封装，而且这个重训练重封装这个过程要有一个对他的一个状态的一个监控，就是用户要知道他点击了那个重训练之后，他要知道当前是走到哪一步，当前这个重部署有没有部署完，同步署完了之后他再去预测，这个时候他预测的时候用的是么一个模式。因为这个过程可能会花很长的时间，所以说你的这个重训练同部署的要有一个状态监控的一个现场去去监管他的这个状态。状态要通知到前端，前端要知道要获取的状态。
要做一点开发，要写代码
前端给他们两个接口。这是一个是用来触发你的同训练同步署的每个命令的。另外一个是你要通知他的，你是你给他发那个状态通知了。
或者说你做一个轮巡也可以，你让前端去轮询你对吧？

3.梳理 FastGPT 工作流的问题类型与核心场景，明确两大场景落地重点

具体要做的事：

• 梳理 FastGPT 工作流中涉及的所有问题类型，按核心场景分类整理成表格；
• 重点明确两大核心场景的定位：一是 RAG 知识问答场景，二是数据查询场景；
• 基于场景梳理结果，为后续接口对接、功能优化及落地执行提供明确依据。

1
2

原文：
把这个工作流梳理一下，就是看一下他们当前哪些问题的类型，然后可能要列一个表。主要是这些场景你梳理一下。但是说可能主要实现的两个场景，一个就是RAG的一个知识文档，另外一个就是查数据。他可能主要是做这样两个场景