Langchain-Chatchat自定义评分函数提升检索相关性

Langchain-Chatchat自定义评分函数提升检索相关性

在企业知识管理日益复杂的今天，一个常见的痛点浮现出来：员工明明知道公司内部有某份技术文档，却在搜索时屡屡碰壁。输入“交换机端口频繁断连怎么办”，返回的却是电源维护手册；提问“报销流程变更”，结果跳出三年前的旧制度文件。这种“看得见、摸不着”的信息孤岛问题，正在悄然吞噬组织效率。

这背后暴露的是传统向量检索的局限——仅靠余弦相似度匹配语义，难以应对真实场景中的多义词、上下文依赖和时效偏好。而解决方案，并非推倒重来，而是引入一层轻量但关键的“裁判机制”：自定义评分函数。它像一位懂业务的技术专家，在初步召回的结果中二次筛选，把真正相关的片段推到前面。

Langchain-Chatchat 作为当前最活跃的开源本地知识库问答系统之一，因其全链路私有化部署能力，成为金融、医疗、政企等领域构建智能问答系统的首选。然而，默认的向量检索策略往往只能解决60%~70%的问题。要突破瓶颈，必须深入其检索流程，植入更精细的相关性判断逻辑。

标准的 RAG（检索-增强生成）流程通常是这样的：用户提问 → 编码为向量 → 在 FAISS 或 Milvus 中查找 top-k 最近邻 → 拼接 context 输入 LLM 生成答案。这个过程高效，但也粗糙。尤其是当多个文档块与问题的向量距离相近时，排序的微小偏差可能导致最终回答质量天差地别。

于是我们引入“Retrieve & Rerank”架构。这不是什么新概念，Google 搜索引擎早已用类似机制对候选网页进行重排序。但在本地知识库场景下，这套方法的价值被重新放大：我们可以结合关键词命中、语义匹配、时间新鲜度、字段权重等多种信号，设计出贴合业务需求的综合打分模型。

具体怎么做？先从向量库中扩大召回范围，比如取出 top-50 而非 top-5 的候选片段。这样做是为了避免高相关性内容因嵌入模型的局部失真被提前过滤。然后，对每个候选块提取多维特征：

• 关键词重叠度：是否包含问题中的核心术语？例如，“端口”、“STP”、“光模块”等；
• 语义相似度：使用更高质量的 Sentence-BERT 模型单独计算问题与文本块的语义匹配程度，而非依赖原始向量库的粗略分数；
• 元数据加权：所属章节是否为“故障排查”？更新时间是否在最近半年内？这些都可以转化为加分项；
• 结构位置偏好：出现在标题附近或列表项中的内容，通常更具信息密度。

接下来是打分公式的艺术。以下是一个实战中验证有效的实现：

from typing import List, Dict from langchain.schema import Document import numpy as np from sentence_transformers import util import re def custom_scoring_function( question: str, candidates: List[Document], embedding_model, keyword_weight: float = 0.3, semantic_weight: float = 0.5, freshness_weight: float = 0.2, base_score_weight: float = 0.8 ) -> List[Document]: """ 自定义评分函数：融合关键词、语义、时间等多维度信号进行重排序 """ scored_docs = [] question_words = set(re.findall(r'\b[a-zA-Z]{3,}\b', question.lower())) q_embedding = embedding_model.encode(question, convert_to_tensor=True) for doc in candidates: score_components = { 'base_score': doc.metadata.get('score', 0.0), 'keyword_match': 0.0, 'semantic_similarity': 0.0, 'freshness': 0.0 } # 关键词匹配：基于词频交集归一化 content_words = set(re.findall(r'\b[a-zA-Z]{3,}\b', doc.page_content.lower())) if content_words and question_words: keyword_overlap = len(question_words & content_words) / len(question_words) score_components['keyword_match'] = min(keyword_overlap, 1.0) # 更精准的语义相似度（使用专用SBERT模型） c_embedding = embedding_model.encode(doc.page_content[:512], convert_to_tensor=True) sem_sim = util.cos_sim(q_embedding, c_embedding).item() score_components['semantic_similarity'] = sem_sim # 新鲜度处理：越接近当前时间得分越高 timestamp = doc.metadata.get('timestamp', 0) time_diff = max(1, (1700000000 - timestamp)) # 示例基准时间戳 score_components['freshness'] = 1 / (1 + np.log(time_diff)) # 加权融合（可调参） total_score = ( base_score_weight * score_components['base_score'] + keyword_weight * score_components['keyword_match'] + semantic_weight * score_components['semantic_similarity'] + freshness_weight * score_components['freshness'] ) doc.metadata['rerank_score'] = total_score doc.metadata['score_components'] = score_components scored_docs.append(doc) # 按综合得分降序排列 scored_docs.sort(key=lambda x: x.metadata['rerank_score'], reverse=True) return scored_docs

这段代码的关键在于灵活性。权重参数可以根据实际反馈动态调整。例如，在政策法规类知识库中，freshness_weight可以上调至 0.4，确保最新条款优先；而在历史档案查询场景，则可降低时间因子影响，突出语义匹配。

该函数可以无缝集成进 Langchain-Chatchat 的检索管道。只需在获取 retriever 后挂载处理层即可：

retriever = vectorstore.as_retriever(search_kwargs={"k": 50}) raw_results = retriever.get_relevant_documents(query) reranked_results = custom_scoring_function(query, raw_results, sbert_model) final_context = reranked_results[:5] # 精选 top-5

整个过程无需改动底层索引结构，属于低侵入式增强，非常适合渐进式优化。

说到系统架构，Langchain-Chatchat 的优势不仅在于功能完整，更在于其清晰的模块划分。整个流程涵盖文档加载、文本分割、向量化存储、检索生成与前端交互五大环节，且每一环都支持替换与扩展。比如你可以用UnstructuredLoader解析复杂 PDF 表格，选用text2vec-large-chinese这类专为中文优化的 embedding 模型，再搭配 ChatGLM 或 Qwen 等国产大模型完成生成。

更重要的是，所有处理均可在本地完成，彻底规避数据外泄风险。这一点对于敏感行业至关重要。相比商用 SaaS 平台动辄按 token 计费、数据上传云端的模式，Langchain-Chatchat 提供了一种真正可控、可审计的知识智能化路径。

在一个典型的企业部署中，系统架构如下所示：

+------------------+ +----------------------------+ | Web Frontend |<----->| Backend (FastAPI/Flask) | +------------------+ +--------------+-------------+ | +------------------v------------------+ | Retrieval Module | | - Load documents | | - Split text | | - Generate embeddings | | - Store in Vector DB (e.g., FAISS) | +------------------+------------------+ | +------------------v------------------+ | Custom Scoring & Re-ranking | | - Apply keyword/semantic scoring | | - Boost relevant chunks | +------------------+------------------+ | +------------------v------------------+ | LLM Generation (e.g., ChatGLM) | | - Prompt templating | | - Context injection | | - Answer synthesis | +-------------------------------------+

其中，“Custom Scoring & Re-ranking” 模块正是本文聚焦的核心所在。它承上启下，将原始检索结果转化为高质量上下文供给大模型。

以某企业的 IT 支持系统为例，员工提问：“服务器磁盘 I/O 延迟高如何处理？” 经过重排序后，系统优先返回了近期更新的《Linux 性能调优指南》中关于iostat分析和deadline调度器配置的段落，而不是泛泛而谈“检查硬盘连接”的老旧建议。这种精准响应的背后，正是关键词匹配（“I/O延迟”、“iostat”）、语义理解（“高负载下的读写瓶颈”）与时间权重共同作用的结果。

当然，任何优化都不是无代价的。重排序会增加几十到几百毫秒的延迟，尤其当候选集较大或使用重型模型计算语义相似度时。因此实践中需做好权衡：

• 初始召回数不宜过大，一般设置为最终输出数量的 3~5 倍即可；
• 对高频问题启用缓存机制，直接复用已有的重排结果；
• 使用轻量级 reranker 模型（如 BGE Ranker）替代通用 SBERT，进一步压缩耗时；
• 引入监控埋点，记录每次检索的各维度得分变化，便于后续分析调优。

另一个常被忽视的问题是过拟合。如果过度依赖关键词匹配，系统可能变成“关键词搜索引擎”，丧失语义理解能力。正确的做法是以语义为主导，其他信号作为辅助修正。例如，即使某个片段未完全命中关键词，只要语义高度相关，仍应给予较高排名。

长期来看，随着小型化 reranker 模型的发展，这类技术正朝着自动化、低延迟方向演进。未来甚至可能出现基于强化学习的动态评分策略，根据用户点击行为自动调整权重。但现阶段，一个设计良好的自定义评分函数，已经足以让企业的知识库问答系统实现质的飞跃。

这种高度集成的设计思路，正引领着智能知识管理系统向更可靠、更高效的方向演进。