企业官网建设流程全解析

1. 这不是背诵考试，而是技术表达能力的实战检验

“DocResearch 项目面试：把每个模块讲明白，而不是背术语”——这句话一出来，我就知道，又一位被“面试八股文”折磨过的同学在喊救命。最近三个月，我帮二十多位准备算法工程、RAG系统、文档智能方向岗位的同学做过模拟面试，其中超过七成卡在同一个地方：一提到BM25，张口就是“一种基于词频和逆文档频率的经典检索算法”；说到Pydantic，立刻切换成教科书腔调：“用于数据验证和设置管理的Python库”；轮到RRF，干脆直接报出公式：$ \text{RRF}(d) = \sum_{i=1}^{n} \frac{1}{k + \text{rank}_i(d)} $，然后等着面试官点头。结果呢？面试官没点头，反而问：“你刚才说的‘逆文档频率’，如果我把一个词从1000份文档里删掉500份，它的IDF值怎么变？变大还是变小？为什么？”——人当场愣住。

这根本不是考你记不记得定义，而是考你能不能把技术模块当做一个活的系统部件来理解、拆解、解释、调试。DocResearch不是一个玩具Demo，它是一个真实落地的文档研究辅助系统：支持PDF/Word/Markdown多格式解析，构建可检索的知识图谱，融合语义与关键词双路召回，最后用重排序机制输出精准结果。它的每个模块都不是孤立存在，而是像齿轮咬合一样相互依赖。比如，Pydantic不是用来“校验JSON”的摆设，它是整个pipeline的数据契约守门人——PDF解析器输出的chunk结构、BM25引擎接收的query字段、RRF融合时的score归一化范围，全靠Pydantic模型强制约束。你背了十遍“Pydantic支持类型注解和自动转换”，但如果你讲不清Field(default_factory=list)和Field(default=[])在多线程环境下的坑，就等于没真正用过它。

我见过最典型的失败案例，是一位985硕士，简历写着“精通RAG”，面试时能流畅画出Retrieval-Augmented Generation流程图，但当被要求现场手写一个BM25评分函数，并说明为什么对长文档要加长度惩罚（length normalization）时，他花了三分钟才写出基础公式，却完全说不清k1和b两个超参的实际物理意义——k1控制词频饱和度，b决定文档长度影响权重。这不是知识盲区，是缺乏工程视角下的技术具象化能力。DocResearch面试要的，是你能指着代码说：“这里我用Pydantic定义了DocumentChunk模型，因为下游BM25需要保证title、content、page_num三个字段必填且类型明确，否则空字符串传进去会导致TF计算为0，整个文档直接掉出Top-K”；是你能打开jupyter notebook，现场改一行BM25参数，演示b=0.75和b=0.2对法律条文这类长文本检索结果的影响差异；是你能画个简图，说明RRF为什么比简单加权平均更能缓解单一路召回的偏置问题——因为它对排名靠前的文档给予指数级更高的权重，天然抑制低质量但高频匹配的结果。

所以，别再整理“Pydantic十大特性”“BM25五大优点”这种PPT式笔记了。真正的准备，是从你本地跑起来的DocResearch demo出发，逐行读代码，搞懂每一处@validator为什么加在那里，每一条bm25.score()调用背后的数据流向，每一次rrf_fusion()执行时两个rank list是如何对齐、归一、加权的。这篇文章，就是带你用工程师的显微镜，把DocResearch的四个核心模块——文档解析与建模、关键词检索（BM25）、语义检索（隐含但必须理解）、重排序（RRF）——全部掰开、揉碎、泡透，让你下次面试时，开口第一句不是“BM25是一种……”，而是“我在DocResearch里用BM25解决的是短查询词在长文档中定位精准段落的问题，具体实现时，我把PDF解析后的chunk按200字滑动窗口切分，这样既保证语义连贯，又让BM25的TF计算落在合理粒度上……”

2. 模块拆解：从数据契约到检索逻辑的完整链路

2.1 文档建模层：Pydantic不是装饰品，是数据流的交通警察

很多人把Pydantic当成JSON校验工具，这是对它最大的误解。在DocResearch里，Pydantic是整个数据管道的强类型契约制定者和异常熔断器。它不只管输入输出，更管中间态——每一个模块交接时，数据必须符合约定，否则立刻报错，绝不让脏数据污染下游。

先看核心模型DocumentChunk：

from pydantic import BaseModel, Field, validator from typing import List, Optional import re class DocumentChunk(BaseModel): id: str = Field(..., description="唯一标识，通常为doc_id+page_num+chunk_idx") doc_id: str = Field(..., description="原始文档ID") title: str = Field(..., min_length=1, max_length=200) content: str = Field(..., min_length=10, max_length=2000) page_num: int = Field(..., ge=0) chunk_index: int = Field(..., ge=0) metadata: dict = Field(default_factory=dict) @validator('content') def clean_content(cls, v): # 强制清洗：去多余空格、换行、不可见字符 v = re.sub(r'\s+', ' ', v.strip()) if len(v) < 10: raise ValueError("content too short after cleaning") return v @validator('id') def validate_id_format(cls, v): if not re.match(r'^[a-z0-9_-]+$', v): raise ValueError("id must contain only lowercase letters, digits, underscore, hyphen") return v

这个模型远不止“定义字段”那么简单。注意三个关键设计点：

1. min_length/max_length是业务规则，不是技术限制：content要求至少10字符，是因为BM25对极短文本（如“第1条”）计算TF会失真；上限2000是防止PDF解析错误导致单chunk塞入整篇论文。这直接决定了后续检索的粒度合理性。

2. @validator是防御性编程的核心：clean_content不只是美化字符串，它解决了PDF解析器（如pymupdf）常见的“空格爆炸”问题——扫描件OCR后，一个词可能被识别成“法 律 条 文”，中间全是空格。不清洗，BM25的len(content.split())就会虚高，TF计算错误。而validate_id_format则杜绝了后续Elasticsearch或向量库因ID含特殊字符导致的索引失败。

3. default_factory=dict而非default={}：这是Python新手必踩的坑。default={}是可变默认参数，所有实例共享同一个dict对象，多线程下会引发数据污染。default_factory=dict每次新建实例都生成新字典，安全可靠。我在实际压测中，曾因这个错误导致metadata字段在并发插入时互相覆盖，最终召回结果错乱。

再看SearchQuery模型，它定义了用户输入的契约：

class SearchQuery(BaseModel): text: str = Field(..., min_length=2, max_length=500) filters: dict = Field(default_factory=dict) top_k: int = Field(5, ge=1, le=100) @validator('text') def normalize_query_text(cls, v): # 统一转小写，去首尾空格，但保留内部空格（BM25需要） v = v.strip().lower() if not v: raise ValueError("query text cannot be empty after normalization") return v

这里normalize_query_text的处理非常关键。BM25本身不区分大小写，但如果你的文档chunk是大写存储的，而query是小写，直接匹配就会失败。所以统一小写是必须的预处理。但注意：不能去掉内部空格！因为BM25是词项匹配，"machine learning"和"machinelearning"是完全不同的term。很多同学在这里犯错，用re.sub(r'\s+', '', v)把空格全干掉，结果BM25永远找不到结果。

提示：Pydantic模型的.dict()方法返回标准dict，但.json()返回字符串。在FastAPI接口中，return query.dict()是常规操作；但在向量库插入时，如果需要JSON序列化，务必用.json()并指定exclude_unset=True，避免把None值也塞进去污染schema。

实操心得：我在搭建DocResearch时，曾把DocumentChunk的page_num字段从int改成Optional[int]，以为PDF扫描件可能没有页码。结果第二天，BM25的chunk_index排序逻辑就崩了——因为page_num为None时，sorted(chunks, key=lambda x: (x.page_num, x.chunk_index))会抛TypeError。最后解决方案是：所有用于排序、分组、聚合的字段，必须是non-optional。page_num改为page_num: int = Field(default=0)，并在解析器里强制赋默认值。这就是Pydantic强制你思考数据完整性的地方——它逼你面对现实世界的脏数据，而不是假装它们不存在。

2.2 关键词检索层：BM25不是黑箱，是可调校的精密仪器

BM25常被当作“传统检索算法”一笔带过，但在DocResearch里，它是对抗语义漂移的第一道防线。它的价值不在于多先进，而在于稳定、可控、可解释。当你搜索“劳动合同解除条件”，BM25能精准命中《劳动合同法》第三十六条至第四十条的原文段落，而纯向量检索可能把“员工离职流程”“社保停缴时间”这些相关但不精确的内容排在前面。

BM25核心公式是： $$ \text{score}(Q,d) = \sum_{i=1}^{n} \text{IDF}(q_i) \cdot \frac{\text{TF}(q_i,d) \cdot (k_1 + 1)}{\text{TF}(q_i,d) + k_1 \cdot (1 - b + b \cdot \frac{|d|}{\text{avgdl}})} $$

但面试时，光写公式没用。你需要讲清楚每个参数在DocResearch中的实际取值依据和调优过程。

• k1（词频饱和度参数）：DocResearch中设为1.5。为什么不是2.0或0.5？因为我们的chunk平均长度约300字，k1越大，词频增长越平缓。设1.5意味着：一个词在chunk中出现3次，其TF贡献约为最大值的85%；出现5次，贡献约94%。这防止了“合同”一词在某段落重复出现20次就霸榜，压制了其他关键term。实测中，k1=2.0时，法律条文类文档的召回多样性下降12%。

• b（长度归一化参数）：设为0.75。avgdl（平均文档长度）我们取所有chunk的中位数，约280字。b=0.75意味着文档长度对分数的影响权重很高。为什么？因为PDF解析后的chunk长度差异极大：有的是标题（20字），有的是整页扫描（800字）。不加长度惩罚，长chunk天然得分高，导致短小精悍的法条摘要被淹没。b=0.75让一个800字chunk的长度惩罚系数达到1 - 0.75 + 0.75*(800/280) ≈ 2.14，有效抑制其优势。

• IDF计算方式：不是简单log(N/df)，而是log((N - df + 0.5) / (df + 0.5))（Smooth IDF）。这是为了防止df=0时log无穷大，也避免df=N时IDF=0。在DocResearch的语料中，像“的”“和”这类停用词df接近总chunk数，Smooth IDF给它们极小正值（如0.001），而非0，确保BM25仍能计算，只是贡献微乎其微。

BM25的实现不是调包完事。DocResearch自研了一个轻量级BM25Scorer类，关键代码如下：

class BM25Scorer: def __init__(self, corpus: List[DocumentChunk], k1=1.5, b=0.75): self.k1 = k1 self.b = b self.corpus = corpus self.N = len(corpus) # 预计算每个term的df和avgdl self.avgdl = sum(len(c.content.split()) for c in corpus) / self.N self.df_cache = self._build_df_cache() def _build_df_cache(self): # 构建term -> document frequency映射 df_dict = defaultdict(int) for chunk in self.corpus: terms = chunk.content.lower().split() # 去停用词（简单版） terms = [t for t in terms if t not in STOP_WORDS] for term in set(terms): # set去重，df统计文档频次，非词频 df_dict[term] += 1 return df_dict def score(self, query: str, chunk: DocumentChunk) -> float: score = 0.0 query_terms = query.lower().split() doc_len = len(chunk.content.split()) for term in query_terms: if term not in self.df_cache: continue df = self.df_cache[term] idf = math.log((self.N - df + 0.5) / (df + 0.5)) # 计算该term在chunk中的tf tf = chunk.content.lower().count(term) # 简单子串计数，实际用空格分词更准 # BM25核心计算 numerator = tf * (self.k1 + 1) denominator = tf + self.k1 * (1 - self.b + self.b * doc_len / self.avgdl) score += idf * (numerator / denominator) if denominator != 0 else 0 return score

注意几个细节：

• _build_df_cache()用set(terms)统计df：df是包含该term的文档数，不是term出现总次数。用set确保每个chunk对df只贡献1次，这是正确实现的关键。

• score()中tf用count()而非分词后count()：这是权衡。精确分词（如jieba）更准，但增加依赖和延迟。content.lower().count(term)对英文效果好，对中文有歧义（如“合同”在“劳动合同”中会被重复计数），所以在DocResearch中，我们对中文语料额外做了n-gram扩展（bigram），把“劳动”“合同”“劳动合同”都作为独立term索引，弥补了简单count的不足。

• denominator的零检查：虽然数学上denominator不会为零，但浮点计算可能产生极小值，加个保护更稳妥。

常见问题：为什么不用Elasticsearch内置BM25？答案很实在：Elasticsearch的BM25是针对全文档设计的，而DocResearch的chunk粒度更细，且需要与向量检索结果做RRF融合，必须自己掌控score的绝对数值范围。ES返回的score是归一化的相对值，无法与向量相似度直接比较。自己实现，才能保证BM25 score在0~100区间，向量相似度也在0~100，RRF融合时才有可比性。

2.3 语义检索层：虽未明说，却是RRF融合的前提

DocResearch标题没提向量检索，但RRF（Reciprocal Rank Fusion）的存在，本身就暗示了双路召回架构：一路是BM25关键词检索，另一路必然是语义检索（如Sentence-BERT、Cohere Embed等）。RRF的作用，就是把这两路独立排序的结果，融合成一个更鲁棒的最终排序。

语义检索模块在面试中常被忽略，但它决定了DocResearch的上限。BM25擅长精确匹配，但对同义词、缩写、概念泛化无能为力。比如搜“工伤认定”，BM25可能错过“因工负伤鉴定”这段文字，而语义检索能捕捉到“工伤”和“因工负伤”的语义相似性。

DocResearch采用all-MiniLM-L6-v2模型（384维），部署在本地CPU上。选择理由很务实：

• 速度：单次embedding耗时<100ms（Intel i7），满足实时交互；
• 内存：模型仅80MB，不占用GPU资源；
• 效果：在法律文书相似度任务上，与all-mpnet-base-v2（512维）相比，准确率仅低3%，但速度提升3倍。

语义检索的SearchResult模型需与BM25对齐：

class SemanticResult(BaseModel): chunk_id: str similarity_score: float = Field(..., ge=0.0, le=1.0) # 归一化到0~1 rank: int = Field(..., ge=1)

关键点在于similarity_score必须归一化。原始cosine similarity范围是[-1,1]，但负值无意义（语义距离不可能负），所以我们用max(0, cosine_sim)，再线性映射到[0,1]。这确保了RRF公式中，两路score的数值尺度一致。

注意：语义检索的chunk embedding不是对原始content直接encode，而是对title + " | " + content拼接后encode。实测表明，加入title能显著提升法律条文的区分度——“劳动合同法第三十九条”和“劳动合同法第四十条”内容相似度高，但title不同，拼接后embedding距离拉大，召回更精准。

2.4 重排序层：RRF不是魔法，是排名共识的量化表达

RRF（Reciprocal Rank Fusion）是DocResearch的点睛之笔。它不改变单个检索器的内部逻辑，而是站在更高维度，用“排名一致性”来判断结果质量。公式很简单： $$ \text{RRF Score}(d) = \sum_{i=1}^{n} \frac{1}{k + \text{rank}_i(d)} $$ 其中k是常数（通常设为60），rank_i(d)是文档d在第i个检索器结果中的排名（从1开始）。

为什么RRF比简单加权平均（Weighted Sum）更优？举个真实例子：
用户搜“竞业限制补偿金标准”。

• BM25召回：
  1. 《劳动合同法》第二十三条（竞业限制条款）
  2. 《最高人民法院关于审理劳动争议案件司法解释（四）》第六条（补偿金标准）
  3. 某公司员工手册（内部规定）
• 语义检索召回：
  1. 《最高人民法院关于审理劳动争议案件司法解释（四）》第六条（补偿金标准）
  2. 《劳动合同法》第二十四条（竞业限制范围）
  3. 某地方法院判例（提及补偿金）

加权平均：假设BM25给第1条打分95，语义给第1条打分80，则第1条总分=0.595 + 0.580 = 87.5；第2条BM25分88，语义分92，总分90。结果第2条排第一——但第2条才是用户真正要找的“标准”！
RRF：第1条在BM25排1，在语义排2 → RRF=1/(60+1) + 1/(60+2) ≈ 0.0164 + 0.0161 = 0.0325；第2条在BM25排2，在语义排1 → RRF=1/(60+2) + 1/(60+1) = 同样0.0325。等等，一样？不，RRF的魔力在于对排名靠前的文档给予指数级更高权重。当k=60时，第1名贡献≈0.0164，第2名≈0.0161，差距微小；但第10名贡献仅≈0.0145，第100名≈0.0099。所以，真正拉开差距的是同时出现在两路Top-10的文档。第2条在两路都是Top-2，RRF稳居第一；而第1条在语义排第2，但第3条在语义排第100，RRF几乎为0，自然被淘汰。

DocResearch的RRF实现极其简洁：

def rrf_fusion(bm25_results: List[BM25Result], semantic_results: List[SemanticResult], k: int = 60) -> List[Tuple[str, float]]: # 构建id -> rank映射 bm25_rank = {r.chunk_id: i+1 for i, r in enumerate(bm25_results)} semantic_rank = {r.chunk_id: i+1 for i, r in enumerate(semantic_results)} # 合并所有出现过的chunk_id all_ids = set(bm25_rank.keys()) | set(semantic_rank.keys()) scores = {} for chunk_id in all_ids: score = 0.0 if chunk_id in bm25_rank: score += 1.0 / (k + bm25_rank[chunk_id]) if chunk_id in semantic_rank: score += 1.0 / (k + semantic_rank[chunk_id]) scores[chunk_id] = score # 按RRF score降序排列 return sorted(scores.items(), key=lambda x: x[1], reverse=True)

这里有个易错点：bm25_results和semantic_results的长度可能不同（如BM25返回50条，语义返回30条）。RRF天然兼容——没出现的文档，对应项为0。所以不必强行截断到相同长度，这是RRF鲁棒性的体现。

实操心得：k值的选择是经验性的。k=60是经典值，但我们在法律语料上测试发现，k=40时Top-5的准确率提升2.3%，因为法律文档专业性强，两路召回Top-10的重合度本就高，降低k让排名靠前的权重差异更明显。但k不能太小（如k=10），否则第1名和第2名的RRF分差过大（1/11 vs 1/12），导致结果过于集中，牺牲了多样性。最终选定k=40，并在配置文件中注释：“法律垂直领域调优值，通用领域建议保持60”。

3. 实操复现：从零搭建可面试演示的DocResearch最小可行版

3.1 环境准备与依赖安装：避开Python环境的十大陷阱

面试官最常问：“你本地跑起来了吗？” 如果回答“还没，等面试前装”，基本就凉了。DocResearch的最小可行版（MVP）只需5个核心依赖，但安装过程暗藏玄机。我帮你踩过所有坑，列出最稳路径。

第一步：Python版本锁定
必须用Python 3.9。为什么不是3.10或3.11？因为pymupdf（PDF解析主力）在3.10+上对ARM芯片（Mac M1/M2）支持不稳定，fitz模块常报ImportError: dlopen(...) image not found。3.9是目前最平衡的选择——兼容性好，性能足够。下载地址：https://www.python.org/downloads/release/python-3913/ （选macOS 64-bit Intel/Apple Silicon Universal2 installer）。

第二步：pip源与权限
国内必须换清华源，否则pip install pymupdf可能卡死：

pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple/

安装时绝对不要加sudo！用sudo pip install会污染系统Python，后续vscode调试、virtualenv都会出问题。正确姿势是：

# 创建专属虚拟环境（名称必须含docresearch，方便面试时展示） python3.9 -m venv docresearch-env source docresearch-env/bin/activate # Mac/Linux # docresearch-env\Scripts\activate.bat # Windows

第三步：依赖安装顺序与避坑指南
按此顺序执行，避免依赖冲突：

# 1. 先装Pydantic（基础契约） pip install pydantic==1.10.12 # 为什么不是2.x？因为DocResearch用的是v1 API（BaseModel, Field），v2语法不兼容。 # 且1.10.12是最后一个支持Python 3.9的v1稳定版。 # 2. 再装PDF解析器（重量级依赖） pip install PyMuPDF==1.19.6 # 版本必须锁定！1.20+在M1芯片上崩溃，1.19.6是黄金版本。 # 安装后立即验证： python -c "import fitz; print(fitz.__version__)" # 应输出1.19.6 # 3. 安装BM25所需（轻量） pip install scikit-learn==1.1.3 # 不要用1.2+，API有breaking change pip install numpy==1.23.5 # sklearn 1.1.3的配套numpy # 4. 安装语义模型（核心） pip install sentence-transformers==2.2.2 # 2.2.2是最后一个支持all-MiniLM-L6-v2且无CUDA依赖的版本。 # 安装后测试加载： python -c "from sentence_transformers import SentenceTransformer; m = SentenceTransformer('all-MiniLM-L6-v2'); print('OK')" # 首次运行会下载80MB模型，耐心等待。 # 5. 最后装Web框架（可选，但推荐） pip install fastapi==0.104.1 uvicorn==0.23.2

提示：sentence-transformers安装时，如果遇到torch冲突，用pip install torch==1.13.1+cpu -f https://download.pytorch.org/whl/torch_stable.html单独装CPU版。千万别装CUDA版——面试演示不需要GPU，装了反而增加启动失败风险。

常见问题速查表：

3.2 核心代码实现：三步构建可演示的检索流水线

现在，用不到100行代码，搭出DocResearch MVP。重点不是功能多全，而是每个模块都可现场讲解、可修改、可验证。

Step 1：文档加载与Pydantic建模（loader.py）
创建documents/目录，放入一份《劳动合同法》PDF。代码：

# loader.py from pathlib import Path import fitz from pydantic import BaseModel, Field from typing import List class DocumentChunk(BaseModel): id: str doc_id: str title: str content: str page_num: int chunk_index: int def load_pdf_as_chunks(pdf_path: str, chunk_size: int = 200, overlap: int = 50) -> List[DocumentChunk]: doc = fitz.open(pdf_path) chunks = [] doc_id = Path(pdf_path).stem for page_num in range(len(doc)): page = doc[page_num] text = page.get_text() if not text.strip(): continue # 按句子切分，避免在单词中间切断 sentences = [s.strip() for s in text.split('。') if s.strip()] current_chunk = "" for sent in sentences: if len(current_chunk) + len(sent) <= chunk_size: current_chunk += sent + "。" else: if current_chunk: chunks.append(DocumentChunk( id=f"{doc_id}_{page_num}_{len(chunks)}", doc_id=doc_id, title=f"第{page_num+1}页", content=current_chunk, page_num=page_num, chunk_index=len(chunks) )) current_chunk = sent + "。" # 处理最后一块 if current_chunk: chunks.append(DocumentChunk( id=f"{doc_id}_{page_num}_{len(chunks)}", doc_id=doc_id, title=f"第{page_num+1}页", content=current_chunk, page_num=page_num, chunk_index=len(chunks) )) return chunks # 测试加载 if __name__ == "__main__": chunks = load_pdf_as_chunks("documents/劳动合同法.pdf") print(f"Loaded {len(chunks)} chunks. First chunk ID: {chunks[0].id}")

运行python loader.py，应输出chunk数量和首个ID。这就是你的数据基石——所有后续模块都基于这个Pydantic列表工作。

Step 2：BM25检索器（bm25.py）
紧接上一步，实现可调参的BM25：

# bm25.py import math from typing import List, Tuple from loader import DocumentChunk class BM25Scorer: def __init__(self, corpus: List[DocumentChunk], k1=1.5, b=0.75): self.k1 = k1 self.b = b self.corpus = corpus self.N = len(corpus) self.avgdl = sum(len(c.content.split()) for c in corpus) / self.N self.df_cache = self._build_df_cache() def _build_df_cache(self): from collections import defaultdict df_dict = defaultdict(int) for chunk in self.corpus: terms = chunk.content.lower().split() for term in set(terms): df_dict[term] += 1 return df_dict def score(self, query: str, chunk: DocumentChunk) -> float: score = 0.0 query_terms = query.lower().split() doc_len = len(chunk.content.split()) for term in query_terms: if term not in self.df_cache: continue df = self.df_cache[term] idf = math.log((self.N - df + 0.5) / (df + 0.5)) tf = chunk.content.lower().count(term) numerator = tf * (self.k1 + 1) denominator = tf + self.k1 * (1 - self.b + self.b * doc_len / self.avgdl) score += idf * (numerator / denominator) if denominator != 0 else 0 return score def search(self, query: str, top_k: int = 5) -> List[Tuple[str, float]]: scores = [(chunk.id, self.score(query, chunk)) for chunk in self.corpus] return sorted(scores, key=lambda x: x[1], reverse=True)[:top_k] # 测试BM25 if __name__ == "__main__": from loader import load_pdf_as_chunks chunks = load_pdf_as_chunks("documents/劳动合同法.pdf") scorer = BM25Scorer(chunks) results = scorer.search("劳动合同解除", top_k=3) print("BM25 Results:", results)

运行python bm25.py，你会看到类似[('劳动合同法_1_0', 12.34), ('劳动合同法_2_1', 9.87), ...]的输出。这就是你可以现场修改的BM25——把k1改成2.0再运行，分数会变，你能立刻解释为什么。

Step 3：RRF融合与主流程（main.py）
整合所有模块：

# main.py from bm25 import BM25Scorer from loader import load_pdf_as_chunks from sentence_transformers import SentenceTransformer import numpy as np from typing import List, Tuple # 加载文档 chunks = load_pdf_as_chunks("documents/劳动合同法.pdf") # 初始化BM25 bm25_scorer = BM25Scorer(chunks) # 初始化语义模型（首次运行会下载） model = SentenceTransformer('all-MiniLM-L6-v2') # 预计算所有chunk的embedding（面试演示时可注释掉，现场计算更真实） # chunk_embeddings = model.encode([c.title + " | " + c.content for c in chunks]) def semantic_search(query: str, top_k: int = 5) -> List[Tuple[str, float]]: # 现场计算，展示真实延迟 query_embedding = model.encode([query])[0] # 简化：用余弦相似度，不优化 scores = [] for i, chunk in enumerate(ch