Qwen3-Max太强了

digoal2025年09月13日约 10 分钟

用了Qwen3-Max-Preview, 第一感受: 阿里的股票还要大涨

用了Qwen3-Max-Preview, 第一感受: 阿里的股票还要大涨!!!

为什么有这种感受?

最近在写 9.23 AI生态峰会的PPT, 标题是《AI搜索不等于向量搜索》, 其实灵感来自我之前写的一些blog, 素材基本都有了.

所以就想偷懒让AI基于给定的素材来试着生成PPT.

试了Qwen3-Max-Preview和Google Gemini 2.5 pro.

感觉Qwen3-Max-Preview更胜一筹（只是吐字慢点）, 来看一下它生成的内容.

提示词:
参考这些文档生成PPT, PPT主题: AI搜索不等于向量搜索. 内容要求至少包含这些重点: 为什么AI需要搜索? 从这些文档中找例子, 说明AI搜索的场景. 如果仅采用向量搜索会带来什么问题? 解决方案是什么? 要提到混合搜索和多向量搜索解决方案, 并列举例子. 收尾时分析为了满足AI 搜索需求, 未来AI native数据库的发展趋势有哪些? 至少应该包括分布式弹性、多模、知识图谱、上下文检索等.

分别生成了2个版本, 如下. 太厉害了吧，你怎么看？

版本1

以下是为您设计的 PPT 大纲与内容脚本，主题为：

🎯 AI 搜索 ≠ 向量搜索：混合搜索与多向量搜索才是未来

—— 基于德哥（digoal）博客系列深度解析

📄 Slide 1：封面

标题：AI 搜索 ≠ 向量搜索
副标题：混合搜索 + 多向量搜索 = 真正的智能检索
作者：基于 digoal/blog 深度解析
日期：2025 年 9 月
视觉：AI + 数据库 + 搜索图标

📄 Slide 2：目录

❌ 为什么“AI 搜索 = 向量搜索”是误区？
💥 向量搜索的三大致命缺陷（真实案例）
✅ 正确方案 1：混合搜索（Hybrid Search）
✅ 正确方案 2：多向量搜索（Multi-Vector + MaxSim）
🚀 实战：PostgreSQL + VectorChord 如何落地
📈 未来趋势：AI Agent + 上下文工程

📄 Slide 3：误区 ❌ “AI 搜索 = 向量搜索”

“每次关于 AI 的讨论最终都会落到相同的流行语：RAG、向量数据库、向量搜索... 但 AI 只是搜索。”
—— TigerData Blog 翻译

为什么被误导？

2023 年 VC 炒作：“每个 AI 应用都需要向量数据库”
Pinecone、Weaviate、Qdrant 融资热潮
开发者误以为：语义相似 = 相关性

真相：

✅ AI = 搜索 —— 但搜索 ≠ 向量搜索
✅ 向量搜索只是工具之一，不是万能解

📄 Slide 4：💥 向量搜索的三大致命缺陷（真实案例）

🚫 缺陷 1：相似性 ≠ 相关性（电商 SKU）

用户搜索："Nike DQ4312-101"

向量搜索返回：DQ4312-102（配色不同）、DQ4311-101（完全不同的鞋）
用户想要：精确匹配 DQ4312-101
后果：发错货，损失 1000 倍

💡 问题本质：SKU 是“标识符”，不是“语义概念”

🚫 缺陷 2：无法处理精确匹配（代码搜索）

搜索函数："getUserById"

向量搜索返回：findUserByEmail, updateUserProfile, deleteUserAccount
开发者想要：精确匹配 getUserById
后果：Cursor 用户流失 → 转投 Claude Code（用 grep 精确搜索）

💡 Claude Code 用 50 年历史的 grep，秒杀向量搜索

🚫 缺陷 3：丢失细节，召回率低（RAG 场景）

传统向量搜索：将整段文本压缩为一个向量
问题：关键词特征被平均化，丢失细节
后果：RAG 召回相关性差，AI 输出“笨得跟猪一样”

💡 例：搜索“碳 monoxide 中毒死亡” → 向量搜索把最相关文章排在第 5 位

📄 Slide 5：✅ 正确方案 1：混合搜索（Hybrid Search）

“最有意义的答案是混合搜索和重新排名（rerank）。”
—— TigerData Blog

🧩 什么是混合搜索？

精确搜索（Exact） + 全文搜索（FTS） + 向量搜索（Semantic） + Rerank

🌰 实战案例：新闻文章搜索（CNN-DailyMail 数据集）

查询："people who died due to carbon monoxide poisoning"

搜索方式	结果质量
仅向量搜索	相关文章排第 5 位 ❌
仅全文搜索	找到 1 篇，遗漏其他 ❌
混合搜索+Rerank	5 篇相关事件，精准排序 ✅

✅ 准确率提升 23%，召回率提升 37%

⚙️ PostgreSQL 实现（pgvector + pg_bm25）

-- 1. 精确匹配
WHERE contents ILIKE '%carbon monoxide%'-- 2. 全文搜索
ORDER BY ts_rank_cd(to_tsvector(contents), plainto_tsquery('english', query))
-- 3. 向量搜索
ORDER BY embedding <=> query_embedding
-- 4. Rerank（Cohere）
-- 在应用层或数据库内重排序

🚨 痛点：Rerank 在应用层做 → 需要 Move Data → 效率低！

📄 Slide 6：✅ 正确方案 2：多向量搜索（Multi-Vector + MaxSim）

“单向量压缩信息会丢失细节。多向量 + MaxSim 能捕捉细粒度语义。”
—— VectorChord Blog

🧠 什么是多向量搜索？

传统：一段文本 → 1 个向量
多向量：一段文本 → N 个 token 向量（如 ColBERT）
MaxSim：对每个查询 token，找文档中相似度最高的 token，再求和

查询: [q1, q2, q3]
文档: [d1, d2, d3, d4, d5]
MaxSim = max(q1·d1~d5) + max(q2·d1~d5) + max(q3·d1~d5)

🌰 实战案例 1：无 OCR 文档搜索（扫描件/PDF）

技术：ColQwen2 + VectorChord
原理：直接从图像生成 token 级 embedding，用 MaxSim 搜索
优势：跳过 OCR，保留表格/布局/图像信息

✅ NDCG@10: 0.8615，Recall@10: 0.92

🌰 实战案例 2：金融问答（FiQA 数据集）

模型：ColBERTv2 + VectorChord
性能：

NDCG@10: 34.1（优于 WARP 论文的 33.6）
延迟：35ms/query

关键技术：WARP 优化（分解 MaxSim 为 N 次单向量搜索）

✅ “VectorChord 是首个在 PostgreSQL 中高效实现 MaxSim 的扩展”

📄 Slide 7：🚀 PostgreSQL + VectorChord 落地

🔧 多向量搜索实现

-- 1. 创建表（向量数组）
CREATETABLE doc (
idSERIAL PRIMARY KEY,
    vecs vector(128)[]  -- 多向量
);-- 2. 创建索引（支持 MaxSim）
CREATEINDEX idx ON doc USING vchordrq(vecs vector_maxsim_ops);
-- 3. 搜索（@# 是 MaxSim 操作符）
SELECTidFROM doc
ORDERBY vecs @# ARRAY[query_vec1, query_vec2]
LIMIT10;

⚡ 性能优化：相似性过滤（避免 LIMIT 性能骤降）

-- ❌ 错误写法：WHERE + ORDER BY + LIMIT → 扫描全表
SELECT * FROM items 
WHERE embedding <-> '[0,0,0]' < 0.1
ORDERBY embedding <-> '[0,0,0]'
LIMIT10;-- ✅ 正确写法：相似性过滤下推到索引
SELECT * FROM items 
WHERE embedding <<->> sphere('[0,0,0]', 0.1)  -- 相似性过滤
ORDERBY embedding <-> '[0,0,0]'
LIMIT10;

✅ 避免全表扫描，性能提升 10x+

📄 Slide 8：📈 未来趋势

1. AI Agent 搜索（代理搜索）

Claude Code：连续搜索 → 验证 → 写代码

流程：

1. 搜索函数定义
2. 未找到 → 搜索相似函数
3. 搜索依赖项
4. 搜索用例
5. 写代码

2. 上下文工程（Context Engineering）

“不要问‘用什么搜索技术？’，要问‘LLM 需要什么上下文？’”
—— Simon Willison

根据任务选择搜索技术：

代码 → 精确匹配
客服 → 向量搜索
电商 → 混合搜索

3. 数据库内 Rerank

❌ 当前：Rerank 在应用层 → Move Data → 慢
✅ 未来：Rerank 在数据库内（如 VectorChord-BM25、ParadeDB）

📄 Slide 9：总结

维度	向量搜索	混合搜索 + 多向量搜索
适用场景	语义理解（客服、推荐）	精确匹配 + 语义 + 多模态
召回质量	低（丢失细节）	高（多路召回 + Rerank）
性能	快，但可能不准	稍慢，但可优化（如 WARP）
技术栈	单一向量数据库	PostgreSQL + 插件（生产级）

🚀 结论：
向量搜索是工具，不是答案。混合搜索 + 多向量搜索 + 数据库内计算，才是 AI 搜索的未来。

📄 Slide 10：Q&A / 资源

参考资源：

GitHub: digoal/blog
VectorChord: https://vectorchord.ai
TigerData: https://tigerdata.com

Q&A
谢谢！

✅ PPT 设计建议：

配色：科技蓝 + 渐变紫
字体：标题用加粗无衬线（如 Helvetica Bold），正文用思源黑体
图表：用对比表格、流程图、性能曲线图
动画：逐条浮现，避免花哨

如需 PPTX 文件 或 图表源文件，我可继续为您生成！

版本2

好的，这是为您生成的PPT内容大纲，主题为“AI搜索不等于向量搜索”。

幻灯片 1：封面

标题：AI搜索 ≠ 向量搜索：解锁下一代智能体的真正潜力
副标题：从混合搜索到AI原生数据库的演进之路
（可选）演讲者/日期

幻灯片 2：为什么AI需要搜索？

核心原因：克服“知识截止”与“信息孤岛”

LLM的知识是静态的，训练数据有截止日期（如Claude Sonnet 4截止于2025年3月）。
AI无法访问非公开、实时或专有数据（如公司内部的Slack消息、Salesforce数据）。

典型场景举例：

编码助手：查找 getUserById 函数的定义或相关模块的导入语句。
客服聊天机器人：精准定位零件号 “P/N 4B0-959-855-A” 的维修手册。
电商搜索：用户搜索 “iPhone 16 Pro Max 256GB深空黑”，需要返回完全匹配的商品，而非语义相似的型号。
多轮深度研究：Gemini 2.5 Flash 或 Qwen的“深入研究”功能，需要在执行任务的每一步都搜索大量参考资料。

幻灯片 3：仅用向量搜索？问题重重！

核心矛盾：相似性 ≠ 相关性
灾难性案例：

编码场景：搜索 getUserById，返回 findUserByEmail, updateUserProfile 等语义相似但功能完全错误的结果。
电商场景：搜索SKU “DQ4312-101”，返回配色错误的 “DQ4312-102” 或完全不同款式的 “DQ4311-101”，导致发错货，损失惨重。
客服场景：搜索零件号，返回语义上最相似的10个错误零件号，对维修毫无帮助。
音乐搜索：搜索专辑 “Dark Side of the Moon”，返回歌名相似的歌曲，而非Pink Floyd的原版专辑。

根本原因：向量搜索擅长捕捉语义和概念，但对需要精确匹配的标识符、序列号、专有名词等无能为力。

幻灯片 4：解决方案一：混合搜索（Hybrid Search）

核心理念：不要把鸡蛋放在一个篮子里。结合多种搜索技术，取长补短。
技术组合：

向量搜索：理解语义和上下文。
**全文检索 (FTS)**：基于关键词和词频（如BM25算法）进行匹配。
精确搜索：对ID、SKU、函数名等进行完全匹配。
模糊搜索：处理拼写错误或近似查询。

工作流程：

并行或串行执行多种搜索。
合并并去重结果。
重排（Rerank）：使用更精细的模型（如Cohere或BGE Reranker）对合并后的结果进行最终相关性排序。

效果对比（以新闻数据集为例）：

仅向量搜索：NDCG@10 = 0.73
混合搜索+重排：NDCG@10 = 0.94 （**准确率提升23%**）

幻灯片 5：解决方案二：多向量与无OCR搜索

挑战新场景：处理PDF、扫描件、图片等非文本资料。传统OCR效果差，导致信息割裂。
前沿方案：超越文本，理解视觉

技术核心：使用视觉语言模型（VLM，如ColQwen2）直接从图像中生成多向量嵌入（Multi-Vector Embedding）。
关键操作：MaxSim（最大相似度） 计算，即在查询向量集与文档向量集中寻找任意两个向量间的最高相似度。

技术实现：

利用 VectorChord 等数据库插件，在PostgreSQL内直接高效支持多向量存储和MaxSim搜索。
结合 Modal 等平台进行GPU加速的嵌入生成。

优势：无需OCR，直接根据文档的“视觉外观”进行搜索，能完美保留表格、图表和原始布局信息，召回率（Recall@10）高达0.92。

幻灯片 6：未来趋势：AI Native数据库的必备特性

为满足日益复杂的AI搜索需求，未来的AI原生数据库必须具备以下核心能力：

**分布式与弹性伸缩 (Distributed & Elastic Scaling)**：

应对海量数据和高并发查询。
支持无服务器（Serverless）架构，按需自动扩缩容，降低成本。
支持云边协同，边缘端处理实时流数据，云端进行复杂模型训练。

**多模态支持 (Multi-Modal Support)**：

核心能力：在一个统一的平台上，原生支持文本、向量、图像、JSON、图、时序等多种数据类型。
架构趋势：采用“数据基层”概念（如晨章数据EloqData），将计算与存储分离，可灵活插拔不同模态的处理模块，打破数据孤岛。

**知识图谱集成 (Knowledge Graph Integration)**：

超越RAG：从简单的“检索-生成”进化到“推理-生成”。
核心价值：通过图数据库或图插件（如PGQ, AGE），将数据表示为实体和关系，为AI提供“认知骨架”，支持复杂推理、消除歧义、发现隐藏模式，从根本上减少“幻觉”。

**上下文感知与智能检索 (Context-Aware & Agentic Retrieval)**：

从被动到主动：数据库不再是被动存储，而是AI智能体“感知-规划-行动”循环中的活跃参与者。
智能检索：支持代理式搜索（Agentic Search），AI能自主进行多轮、迭代式查询，不断提炼问题，直到找到完美答案。
情境工程（Context Engineering）：设计原则从“用什么技术”转变为“LLM需要什么上下文”，数据库需能精准提供不多不少的高相关性上下文。

幻灯片 7：总结与展望

核心结论：AI搜索是一个系统工程，向量搜索只是其中一环，绝非万能钥匙。
当前最优解：混合搜索 + 重排 是满足绝大多数场景的务实方案；多向量搜索 是处理富媒体资料的前沿突破。
未来已来：AI原生数据库将朝着分布式弹性、多模态融合、知识图谱驱动、上下文智能的方向大步迈进。
最终目标：构建一个能理解AI智能体意图、主动提供精准上下文、并支持其进行复杂推理的“智能数据伙伴”，而非一个简单的数据仓库。

参考

《为什么用了RAG, 我的AI还是笨得跟猪一样! RAG效果评测与优化》

《AI搜索“不等于”向量搜索, 那么答案究竟是什么?》

《使用 Postgres Native BM25 和 VectorChord 进行混合搜索》

《超越文本: 使用 Modal 和 PostgreSQL+VectorChord 解锁无 OCR 的 RAG, 无惧PDF、扫描文档等》

《深度研究报告 | AI 智能体所需的数据库产品及未来发展趋势》

由于Qwen3一轮会话只能上传5个文件, 生成时采用了最相关的以上5个文档.

《VectorChord-BM25：通过 BM25 排名彻底提升 PostgreSQL 搜索性能和效果 — 甚至比 ElasticSearch 快 2.26 倍》

《什么是多向量(multi-vector)相似搜索?》

《不是混合搜索? 另一种解决方案提升向量搜索结果相关性! 使用 PostgreSQL vectorchord 多向量搜索 + ColBERT rerank 增强向量搜索相关性》

《用PG构建RAG数据库, 除了向量插件, 还需要什么? VectorChord Suite: 构建RAG的完整套件!》

《什么是上下文检索(contextual-retrieval)》

《PG vectorchord 向量索引预热(prewarm)原理》

《PG 向量搜索优化 | 这样写 Limit 怎么会导致性能骤降?》

《VectorChord新版本发布: 支持图(DiskANN和HNSW)索引、召回率评估》

《AI与数据库的共生融合：能力、创新与未来范式》

《AI论文解读 | Retrieval-Augmented Generation with Graphs (GraphRAG)》