wiki_crawler

本仓库主要用于存放wiki_crawler的代码

核心依赖 firecrawl 和 阿里百炼 的api支持

完成wiki网页爬取和向量化与知识库查找

当前状况

1. chunk分段逻辑：根据返回的markdown进行分割，按照#、##进行标题的分类，增加JSONB格式字段meta_info，有下面两个字段，分别可以用于数据库查询和LLM上下文认知资料来源

   # 源数据 (headers)
   headers = {"h1": "产品介绍", "h2": "核心功能", "h3": "多语言支持"}
   
   # 生成数据 (header_path)
   # Python 代码逻辑: " > ".join(headers.values())
   header_path = "产品介绍 > 核心功能 > 多语言支持"
   

2. 量化指标以及测试：目前存入的数据较少，测试结果可能偏差较大

   "p_at_1": [],    # Precision@1: 首位精确率
   "hit_at_5": [],  # HitRate@5: 前5命中率，即返回的前五个（目前设置只返回5个）是否符合问题
   "mrr": [],       # Mean Reciprocal Rank: 倒数排名分数，正确答案排得越靠前，分数越高
   "latency": []    # 响应耗时
   

3. 搜索逻辑和问题分类：尚未实现，目前参考一些主流的做法，用户输入后先过一个LLM对问题进行拆分和分类，然后传入对应的知识库参数task_id进行对应的检索

4. RAG逻辑：混合检索，使用向量和关键词混合检索，此处进行粗筛，数据层返回后在业务层调用 gte-rerank 模型进行重排，最后返回请求

   vector_score = (1 - self.db.chunks.c.embedding.cosine_distance(query_vector))# 计算向量相似度
   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. 产品面向场景：客户需求爬取几个文档，并长期维护更新，后续需要新增，但是量相对不会太大，firecrawl付费大概不会太贵。爬虫获取完整wiki（可无视robots.txt），当前知识库存入和爬虫绑定强，依赖markdown格式存入

6. 后续开发：添加旧wiki的更新维护功能。dify增加对后端的封装，做一套搜索逻辑和问题分类的节点，如果不好弄那还是迁回到后端，后端只提供知识库的mcp，bot调用mcp之后，自行调用实现搜索和问题分类

对比其他检索方法的优势，做一套评测机制标准，评估最终LLM输出的准确度，目前是知识库检索准确度

切割逻辑，准确率定义，归结资料，测试设计，mcp服务调用，搜索逻辑，问题分类，流程架构设计，场景假设

整理dify报错，

包装mcp server