61 lines
5.4 KiB
Markdown
61 lines
5.4 KiB
Markdown
# 下一步开发计划
|
||
|
||
## 2025.1.13
|
||
|
||
1. 知识库RAG
|
||
测试相关资料参考链接: <https://1988251901502969000zhuanlan.zhihu.com/p/>
|
||
|
||
- [ ] 参照主流知识库架构增减修改当前知识库字段
|
||
- [ ] 根据主流RAG测试要求完善知识库检索测试
|
||
- [ ] 开发LLM输出测试
|
||
- [ ] 横向对比不同检索方法或模型下的测试效果
|
||
2. 后端封装backend
|
||
|
||
1. v2API全面增补，废弃v1API，修改data_service.py里为v1保留的旧接口。
|
||
预期实现效果：
|
||
- [ ] 添加任务
|
||
- [ ] 查询任务
|
||
- [ ] 执行任务
|
||
- [ ] 知识库搜索
|
||
2. 包装成MCP
|
||
|
||
3. dify节点
|
||
|
||
- [ ] 完成dify的LLM输出工具，主要负责处理搜索逻辑和问题分类，调用api，发布工具。
|
||
也可能直接在backend里全部实现，直接集成到bot里
|
||
|
||
4. firecrawl与替代方案调研
|
||
|
||
1. firecrawl付费方案
|
||
- 常规订阅链接: <https://www.firecrawl.dev/pricing>
|
||
注意: 此链接下均是按时间订阅的,每月限制额度, 可额外购买, 但是考虑到客户使用的时候可能会固定时间集中使用(**采集新wiki, 更新旧wiki**)
|
||
- 企业订阅方案: 需要联系firecrawl订制
|
||
2. firecrawl开源方案
|
||
- 开源github链接: <https://github.com/mendableai/firecrawl>
|
||
- 优劣对比
|
||
|
||
| 对比维度 | 开源版 (Self-hosted) | 云服务版 (Cloud / SaaS) | 核心差异说明 |
|
||
| :-------------------------- | :------------------------------------------------------------- | :-------------------------------------------------------------- | :------------------------------------------------------------------ |
|
||
| **部署方式** | 🐳 **Docker 自托管**<br>需自行配置服务器环境 | ☁️ **开箱即用**<br>注册 API Key 即可调用 | 云版省去了复杂的环境搭建过程。 |
|
||
| **成本** | 🆓 **软件免费**<br>需支付服务器/带宽费用 | 💰 **订阅制**<br>按 Credits (页数) 计费，有免费额度 | 量大且有闲置服务器时开源版更省钱；量小或追求稳定时云版更划算。 |
|
||
| **反爬虫绕过**<br>(Proxies) | ❌ **弱 / 需自行配置**<br>默认使用本机 IP，易被 Cloudflare 拦截 | ✅ **强 / 内置智能代理**<br>自动轮换 IP，擅长绕过 WAF 和人机验证 | **这是最大的区别。** 云版包含商业代理池成本，开源版需你自己买代理。 |
|
||
| **维护难度** | 🛠 **高**<br>需维护 Redis、队列、无头浏览器更新 | ☕ **零**<br>官方团队维护基础设施 | 开源版遇到浏览器崩溃或内存泄漏需自己修。 |
|
||
| **并发与性能** | ⚠️ **受限于硬件**<br>取决于你的服务器配置 | 🚀 **弹性扩容**<br>支持高并发，速度通常更快 | 云版对并行抓取做了优化。 |
|
||
| **JS 渲染** | ✅ **支持**<br>需配置 Playwright/Puppeteer | ✅ **支持**<br>默认优化，加载更稳定 | 两者核心引擎相同，但云版资源分配更合理。 |
|
||
| **数据隐私** | 🔒 **高 (本地化)**<br>数据不经过第三方服务器 | ☁️ **中**<br>数据需传输至 Firecrawl 服务器处理 | 对数据合规性要求极高的场景（如金融/医疗）首选开源版。 |
|
||
| **适用场景** | 极客折腾、内网抓取、低频低难度网站、数据极度敏感 | 商业项目、大规模抓取、高难度网站 (有反爬)、追求稳定性 | |
|
||
|
||
3. 自主研发爬虫
|
||
1. 反爬机制: 维基百科对IP有访问频率限制, 且有验证码, 需自行处理
|
||
2. 动态内容: 维基百科有很多动态内容, 如表格, 图片等, 需自行处理, 如使用Selenium等工具模拟浏览器行为
|
||
|
||
**Firecrawl方案和替代评估总结**
|
||
假设客户的产品需求是: 从不同的网站爬取文档制成知识库, 并且需要定期维护, 那么其实只有在爬取新的站点和维护旧的站点的时候会集中使用firecrawl的额度, 主要特点是**使用时间集中**且**使用时段内额度需求量很大**以及**优先要保证爬虫模块的稳定性**
|
||
因此最推荐的方案是: 定时采购额度, 但是考虑到常规的订阅只有按时间计费, 而客户的需求是**定期维护**, 而**按使用额度计费, 即企业协商订阅**的方案是最符合客户需求的.
|
||
|
||
| 类别 | 成本 | 困难 |
|
||
| --- | --- | --- |
|
||
| 闭源版 | 购买定制服务, 如果企业长期话成本可能几千? 按年也就一年左右的量够用了 | 用起来很顺手, 目前的接口返回值基本能满足开发需求 |
|
||
| 开源版 | 需要准备IP池之类的反爬机制, 需要为IP代理付费 | 配置和学习相关的运营维护 |
|
||
| 自主研发 | 除了研发的时间精力外, 也必需IP池的购买 | 高 |
|