57 lines
2.9 KiB
Markdown
57 lines
2.9 KiB
Markdown
# wiki_crawler
|
||
|
||
本仓库主要用于存放wiki_crawler的代码
|
||
|
||
核心依赖 `firecrawl` 和 阿里百炼 的api支持
|
||
|
||
完成wiki网页爬取和向量化与知识库查找
|
||
|
||
mcp调试命令
|
||
|
||
```bash
|
||
npx @modelcontextprotocol/inspector uv run backend/mcp_server.py
|
||
```
|
||
|
||
需要nodejs环境
|
||
打开页面后在Environment Variables中添加`PYTHONIOENCODING = utf-8`来防止编码问题（视具体情况而定，如果可以正常运行，也可以不加）
|
||
|
||
## 当前状况
|
||
|
||
1. chunk分段逻辑：根据返回的markdown进行分割，按照#、##进行标题的分类，增加JSONB格式字段meta_info，有下面两个字段，分别可以用于数据库查询和LLM上下文认知资料来源
|
||
|
||
```python
|
||
# 源数据 (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 模型进行重排，最后返回请求
|
||
|
||
```python
|
||
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
|