简介这是一份基于Python的新闻搜索引擎设计与实现的完整项目资料包面向具备Python编程基础、熟悉Web开发或数据库操作、对自然语言处理与信息检索感兴趣的研发人员、数据工程师及高校学生覆盖搜索后端开发全流程。资源为单个docx文档约118KB集中呈现从新闻采集、中文分词、倒排索引构建到BM25相关性排序、Web与桌面GUI展示的完整工程思路并配套程序代码、数据库设计及模块拆分说明。目前已有64人学习/浏览。通过学习可掌握爬虫反爬应对、文本清洗、索引构建和排序优化等关键环节理解垂直领域搜索系统的模块化架构并能在舆情监测、金融研究、媒体辅助等实际业务中迁移应用。文档目录按项目背景、系统架构、代码示例、应用领域等逐层展开结构清晰适合作为课程设计、毕业设计或技术进阶的参考资料。1. 为什么一个可解释的新闻搜索比“搜索引擎”更重要通用搜索引擎的排序是个黑盒输入关键词得到结果但你解释不了“为什么它排第一”。面向垂直领域的新闻搜索不一样必须能回溯每一步标题命中加了权重近期发布时间加了指数衰减BM25 的 b 参数对长文做了长度归一化。用 Python 实现的这个新闻搜索引擎把自然语言处理、信息检索和 MySQL 数据库三条线串进同一个体系requests 采集新闻jieba 完成中文分词倒排索引解决加速问题BM25 决定相关性排序FastAPI 提供检索接口前端用 Web 和 Tkinter 双落点。适合做舆情监控、行业研究或者想搞懂搜索系统内部机制的工程师。这个项目的价值不在“能搜到”而在“能说清怎么搜到的”。2. 数据与文本处理爬虫采集、中文分词与检索单元的确定搜索结果的上限由数据质量决定。排序模型再强拿到的也是清洗后的标题、正文、发布时间和来源。这一层的工作直接决定索引里有什么词项、每个文档多长、发布时间是否可信。下面从采集、解析到分词归一化把进入索引之前的工序走通。2.1 先入库还是先检索取决于数据量素材里同时给出了“在线抓取即时解析”和“先入库后索引”两条路径。我的经验是分阶段几百篇演示数据时直接抓完建索引代码直观上万篇且需要多次重启系统时必须把新闻原始字段先落 MySQL检索时再加载索引。这样爬虫崩溃不丢数据索引重建也不用重新抓网页。数据层设计上news 表只存新闻实体字段news_processed 表存分词结果index_term_doc 存倒排信息。表的拆分让加载和增量更新互不干扰。表名职责与检索的关系news新闻原始字段标题、正文、时间、来源结果展示时读取详情news_processed分词后的词项列表与字段标记索引构建的输入index_term_doc词项到文档及出现位置查询加速的主体search_log查询词、点击、时间调优与热门词分析2.2 反爬与页面结构变化的工程化解耦新闻网站改版很频繁按标签硬编码的选择器两三周就会失效。素材里强调的“模块化、配置驱动”设计可以拆成两层访问层统一管理请求频率和身份特征解析层为每个新闻源维护独立的抽取规则。下面这段代码把这两件事分开处理。import requests import random import time import re from bs4 import BeautifulSoup UA_POOL [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36, ] def fetch(url, sleep(0.5, 1.5)): 带随机UA和休眠的抓取避免高频请求被识别为脚本 session requests.Session() session.headers.update({User-Agent: random.choice(UA_POOL)}) resp session.get(url, timeout10) resp.encoding resp.apparent_encoding time.sleep(random.uniform(*sleep)) return resp.text def parse_news(html, rule): soup BeautifulSoup(html, lxml) # rule是每个新闻源的独立配置改版时只改配置不动代码 title_node soup.select_one(rule[title]) body_node soup.select_one(rule[body]) if body_node is None: # 降级策略取文本最长的div用于正文容器样式调整后的兜底 body_node max(soup.find_all(div), keylambda d: len(d.get_text()), defaultNone) return { title: title_node.get_text(stripTrue) if title_node else , body: body_node.get_text(\n, stripTrue) if body_node else , publish_time: extract_time(html), source: rule[source_name], } def extract_time(html): # 优先匹配微格式datetime属性再退回meta标签 m re.search(rdatetime([^]), html) if m: return m.group(1) m re.search( rmeta[^]propertyarticle:published_time[^]content([^]), html, ) return m.group(1) if m else None逻辑说明fetch 把 UA 随机、编码推断、请求间隔放在一起随机休眠区间比固定 1 秒更不容易形成访问特征parse_news 的入参 rule 是每个新闻源一组的抽取规则站点改版只改配置。正文解析失败时退到“文本最长的 div”是保底手段准确率不如规则命中但能保证数据链路不断。extract_time 先读微格式 datetime 属性再找 article:published_time 的 meta 标签这是新闻页里最主流的两种发布时间承载方式。注意很多新闻站点的发布时间藏在页面渲染后的 JS 变量里比如pubDate: 2025-03-01 10:30:00。这种情况可以再加一条正则兜底最终优先级顺序是规则选择器 → 微格式属性 → meta 标签 → 正则。2.3 jieba 分词、停用词与字段权重中文没有天然空格分隔jieba 的精确模式 cut_allFalse 适合索引构建词项少、索引体积稳定query 侧对长查询改用搜索引擎模式可以拆出更细的词项提高召回。import jieba import re STOP_WORDS set() with open(stopwords.txt, encodingutf-8) as f: STOP_WORDS {line.strip() for line in f if line.strip()} def tokenize(text, search_modeFalse): # 精确模式保证索引词项稳定search_modeTrue 时按搜索引擎模式细切 if search_mode: words jieba.cut_for_search(text) else: words jieba.cut(text, cut_allFalse) result [] for w in words: w w.strip().lower() if not w or w in STOP_WORDS: continue if re.fullmatch(r[\d\W_], w): continue result.append(w) return result def prepare_doc(news_item): # 标题和正文分别分词返回带字段标记的词项流 return { title_tokens: tokenize(news_item[title]), body_tokens: tokenize(news_item[body]), publish_time: news_item[publish_time], news_id: news_item[news_id], }参数说明停用词表按行读取常见做法是合并公开停用词表和自己从语料里统计的高频无义词正则[\d\W_]过滤纯数字和纯符号但做 lower 而不是直接去大写是为了保留 “ChatGPT”“iPhone” 这类含大小写的专有名词形态。prepare_doc 输出的标题词项和正文词项分开为第三章的字段加权做准备。2.4 重复新闻去重与字段权重定型同一新闻在不同平台互相转载很常见标题完全一致或高度相似的条目会同时进入索引污染排序结果。演示项目里可以先对标题做归一化去掉空格、去标点、数字统一格式再算 MD5 做精确去重。更严谨的做法是两两比较最长公共子串或计算 SimHash在十万级语料上可以按候选桶只对比同桶内的文档把 O(n²) 降下来。字段权重在这个阶段定下来比较合理标题词项权重设 2.8正文设为 1.0导语段文字段单独设 1.6。理由来自一个常见现象标题完整包含查询词的新闻用户点击率显著高于正文命中。后面 BM25 的最终得分会把这些权重直接乘进相关性里。这个值可以先写死再通过第五章的验证方法去调。3. 倒排索引与 BM25 排序从全表扫描到毫秒级检索没有倒排索引MySQL 的 LIKE %词% 在十万条新闻上就是几十秒级别的全表扫描有了倒排索引一次查询收敛到几个词项的 posting list 合并毫秒级返回。倒排索引解决的是“哪些文档包含这个词”BM25 解决的是“这些文档里谁更相关”两个环节缺一不可。3.1 索引落内存还是落 MySQL方案优点缺点适用量级内存 dict 结构查询快代码直观方便调试进程重启要重建单机百万级以下MySQL 的 index_term_doc 表持久化支持增量更新查询多一次 DB 往返分布式前的过渡Redis / 搜索中间件自带数据结构与持久化引入额外依赖高并发线上场景素材里同时设计了 index_term_doc 表结构和内存构建模块实际运行时先读表加载进内存查询只走 dict 结构。这个“表存、内存查”的组合是单机新闻搜索里性价比最高的形态既有持久化保障又不让数据库参与每次查询的热路径。3.2 倒排索引构建与候选集生成from collections import Counter, defaultdict class InvertedIndex: def __init__(self): self.postings defaultdict(dict) # 词项 - {doc_id: tf} self.df defaultdict(int) # 词项文档频率计算IDF用 self.doc_len {} # 文档总长度 self.total_docs 0 def add_doc(self, doc_id, field_tokens): # 标题和正文拼在一起统计TFdoc_len后续用于BM25长度归一化 merged field_tokens[title_tokens] field_tokens[body_tokens] counter Counter(merged) self.doc_len[doc_id] len(merged) for term, tf in counter.items(): # counter迭代时每个term唯一df自增就是文档频率 self.postings[term][doc_id] tf self.df[term] 1 self.total_docs 1 def build_from_processed(self, processed_rows): for row in processed_rows: self.add_doc(row[news_id], row) def query(self, terms): # 多词项取并集得到候选文档排序交给评分函数 candidates set() for term in terms: candidates.update(self.postings.get(term, {}).keys()) return candidates逻辑说明add_doc 里把标题和正文词项合并统计 TF同时记录文档长度这两个值 BM25 都要用。df 自增放在 counter 迭代里是安全的因为一个 term 在一个文档内即使出现多次counter.items() 也只迭代一次。query 阶段只做候选集收集不做过滤这保证召回不会因为某个词项过于激进而被误杀。3.3 BM25 公式与 k1、b 参数的物理含义BM25 对 TF-IDF 的核心改进是两条曲线TF 不再线性增长而是被 k1 压缩到渐近线文档长度归一化由 b 控制。b0 时完全忽略文档长度b1 时完全按平均长度归一。新闻场景里短标题命中比长正文堆词更有价值所以 b 初始取 0.75k1 取 1.2 到 1.5 之间比较稳妥。import math def bm25(query_terms, doc_id, index, avg_doc_len, k11.5, b0.75): score 0.0 dl index.doc_len.get(doc_id, 0) if dl 0: return 0.0 N index.total_docs for term in query_terms: postings index.postings.get(term, {}) tf postings.get(doc_id, 0) if tf 0: continue df len(postings) # postings的长度就是含该词项的文档数 idf math.log(1.0 (N - df 0.5) / (df 0.5)) tf_part tf * (k1 1.0) / (tf k1 * (1.0 - b b * dl / avg_doc_len)) score idf * tf_part return score参数说明IDF 公式里加了 1避免高频词的 IDF 变成负值反过来扣分tf_part 分母中的dl / avg_doc_len就是长度归一化长文档的 TF 会被压低。k1 越大TF 增长曲线的衰减越慢短查询对头部高 TF 文档更敏感b 越大长文档惩罚越强。调参时要固定一个扫另一个用第五章的评估指标取舍而不是直接改到某一组经验值上。3.4 字段权重与时间衰减的融合排序新闻和普通文档最大的差异是时间敏感。排序公式在 BM25 得分基础上乘两个因子字段权重和发布时间的指数衰减。新闻阅读场景里半衰期取 7 天作为默认值意味着 7 天前发布的新闻时间项权重衰减到一半。from datetime import datetime def rank_news(query_terms, candidates, index, meta, avg_doc_len, half_life7.0): results [] for doc_id in candidates: base bm25(query_terms, doc_id, index, avg_doc_len) if base 0: continue # meta里保存标题词项集合与publish_time构建索引时注入 title_set meta[doc_id][title_set] title_hits sum(1 for t in query_terms if t in title_set) field_boost 1.0 1.8 * title_hits # 标题命中一次乘以2.8没有命中不惩罚 age_days (datetime.now() - meta[doc_id][publish_time]).days time_decay math.exp(-age_days / half_life) final base * field_boost * (0.5 0.5 * time_decay) results.append((doc_id, final)) results.sort(keylambda x: x[1], reverseTrue) return results逻辑说明field_boost 直接统计标题命中词项的个数让标题完整包含查询词的新闻优先时间衰减被压缩到 [0.5, 1.0] 区间即使是很久以前的强相关新闻也不会被彻底压出首页。最终得分是乘法组合调参时不要单独放大时间项否则强相关的老新闻会集体跌出前 20新闻搜索的“相关第一、时间第二”原则就被破坏了。4. FastAPI 检索服务与两种前端落点后端把索引和排序封装成服务前端只消费接口。API 设计、查询解析和前端实现在这里端到端串起来。Web 页面适合日常查询Tkinter 客户端适合内网调试和演示环境两者共用同一套检索服务。4.1 API 接口约定接口方法参数返回/api/searchGETq, limit, page新闻 id 列表、得分、摘要/api/news/{news_id}GET路径参数新闻完整字段/api/suggestGETprefix补全候选词/api/hot_queriesGETtop_n高频搜索词/api/auth/loginPOSTusername, password访问 token/api/admin/search_logsGETpage搜索日志分页4.2 查询解析与搜索接口实现查询侧需要做一次轻量解析普通关键词走全词匹配带引号的短语要求词项按顺序出现前缀site:或from:可以限定来源。素材里的实现聚焦前两种代码保持精简后续要扩展解析规则时再抽独立的解析函数。from fastapi import FastAPI, Query, HTTPException app FastAPI() class SearchEngine: 组合InvertedIndex与meta数据启动时加载查询时只读 def __init__(self): self.index None self.meta {} def rank(self, query_terms, candidates): # 细节见 rank_news 实现这里做封装 return rank_news(query_terms, candidates, self.index, self.meta, self.avg_doc_len) engine SearchEngine() app.get(/api/search) def search_api(q: str Query(..., min_length1), limit: int 10, page: int 1): query_terms tokenize(q, search_modeTrue) if not query_terms: raise HTTPException(status_code400, detail查询词全部被停用词过滤) candidates engine.index.query(query_terms) ranked engine.rank(query_terms, candidates) start (page - 1) * limit page_items ranked[start:start limit] return { total: len(ranked), page: page, items: [item_to_dict(doc_id, score, query_terms) for doc_id, score in page_items], } def make_summary(meta, query_terms): body meta[body] pos -1 for t in query_terms: p body.find(t) if p ! -1: pos p break if pos -1: return body[:120] return body[max(0, pos - 40): pos 80] ...参数说明tokenize 开启 search_mode让“人工智能监管政策”这样的长查询拆出多个候选词提高召回。make_summary 用第一个命中的词项定位正文窗口这比固定截取前 120 字更贴近查询意图。total 字段保留全量命中数前端翻页时用。4.3 Web 前端与 AJAX 异步调用Web 端用 FastAPI 自带的 Jinja2 模板渲染搜索首页查询动作通过 AJAX 请求 /api/search避免整页刷新。部署时不引入前端工程化工具链直接启动 uvicorn 就能跑。核心结构是一个输入框、一个结果列表容器fetch 拿到 JSON 后渲染。素材里的完整项目还包含 Tkinter 客户端适合在没有浏览器的内网环境调试。下面是一个最小化的调用片段逻辑与 Web 端一致import json import urllib.request import urllib.parse def gui_search(keyword, base_urlhttp://127.0.0.1:8000): # 桌面客户端只做请求转发排序逻辑留在后端服务 url f{base_url}/api/search?q{urllib.parse.quote(keyword)}limit20 with urllib.request.urlopen(url) as resp: data json.loads(resp.read()) return [(item[news_id], item[title], item[score]) for item in data[items]]说明桌面端不复制索引逻辑所有检索和排序都在 FastAPI 服务里完成客户端退化为 JSON 消费端。这种设计在生产环境的价值在于后端算法升级时Web、Tkinter、命令行三个前端都不需要改动。4.4 搜索日志与接口访问控制检索系统只“能搜”不够还要“能改”。search_log 表记录每次查询的关键词、时间、点击的新闻 id这些数据是热门词统计和个性化排序的原料。API 鉴权用简单 token 机制登录接口返回 token其他接口在 Header 带Authorization: Bearer token。管理端 /api/admin/search_logs 必须鉴权普通搜索接口可以匿名放行因为搜索是低风险只读操作日志是敏感数据。5. 索引调优与三层验证让排序权重不再靠猜最后讲一个具体技巧调参排序权重。很多项目把 k1、b、字段权重写死效果不好就换模型。实际上线性扫参加文档级评测就能挖出大部分问题。这里的顺序是先文本后排序先召回后精排。5.1 七步调参顺序新闻搜索场景里参数之间有耦合顺序不对等于白调。我常用的顺序是步骤动作观察指标1检查分词和停用词是否引入垃圾词项词项频次 TOP 表2确认所有文档时间解析成功publish_time 缺失比例3过滤 DF 过大的弱区分度词项检索覆盖率4固定 k11.5、b0.75 跑基线NDCG105扫 k1 在 1.2-2.0 区间NDCG10 曲线6固定 k1扫 b 在 0.5-1.0 区间NDCG10 曲线7最后调字段权重和半衰期前 5 条人工审查每一步只动一个参数记录指标变化。这样改坏了知道是哪个参数引入的回滚也只是 revert 一行配置的事。5.2 离线指标NDCG10MRR 只关心第一个相关结果的位置NDCG 关心整个头部排序质量。实现如下import math def ndcg_at_k(ranked_ids, relevant, k10): # ranked_ids是算法输出的前k个doc_idrelevant是标注的相关文档集合 dcg 0.0 for i, doc_id in enumerate(ranked_ids[:k]): if doc_id in relevant: dcg 1.0 / math.log2(i 2) ideal sum(1.0 / math.log2(i 2) for i in range(min(len(relevant), k))) return dcg / ideal if ideal else 0.0 # 用法示例构造一条查询的人工标注 relevant_docs {101, 105, 109} ranked_docs [102, 101, 105, 109, 110] print(round(ndcg_at_k(ranked_docs, relevant_docs, k10), 4))说明第 1 名命中得 1/log2(2)1第 2 名命中得 0.63位置越靠后折扣越大。理想排序把所有相关文档放在最前面NDCG 是实际 DCG 与理想 DCG 的比值。标注不需要全量做取每个查询前 20 条人工打标就够用。5.3 线上验证与三个常见坑离线指标提升后上线要看真实数据搜索无结果率、平均点击位置、翻页率。线上常见三个坑需要留神。第一个是停用词过滤太猛新闻里的“安全”“风险”“报告”这类词在通用场景是高频词但在财经检索里信息量很大别一刀切进停用词表。第二个是增量索引只增不删已下线新闻的 doc_id 还留在索引里排序时一直参与计算。处理办法是维护一个 deleted 标记表构建时跳过已删除文档。第三个是 b 值不要默认 0.75 就认为是对的短标题占比高的新闻语料b 取 0.5 到 0.6 往往更好用 5.2 的指标曲线去选而不是拍脑袋。本文还有配套的精品资源点击获取 Python实现可解释新闻搜索引擎：从爬虫到BM25排序的完整实践
简介这是一份基于Python的新闻搜索引擎设计与实现的完整项目资料包面向具备Python编程基础、熟悉Web开发或数据库操作、对自然语言处理与信息检索感兴趣的研发人员、数据工程师及高校学生覆盖搜索后端开发全流程。资源为单个docx文档约118KB集中呈现从新闻采集、中文分词、倒排索引构建到BM25相关性排序、Web与桌面GUI展示的完整工程思路并配套程序代码、数据库设计及模块拆分说明。目前已有64人学习/浏览。通过学习可掌握爬虫反爬应对、文本清洗、索引构建和排序优化等关键环节理解垂直领域搜索系统的模块化架构并能在舆情监测、金融研究、媒体辅助等实际业务中迁移应用。文档目录按项目背景、系统架构、代码示例、应用领域等逐层展开结构清晰适合作为课程设计、毕业设计或技术进阶的参考资料。1. 为什么一个可解释的新闻搜索比“搜索引擎”更重要通用搜索引擎的排序是个黑盒输入关键词得到结果但你解释不了“为什么它排第一”。面向垂直领域的新闻搜索不一样必须能回溯每一步标题命中加了权重近期发布时间加了指数衰减BM25 的 b 参数对长文做了长度归一化。用 Python 实现的这个新闻搜索引擎把自然语言处理、信息检索和 MySQL 数据库三条线串进同一个体系requests 采集新闻jieba 完成中文分词倒排索引解决加速问题BM25 决定相关性排序FastAPI 提供检索接口前端用 Web 和 Tkinter 双落点。适合做舆情监控、行业研究或者想搞懂搜索系统内部机制的工程师。这个项目的价值不在“能搜到”而在“能说清怎么搜到的”。2. 数据与文本处理爬虫采集、中文分词与检索单元的确定搜索结果的上限由数据质量决定。排序模型再强拿到的也是清洗后的标题、正文、发布时间和来源。这一层的工作直接决定索引里有什么词项、每个文档多长、发布时间是否可信。下面从采集、解析到分词归一化把进入索引之前的工序走通。2.1 先入库还是先检索取决于数据量素材里同时给出了“在线抓取即时解析”和“先入库后索引”两条路径。我的经验是分阶段几百篇演示数据时直接抓完建索引代码直观上万篇且需要多次重启系统时必须把新闻原始字段先落 MySQL检索时再加载索引。这样爬虫崩溃不丢数据索引重建也不用重新抓网页。数据层设计上news 表只存新闻实体字段news_processed 表存分词结果index_term_doc 存倒排信息。表的拆分让加载和增量更新互不干扰。表名职责与检索的关系news新闻原始字段标题、正文、时间、来源结果展示时读取详情news_processed分词后的词项列表与字段标记索引构建的输入index_term_doc词项到文档及出现位置查询加速的主体search_log查询词、点击、时间调优与热门词分析2.2 反爬与页面结构变化的工程化解耦新闻网站改版很频繁按标签硬编码的选择器两三周就会失效。素材里强调的“模块化、配置驱动”设计可以拆成两层访问层统一管理请求频率和身份特征解析层为每个新闻源维护独立的抽取规则。下面这段代码把这两件事分开处理。import requests import random import time import re from bs4 import BeautifulSoup UA_POOL [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36, ] def fetch(url, sleep(0.5, 1.5)): 带随机UA和休眠的抓取避免高频请求被识别为脚本 session requests.Session() session.headers.update({User-Agent: random.choice(UA_POOL)}) resp session.get(url, timeout10) resp.encoding resp.apparent_encoding time.sleep(random.uniform(*sleep)) return resp.text def parse_news(html, rule): soup BeautifulSoup(html, lxml) # rule是每个新闻源的独立配置改版时只改配置不动代码 title_node soup.select_one(rule[title]) body_node soup.select_one(rule[body]) if body_node is None: # 降级策略取文本最长的div用于正文容器样式调整后的兜底 body_node max(soup.find_all(div), keylambda d: len(d.get_text()), defaultNone) return { title: title_node.get_text(stripTrue) if title_node else , body: body_node.get_text(\n, stripTrue) if body_node else , publish_time: extract_time(html), source: rule[source_name], } def extract_time(html): # 优先匹配微格式datetime属性再退回meta标签 m re.search(rdatetime([^]), html) if m: return m.group(1) m re.search( rmeta[^]propertyarticle:published_time[^]content([^]), html, ) return m.group(1) if m else None逻辑说明fetch 把 UA 随机、编码推断、请求间隔放在一起随机休眠区间比固定 1 秒更不容易形成访问特征parse_news 的入参 rule 是每个新闻源一组的抽取规则站点改版只改配置。正文解析失败时退到“文本最长的 div”是保底手段准确率不如规则命中但能保证数据链路不断。extract_time 先读微格式 datetime 属性再找 article:published_time 的 meta 标签这是新闻页里最主流的两种发布时间承载方式。注意很多新闻站点的发布时间藏在页面渲染后的 JS 变量里比如pubDate: 2025-03-01 10:30:00。这种情况可以再加一条正则兜底最终优先级顺序是规则选择器 → 微格式属性 → meta 标签 → 正则。2.3 jieba 分词、停用词与字段权重中文没有天然空格分隔jieba 的精确模式 cut_allFalse 适合索引构建词项少、索引体积稳定query 侧对长查询改用搜索引擎模式可以拆出更细的词项提高召回。import jieba import re STOP_WORDS set() with open(stopwords.txt, encodingutf-8) as f: STOP_WORDS {line.strip() for line in f if line.strip()} def tokenize(text, search_modeFalse): # 精确模式保证索引词项稳定search_modeTrue 时按搜索引擎模式细切 if search_mode: words jieba.cut_for_search(text) else: words jieba.cut(text, cut_allFalse) result [] for w in words: w w.strip().lower() if not w or w in STOP_WORDS: continue if re.fullmatch(r[\d\W_], w): continue result.append(w) return result def prepare_doc(news_item): # 标题和正文分别分词返回带字段标记的词项流 return { title_tokens: tokenize(news_item[title]), body_tokens: tokenize(news_item[body]), publish_time: news_item[publish_time], news_id: news_item[news_id], }参数说明停用词表按行读取常见做法是合并公开停用词表和自己从语料里统计的高频无义词正则[\d\W_]过滤纯数字和纯符号但做 lower 而不是直接去大写是为了保留 “ChatGPT”“iPhone” 这类含大小写的专有名词形态。prepare_doc 输出的标题词项和正文词项分开为第三章的字段加权做准备。2.4 重复新闻去重与字段权重定型同一新闻在不同平台互相转载很常见标题完全一致或高度相似的条目会同时进入索引污染排序结果。演示项目里可以先对标题做归一化去掉空格、去标点、数字统一格式再算 MD5 做精确去重。更严谨的做法是两两比较最长公共子串或计算 SimHash在十万级语料上可以按候选桶只对比同桶内的文档把 O(n²) 降下来。字段权重在这个阶段定下来比较合理标题词项权重设 2.8正文设为 1.0导语段文字段单独设 1.6。理由来自一个常见现象标题完整包含查询词的新闻用户点击率显著高于正文命中。后面 BM25 的最终得分会把这些权重直接乘进相关性里。这个值可以先写死再通过第五章的验证方法去调。3. 倒排索引与 BM25 排序从全表扫描到毫秒级检索没有倒排索引MySQL 的 LIKE %词% 在十万条新闻上就是几十秒级别的全表扫描有了倒排索引一次查询收敛到几个词项的 posting list 合并毫秒级返回。倒排索引解决的是“哪些文档包含这个词”BM25 解决的是“这些文档里谁更相关”两个环节缺一不可。3.1 索引落内存还是落 MySQL方案优点缺点适用量级内存 dict 结构查询快代码直观方便调试进程重启要重建单机百万级以下MySQL 的 index_term_doc 表持久化支持增量更新查询多一次 DB 往返分布式前的过渡Redis / 搜索中间件自带数据结构与持久化引入额外依赖高并发线上场景素材里同时设计了 index_term_doc 表结构和内存构建模块实际运行时先读表加载进内存查询只走 dict 结构。这个“表存、内存查”的组合是单机新闻搜索里性价比最高的形态既有持久化保障又不让数据库参与每次查询的热路径。3.2 倒排索引构建与候选集生成from collections import Counter, defaultdict class InvertedIndex: def __init__(self): self.postings defaultdict(dict) # 词项 - {doc_id: tf} self.df defaultdict(int) # 词项文档频率计算IDF用 self.doc_len {} # 文档总长度 self.total_docs 0 def add_doc(self, doc_id, field_tokens): # 标题和正文拼在一起统计TFdoc_len后续用于BM25长度归一化 merged field_tokens[title_tokens] field_tokens[body_tokens] counter Counter(merged) self.doc_len[doc_id] len(merged) for term, tf in counter.items(): # counter迭代时每个term唯一df自增就是文档频率 self.postings[term][doc_id] tf self.df[term] 1 self.total_docs 1 def build_from_processed(self, processed_rows): for row in processed_rows: self.add_doc(row[news_id], row) def query(self, terms): # 多词项取并集得到候选文档排序交给评分函数 candidates set() for term in terms: candidates.update(self.postings.get(term, {}).keys()) return candidates逻辑说明add_doc 里把标题和正文词项合并统计 TF同时记录文档长度这两个值 BM25 都要用。df 自增放在 counter 迭代里是安全的因为一个 term 在一个文档内即使出现多次counter.items() 也只迭代一次。query 阶段只做候选集收集不做过滤这保证召回不会因为某个词项过于激进而被误杀。3.3 BM25 公式与 k1、b 参数的物理含义BM25 对 TF-IDF 的核心改进是两条曲线TF 不再线性增长而是被 k1 压缩到渐近线文档长度归一化由 b 控制。b0 时完全忽略文档长度b1 时完全按平均长度归一。新闻场景里短标题命中比长正文堆词更有价值所以 b 初始取 0.75k1 取 1.2 到 1.5 之间比较稳妥。import math def bm25(query_terms, doc_id, index, avg_doc_len, k11.5, b0.75): score 0.0 dl index.doc_len.get(doc_id, 0) if dl 0: return 0.0 N index.total_docs for term in query_terms: postings index.postings.get(term, {}) tf postings.get(doc_id, 0) if tf 0: continue df len(postings) # postings的长度就是含该词项的文档数 idf math.log(1.0 (N - df 0.5) / (df 0.5)) tf_part tf * (k1 1.0) / (tf k1 * (1.0 - b b * dl / avg_doc_len)) score idf * tf_part return score参数说明IDF 公式里加了 1避免高频词的 IDF 变成负值反过来扣分tf_part 分母中的dl / avg_doc_len就是长度归一化长文档的 TF 会被压低。k1 越大TF 增长曲线的衰减越慢短查询对头部高 TF 文档更敏感b 越大长文档惩罚越强。调参时要固定一个扫另一个用第五章的评估指标取舍而不是直接改到某一组经验值上。3.4 字段权重与时间衰减的融合排序新闻和普通文档最大的差异是时间敏感。排序公式在 BM25 得分基础上乘两个因子字段权重和发布时间的指数衰减。新闻阅读场景里半衰期取 7 天作为默认值意味着 7 天前发布的新闻时间项权重衰减到一半。from datetime import datetime def rank_news(query_terms, candidates, index, meta, avg_doc_len, half_life7.0): results [] for doc_id in candidates: base bm25(query_terms, doc_id, index, avg_doc_len) if base 0: continue # meta里保存标题词项集合与publish_time构建索引时注入 title_set meta[doc_id][title_set] title_hits sum(1 for t in query_terms if t in title_set) field_boost 1.0 1.8 * title_hits # 标题命中一次乘以2.8没有命中不惩罚 age_days (datetime.now() - meta[doc_id][publish_time]).days time_decay math.exp(-age_days / half_life) final base * field_boost * (0.5 0.5 * time_decay) results.append((doc_id, final)) results.sort(keylambda x: x[1], reverseTrue) return results逻辑说明field_boost 直接统计标题命中词项的个数让标题完整包含查询词的新闻优先时间衰减被压缩到 [0.5, 1.0] 区间即使是很久以前的强相关新闻也不会被彻底压出首页。最终得分是乘法组合调参时不要单独放大时间项否则强相关的老新闻会集体跌出前 20新闻搜索的“相关第一、时间第二”原则就被破坏了。4. FastAPI 检索服务与两种前端落点后端把索引和排序封装成服务前端只消费接口。API 设计、查询解析和前端实现在这里端到端串起来。Web 页面适合日常查询Tkinter 客户端适合内网调试和演示环境两者共用同一套检索服务。4.1 API 接口约定接口方法参数返回/api/searchGETq, limit, page新闻 id 列表、得分、摘要/api/news/{news_id}GET路径参数新闻完整字段/api/suggestGETprefix补全候选词/api/hot_queriesGETtop_n高频搜索词/api/auth/loginPOSTusername, password访问 token/api/admin/search_logsGETpage搜索日志分页4.2 查询解析与搜索接口实现查询侧需要做一次轻量解析普通关键词走全词匹配带引号的短语要求词项按顺序出现前缀site:或from:可以限定来源。素材里的实现聚焦前两种代码保持精简后续要扩展解析规则时再抽独立的解析函数。from fastapi import FastAPI, Query, HTTPException app FastAPI() class SearchEngine: 组合InvertedIndex与meta数据启动时加载查询时只读 def __init__(self): self.index None self.meta {} def rank(self, query_terms, candidates): # 细节见 rank_news 实现这里做封装 return rank_news(query_terms, candidates, self.index, self.meta, self.avg_doc_len) engine SearchEngine() app.get(/api/search) def search_api(q: str Query(..., min_length1), limit: int 10, page: int 1): query_terms tokenize(q, search_modeTrue) if not query_terms: raise HTTPException(status_code400, detail查询词全部被停用词过滤) candidates engine.index.query(query_terms) ranked engine.rank(query_terms, candidates) start (page - 1) * limit page_items ranked[start:start limit] return { total: len(ranked), page: page, items: [item_to_dict(doc_id, score, query_terms) for doc_id, score in page_items], } def make_summary(meta, query_terms): body meta[body] pos -1 for t in query_terms: p body.find(t) if p ! -1: pos p break if pos -1: return body[:120] return body[max(0, pos - 40): pos 80] ...参数说明tokenize 开启 search_mode让“人工智能监管政策”这样的长查询拆出多个候选词提高召回。make_summary 用第一个命中的词项定位正文窗口这比固定截取前 120 字更贴近查询意图。total 字段保留全量命中数前端翻页时用。4.3 Web 前端与 AJAX 异步调用Web 端用 FastAPI 自带的 Jinja2 模板渲染搜索首页查询动作通过 AJAX 请求 /api/search避免整页刷新。部署时不引入前端工程化工具链直接启动 uvicorn 就能跑。核心结构是一个输入框、一个结果列表容器fetch 拿到 JSON 后渲染。素材里的完整项目还包含 Tkinter 客户端适合在没有浏览器的内网环境调试。下面是一个最小化的调用片段逻辑与 Web 端一致import json import urllib.request import urllib.parse def gui_search(keyword, base_urlhttp://127.0.0.1:8000): # 桌面客户端只做请求转发排序逻辑留在后端服务 url f{base_url}/api/search?q{urllib.parse.quote(keyword)}limit20 with urllib.request.urlopen(url) as resp: data json.loads(resp.read()) return [(item[news_id], item[title], item[score]) for item in data[items]]说明桌面端不复制索引逻辑所有检索和排序都在 FastAPI 服务里完成客户端退化为 JSON 消费端。这种设计在生产环境的价值在于后端算法升级时Web、Tkinter、命令行三个前端都不需要改动。4.4 搜索日志与接口访问控制检索系统只“能搜”不够还要“能改”。search_log 表记录每次查询的关键词、时间、点击的新闻 id这些数据是热门词统计和个性化排序的原料。API 鉴权用简单 token 机制登录接口返回 token其他接口在 Header 带Authorization: Bearer token。管理端 /api/admin/search_logs 必须鉴权普通搜索接口可以匿名放行因为搜索是低风险只读操作日志是敏感数据。5. 索引调优与三层验证让排序权重不再靠猜最后讲一个具体技巧调参排序权重。很多项目把 k1、b、字段权重写死效果不好就换模型。实际上线性扫参加文档级评测就能挖出大部分问题。这里的顺序是先文本后排序先召回后精排。5.1 七步调参顺序新闻搜索场景里参数之间有耦合顺序不对等于白调。我常用的顺序是步骤动作观察指标1检查分词和停用词是否引入垃圾词项词项频次 TOP 表2确认所有文档时间解析成功publish_time 缺失比例3过滤 DF 过大的弱区分度词项检索覆盖率4固定 k11.5、b0.75 跑基线NDCG105扫 k1 在 1.2-2.0 区间NDCG10 曲线6固定 k1扫 b 在 0.5-1.0 区间NDCG10 曲线7最后调字段权重和半衰期前 5 条人工审查每一步只动一个参数记录指标变化。这样改坏了知道是哪个参数引入的回滚也只是 revert 一行配置的事。5.2 离线指标NDCG10MRR 只关心第一个相关结果的位置NDCG 关心整个头部排序质量。实现如下import math def ndcg_at_k(ranked_ids, relevant, k10): # ranked_ids是算法输出的前k个doc_idrelevant是标注的相关文档集合 dcg 0.0 for i, doc_id in enumerate(ranked_ids[:k]): if doc_id in relevant: dcg 1.0 / math.log2(i 2) ideal sum(1.0 / math.log2(i 2) for i in range(min(len(relevant), k))) return dcg / ideal if ideal else 0.0 # 用法示例构造一条查询的人工标注 relevant_docs {101, 105, 109} ranked_docs [102, 101, 105, 109, 110] print(round(ndcg_at_k(ranked_docs, relevant_docs, k10), 4))说明第 1 名命中得 1/log2(2)1第 2 名命中得 0.63位置越靠后折扣越大。理想排序把所有相关文档放在最前面NDCG 是实际 DCG 与理想 DCG 的比值。标注不需要全量做取每个查询前 20 条人工打标就够用。5.3 线上验证与三个常见坑离线指标提升后上线要看真实数据搜索无结果率、平均点击位置、翻页率。线上常见三个坑需要留神。第一个是停用词过滤太猛新闻里的“安全”“风险”“报告”这类词在通用场景是高频词但在财经检索里信息量很大别一刀切进停用词表。第二个是增量索引只增不删已下线新闻的 doc_id 还留在索引里排序时一直参与计算。处理办法是维护一个 deleted 标记表构建时跳过已删除文档。第三个是 b 值不要默认 0.75 就认为是对的短标题占比高的新闻语料b 取 0.5 到 0.6 往往更好用 5.2 的指标曲线去选而不是拍脑袋。本文还有配套的精品资源点击获取