编写未来计划表

README.md

@@ -26,7 +26,7 @@
    "mrr": [],       # Mean Reciprocal Rank: 倒数排名分数，正确答案排得越靠前，分数越高
    "latency": []    # 响应耗时
    ```
-3. 搜索逻辑和问题分类：目前参考一些主流的做法，用户输入后先过一个LLM对问题进行拆分和分类，然后传入对应的知识库参数task_id进行对应的检索
+3. 搜索逻辑和问题分类：尚未实现，目前参考一些主流的做法，用户输入后先过一个LLM对问题进行拆分和分类，然后传入对应的知识库参数task_id进行对应的检索
 4. RAG逻辑：混合检索，使用向量和关键词混合检索，此处进行粗筛，数据层返回后在业务层调用 gte-rerank 模型进行重排，最后返回请求
 
    ```python
@@ -34,8 +34,10 @@
    keyword_score = func.ts_rank(self.db.chunks.c.content_tsvector, keyword_query) # 计算关键词相似度
    final_score = (vector_score * 0.7 + func.coalesce(keyword_score, 0) * 0.3).label("score")# 计算最终分数
    ```
-5. 产品面向：爬虫获取完整wiki（可无视robots.txt），当前知识库存入和爬虫绑定强，依赖markdown格式存入
+5. 产品面向场景：客户需求爬取几个文档，并长期维护更新，后续需要新增，但是量相对不会太大，firecrawl付费大概不会太贵。爬虫获取完整wiki（可无视robots.txt），当前知识库存入和爬虫绑定强，依赖markdown格式存入
+6. 后续开发：添加旧wiki的更新维护功能。dify增加对后端的封装，做一套搜索逻辑和问题分类的节点，如果不好弄那还是迁回到后端，后端只提供知识库的mcp，bot调用mcp之后，自行调用实现搜索和问题分类
 
+对比其他检索方法的优势，做一套评测机制标准，评估最终LLM输出的准确度，目前是知识库检索准确度
 
 
 切割逻辑，准确率定义，归结资料，测试设计，mcp服务调用，搜索逻辑，问题分类，流程架构设计，场景假设

backend/core/config.py

@@ -5,6 +5,8 @@ class Settings(BaseSettings):
     系统配置类
     自动读取环境变量或 .env 文件
     """
+    CANDIDATE_NUM: int = 10
+
     DB_USER: str
     DB_PASS: str
     DB_HOST: str

backend/routers/v2.py

@@ -24,7 +24,7 @@ async def auto_process(req: AutoProcessRequest, bg_tasks: BackgroundTasks):
 @router.post("/search")
 async def search_smart(req: TextSearchRequest):
     try:
-        res = crawler_service.search(req.query, req.task_id, req.limit)
+        res = crawler_service.search(req.query, req.task_id, req.return_num)
         return make_response(1, res.pop("msg", "Success"), res)
     except Exception as e:
         return make_response(0, str(e))

backend/schemas/schemas.py

@@ -13,7 +13,6 @@ class AddUrlsRequest(BaseModel):
     task_id: int
     urls_obj: dict
 
-# schemas.py
 class CrawlResult(BaseModel):
     source_url: str
     chunk_index: int  # 新增字段
@@ -31,11 +30,6 @@ class SearchRequest(BaseModel):
     query_embedding: dict
     limit: Optional[int] = 5
 
-
-
-
-# ... (保留原有的 Schema: RegisterRequest, AddUrlsRequest 等) ...
-
 # === V2 New Schemas ===
 class AutoMapRequest(BaseModel):
     url: str
@@ -47,4 +41,4 @@ class AutoProcessRequest(BaseModel):
 class TextSearchRequest(BaseModel):
     query: str  # 用户直接传文字，不需要传向量了
     task_id: Optional[int] = None
-    limit: Optional[int] = 5
+    return_num: Optional[int] = 5

backend/services/crawler_service.py

@@ -152,7 +152,7 @@ class CrawlerService:
 
         # 2. 计算粗排召回数量
         # 逻辑：至少召回 50 个，如果用户要很多，则召回 10 倍
-        coarse_limit = return_num * 10 if return_num * 10 > 50 else 50
+        coarse_limit = return_num * 10 if return_num * 10 > settings.CANDIDATE_NUM else settings.CANDIDATE_NUM
         
         # 3. 执行混合检索 (粗排)
         coarse_results = data_service.search(

docs/开发计划.md

@@ -0,0 +1,62 @@
+# 下一步开发计划
+
+## 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池的购买 | 高 |