Update WeKnora.md

docs/WeKnora.md

@@ -92,7 +92,7 @@ WeKnora 处理文档需要多个步骤：插入-》知识提取-》索引-》检
 这个日志完整地记录了一次典型的RAG流程：系统通过**问题改写**和**预处理**来精确理解用户意图，接着利用**向量与关键词混合检索**从知识库中找到相关信息，虽然跳过了**重排序**，但依然执行了**合并**与**过滤**，最后将检索到的知识作为上下文，交由大语言模型**生成**流畅、准确的回答，并通过**流式过滤**保证了输出的纯净性。
 
 ## 文档解析切分
-代码实现了一个独立的、通过gRPC通信的微服务，专门负责文档内容的深度解析、分块和多模态信息提取。它正是上一份日志分析中提到的“异步处理”阶段的核心执行者。
+代码实现了一个独立的、通过gRPC通信的微服务，专门负责文档内容的深度解析、分块和多模态信息提取。它正是“异步处理”阶段的核心执行者。
 
 ### **整体架构**
 这是一个基于Python的gRPC服务，其核心职责是接收文件（或URL），并将其解析成结构化的、可供后续处理（如向量化）的文本块（Chunks）。
@@ -106,7 +106,7 @@ WeKnora 处理文档需要多个步骤：插入-》知识提取-》索引-》检
 ### **详细工作流程**
 当Go后端启动异步任务时，它会携带文件内容和配置信息，向这个Python服务发起一次gRPC调用。以下是完整的处理流程：
 
-#### **第一步：请求接收与分发 (**`server.py`** & **`parser.py`**)**
+#### **第一步：请求接收与分发 (**`server.py`** & **`parser.py`**)
 1. **gRPC服务入口 (**`server.py: serve`**)**:
     - 服务通过`serve()`函数启动。它会根据环境变量（`GRPC_WORKER_PROCESSES`, `GRPC_MAX_WORKERS`）启动一个**多进程、多线程**的服务器，以充分利用CPU资源，提高并发处理能力。
     - 每个工作进程都监听在指定的端口（如50051），准备接收请求。
@@ -123,9 +123,9 @@ WeKnora 处理文档需要多个步骤：插入-》知识提取-》索引-》检
     - 找到后，它会**实例化**这个`PDFParser`类，并将`ChunkingConfig`等所有配置信息传递给构造函数。
 
 #### **第二步：核心解析与分块 (**`base_parser.py`**)**
-这是一个非常好的问题，它触及了整个流程的核心：**如何保证信息的上下文完整性和原始顺序**。
+它触及了整个流程的核心：**如何保证信息的上下文完整性和原始顺序**。
 
-是的，根据您提供的 `base_parser.py` 代码，**最终切分出的 Chunk 中的文本、表格和图像是按照它们在原始文档中的出现顺序来保存的**。
+根据 `base_parser.py` 代码，**最终切分出的 Chunk 中的文本、表格和图像是按照它们在原始文档中的出现顺序来保存的**。
 
 这个顺序得以保证，主要归功于 `BaseParser` 中几个设计精巧的方法相互协作。我们来详细追踪一下这个流程。
 
@@ -186,11 +186,9 @@ WeKnora 处理文档需要多个步骤：插入-》知识提取-》索引-》检
 至此，Go后端就拿到了结构化、信息丰富的文档数据，可以进行下一步的向量化和索引存储了。
 
 
-
 ## 部署
 支持Docker 镜像本地部署，并通过API端口提供接口服务
 
-
 ## 性能和监控
 Weknora包含丰富的监控和测试组件：
 
@@ -231,16 +229,16 @@ INFO [2025-08-29 09:46:37.257] [request_id=Lkq0OGLYu2fV] knowledgebase.go:266[Hy
 
 最终，系统将这两次搜索的结果进行去重和合并（日志中显示每次都找到2个结果，去重后总共还是2个），从而得到一个更可靠的知识集合，用于后续的答案生成。
 
----
+
 
 ### 问题2：重排序模型分析
-当然，这三种Reranker（重排器）是目前RAG领域中非常先进的技术，它们在工作原理和适用场景上有着显著的区别。
+Reranker（重排器）是目前RAG领域中非常先进的技术，它们在工作原理和适用场景上有着显著的区别。
 
 简单来说，它们代表了从“**专门的判别模型**”到“**利用大语言模型（LLM）进行判别**”再到“**深度挖掘LLM内部信息进行判别**”的演进。
 
 以下是它们的详细区别：
 
----
+
 
 #### 1. Normal Reranker (常规重排器 / 交叉编码器)
 这是最经典也是最主流的重排方法。
@@ -254,7 +252,7 @@ INFO [2025-08-29 09:46:37.257] [request_id=Lkq0OGLYu2fV] knowledgebase.go:266[Hy
     - **优点**: 由于查询和文档在模型内部进行了充分的、深度的交互，其**准确度通常非常高**，是衡量Reranker性能的黄金标准。
     - **缺点**: **速度较慢**。因为它必须为**每一个“查询-文档”对**都独立执行一次完整的、代价高昂的计算。如果初步检索返回了100个文档，它就需要运行100次。
 
----
+
 
 #### 2. LLM-based Reranker (基于LLM的重排器)
 这种方法创造性地利用了通用大语言模型（LLM）的能力来进行重排。
@@ -269,7 +267,7 @@ INFO [2025-08-29 09:46:37.257] [request_id=Lkq0OGLYu2fV] knowledgebase.go:266[Hy
     - **优点**: 能够利用LLM强大的**语义理解、推理和世界知识**，对于需要深度理解和推理才能判断相关性的复杂查询，效果可能更好。
     - **缺点**: 计算开销可能非常大（取决于LLM的大小），并且性能**高度依赖于Prompt的设计**。
 
----
+
 
 #### 3. LLM-based Layerwise Reranker (基于LLM分层信息的重排器)
 这是第二种方法的“威力加强版”，是一种更前沿、更复杂的探究性技术。
@@ -300,14 +298,11 @@ INFO [2025-08-29 09:46:37.257] [request_id=Lkq0OGLYu2fV] knowledgebase.go:266[Hy
 2. **进阶探索**: 如果您发现常规Reranker在处理某些非常微妙或需要复杂推理的查询时表现不佳，并且您拥有充足的GPU资源，可以尝试 `LLM-based Reranker`。
 3. **前沿研究**: `Layerwise Reranker` 更适合研究人员或希望在特定任务上压榨出最后一点性能的专家。
 
-在您的系统中，启用重排服务时，您只需要在配置中指定所选的模型ID，并确保您的环境（例如Ollama或类似服务）已经正确加载并运行了该模型。
 
 ### 问题3：粗过滤或细过滤后的知识（带重排）如何组装发送给大模型的？
 这一块主要是设计提示词，典型的指令细节，其核心任务是根据上下文回答用户问题。组装上下文时需要指定  
 关键约束：必须严格按照所提供文档回答，禁止使用你自己的知识回答
-
 未知情况处理： 如果文档中没有足够的信息来回答问题，请告知“根据所掌握的资料，无法回答这个问题”
-
 引用要求：在回答时，如果引用了某个文档内容，请在句子末尾加上文档编号