# 下一步开发计划

## 2025.1.20

1. 知识库RAG
   1. 测试
   测试相关资料参考链接: <https://1988251901502969000zhuanlan.zhihu.com/p/>

      - [ ] 参照主流知识库架构增减修改当前知识库字段
      - [ ] 根据主流RAG测试要求完善知识库检索测试
      - [ ] 开发LLM输出测试
      - [ ] 横向对比不同检索方法或模型下的测试效果
   2. dify原生知识库
   dify原生支持的知识库可以直接配置firecrawl的api_key，实现知识库爬取，因此
2. 后端封装backend

   1. 重置接口，v1版本，restfulAPI
      预期实现效果：
      - [x] 添加任务
      - [x] 查询任务
      - [x] 执行任务
      - [x] 获取所有知识库
      - [x] 知识库搜索
   2. 新增功能
      - [ ] 业务操作原子化
      - [ ] 知识库更新相关
      - [ ] 日志功能
   3. 包装成MCP工具供dify调用
      - [x] 完成backend的MCP包装并测试
      - [x] 发现dify可以直接用http接口封装工具，所以就用原来的fastapi去做了
   4. 阿里云部署
      - [x] 将后端部署阿里云

3. dify节点

   - [x] 完成dify的LLM输出工具，主要负责处理搜索逻辑和问题分类，调用api，发布工具。
   也可能直接在backend里全部实现，直接集成到bot里

4. firecrawl方案
   1. 闭源方案购买
      年费大概9000元/年，不支持绕过robots.txt
   2. 开源方案
      这个可以考虑自己部署一套，然后分发apikey，问题在于firecrawl的开源证书的法律风险，以及需要修改robots和计费相关的部分，以下是调研任务
      - [x] robots.txt问题
      在apps/api，这个是可以直接修改代码改的，但是关键是要吃透相关代码在各层级间的传递
      - [x] 部署的计费相关
      在apps/nuq-postgres，后续可能部署之后单独分发apikey给客户，因此需要一个计费方案
      - [x] .env问题
      需要查阅资料了解里面的一些参数配置重新配置之后好上云，包括API_KEY配置、流量统计和配置