惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

罗磊的独立博客
爱范儿
爱范儿
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
博客园_首页
博客园 - 叶小钗
酷 壳 – CoolShell
酷 壳 – CoolShell
Apple Machine Learning Research
Apple Machine Learning Research
云风的 BLOG
云风的 BLOG
量子位
博客园 - 三生石上(FineUI控件)
Stack Overflow Blog
Stack Overflow Blog
小众软件
小众软件
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
V
V2EX
人人都是产品经理
人人都是产品经理
V
Visual Studio Blog
Jina AI
Jina AI
L
LangChain Blog
M
MIT News - Artificial intelligence
MongoDB | Blog
MongoDB | Blog
Last Week in AI
Last Week in AI
Martin Fowler
Martin Fowler
WordPress大学
WordPress大学

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
RAG全系列之《重排序 Rerank 》
寻走 · 2025-09-19 · via 人人都是产品经理

在RAG系统中,重排序(Rerank)是连接检索与生成的关键一环。本文深入解析Rerank模块的核心逻辑与主流技术路径,结合实际应用场景,帮助产品人理解如何通过重排序提升AI问答系统的准确性与响应质量。

向量化与重排序(rerank)是相辅相成的两个模块, 他们两个搭配起来,共同解决检索准确性的问题。

  • 向量检索的核心:在海量数据中,检索与跟查询内容相近的内容。一般称为内容召回。例如一次性召回 50 条内容
  • rerank的核心:基于召回的内容,再做更加精准的排序。例如将上面 50 条内容,做一次更加精准重排序,获取到 top10 内容;

为什么rerank准确这么重要?

生成答案的大模型,如果自己没有训练的话,他都是通用的识别能力,对于公司/行业内的专有名词/特地话术的区分能力很差。

如果你给了准确的知识,他能够生成准确的答案,但是如果你给的非常接近的错误的知识,他分辨能力较差,非常容易生成错误的答案。

rerank模型

本质就是针对重排序特别训练的大模型。我自己最早搭建 demo 的时候,并没有使用 rerank 模型,直接用一个火山 doubao 1.5模型, 让doubao 1.5 直接针对内容的相关性进行排序。这个也让我了解到了专门的 rerank 大模型到底改进了什么?

  • 速度更快:如果是使用通用的大模型对内容进行排序,耗时会很长,doubao的模型基本都是20s+,如果参与rerank环节的引用知识更多,那么排序时间就更长了。但是专门的rerank模型基本秒级就可以完成同等的排序
  • 排序分数更稳定:对于同一批知识,大模型的排序结果每次排序结果不尽相同,当你复现case的时候非常痛苦,但是专门的rerank模型排序结果是很稳定的;

模型推荐

一般不是很难排序的模型 bge-m3就足够了,模型本身小,运行速度快。如果排序比较难的话, 可以尝试 qwen rerank 8B 的模型,但是这个模型有点大,对于服务器配置要求比较高。

经验总结与反思

希望大家能够理解真正的原理,各个板块存在的意义,不然很容易人云亦云。

真的需要向量化吗?

向量化的时间相对来说比较高,需要搞自己向量化数据库,选择合适的向量化模型,但是我们真的有必要搞向量化吗?

向量化其实主要是方便从海量数据中找到可能的候选内容,供 rerank 使用。针对企业级场景,很多公司的内容并没有那么多,我们完全可以把所有的知识全量 rerank,直接获取结果就好了。我自己测试 500 条知识,rerank 的话几秒就完成了,做个并发的话,速度会更快。

需要自己训练模型吗?

通用的模型在理解一些行业专有名词的时候,效果不佳。如果这个成为了效果的瓶颈了,再考虑做模型微调。一般情况下,选个市面上通用的 rerank 模型就够用了。

微调的话,建议优先训练 rerank 模型,因为它是最终的决定性环节。如果rerank 效果好,向量化效果差,直接在向量化环节搞个 top100,然后交由 rerank 进行排序选出最好的 top10。

后续

上面聊的只是一路检索,但是现在我们使用的基本都是多路检索,后续再给大家介绍一下多路检索,以及后续生成环节如何处理。

本文由 @寻走 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议