RAG on 小盒子的技术分享

Google 刚刚把多模态检索，从“拼装工程”变成了“基础能力”

Thu, 12 Mar 2026 02:51:44 +0000

过去几年，多模态检索一直有一种很别扭的感觉：大家都知道它重要，也都知道它有价值，但真要落地，往往就会迅速滑向一场“拼装工程”。文本一套模型，图片一套模型，音频最好先转写，视频最好先抽帧，PDF 还要单独解析。最后系统看起来像是“能搜”，可背后其实是五六条处理链硬拼在一起，复杂、昂贵，而且很难优雅。

Google 新发布的 Gemini Embedding 2，真正让人眼前一亮的，不是它又把 embedding 做强了一点，而是它第一次把文本、图片、音频、视频、PDF拉进了同一个统一向量空间里。官方把它定义为 Google 首个原生多模态 embedding 模型，目前已经通过 Gemini API 和 Vertex AI 进入 Public Preview。

这件事听上去像模型更新，实际上更像一次架构层的洗牌。因为从这一刻起，多模态检索终于不再只是“大厂能做、小团队很难做优雅”的高级能力，而开始像一项真正的基础设施：可以被调用，可以被组合，也可以被更低成本地接进你的搜索、RAG、知识库和内容系统里。

它到底强在哪，不只是“支持多模态”

很多人看到这里，第一反应可能是：

“支持文本、图片、音频、视频、PDF，这不就是多模态吗？”

还真不止。

Gemini Embedding 2 的关键不只是“什么都能输进去”，而是所有模态出来以后能落在同一个 embedding space 里。这意味着什么？意味着你不再一定要为每种媒介维护完全独立的语义体系。文本可以搜图片，图片可以召回 PDF，音频可以关联视频片段，跨模态检索终于不是一层额外的“补丁能力”，而成了模型本身的默认能力。

这会直接改变系统设计思路。

以前你更像是在设计“五条平行管线”。

现在你更像是在设计“一个统一召回底座”。

注意，我这里说的是“更像”，不是说所有复杂度从此消失。长视频仍然要切片，复杂知识库仍然要做 metadata 设计，高要求场景依然常常需要 rerank。

最值钱的地方，是它终于不再要求你先做“翻译官”

过去处理非文本内容时，行业里一个非常常见的默认动作是“先降级成文本”。

●音频？先 Whisper。

●视频？先抽帧，最好再加字幕。

●PDF？先 OCR，再抽正文。

这类方案当然能工作，但本质上是在让系统把所有模态都挤进“文本入口”里。Gemini Embedding 2 做的，是把入口重新打开。它可以原生摄取音频，不需要中间文本转写；视频支持约 2 分钟级别的原生输入；PDF 也可以直接嵌入。

这意味着搜索开始更接近人真正理解世界的方式。

●你问“哪节课讲过这个图”，系统不一定非要先把整门课转成文本再去关键词匹配；

●你上传一段声音，也不一定非得先变成文字才能参与检索；

●你搜一个商品，也不一定要把图和文分开索引，最后再人工拼装成“结果页”。

一个特别容易被低估的能力：它可以表示“实体”，不只是“素材”

Gemini Embedding 2 还有一个很值得说的亮点：它支持混合输入。

如果你在一个 content entry 里传入多个 parts，比如“文字 + 图片”，模型会为这组内容生成一个聚合后的 embedding；如果你在 contents 数组里放多个独立条目，它则会返回多个独立向量。官方文档甚至直接建议：对于像社交媒体帖子这种包含多种媒体内容的复杂对象，可以把多个 embedding 聚合，形成一个 post-level representation

这件事非常关键。

因为它把 embedding 的对象，从“原子素材”升级成了“业务实体”。

一块手表，不只是商品图，也不只是商品描述；

一条社交帖子，不只是文字，也不只是配图；

一堂课程，不只是讲义 PDF，也不只是视频和录音。

过去这些东西往往是拆开建索引、拆开召回、最后在上层硬拼。

现在你可以在索引层就把它们当成一个“对象”来表示。

这对于做内容平台、商品搜索、企业知识库、课程检索，影响都非常大。因为从这里开始，RAG 的检索单元不再只能是 text chunk，它可以是一个帖子、一个商品、一段课堂内容，甚至一个带图文说明的复杂知识实体。

3072 维不是重点，重点是你终于可以按成本来调“语义密度”

做系统的人都知道，维度本身并不是越大越好。更大的维度意味着更高的存储成本、更高的计算开销、更长的检索延迟。Gemini Embedding 2 默认输出 3072 维，但支持用 output_dimensionality 调整维度，官方推荐的常见选择是 768、1536、3072，并说明它支持从 128 到 3072 的灵活输出。这个能力背后用的是 MRL（Matryoshka Representation Learning）

简单说就是：你可以根据场景，在“效果”和“成本”之间做更细粒度的平衡。

●如果你是大规模通用检索，1536 维可能就已经很香；

●如果你追求极致成本和吞吐，768 维会很有吸引力；

●如果你做的是高价值高精度场景，3072 维会更稳。

免费吗？多少钱？

Gemini Embedding 2 现在有两条主路径，想快速试、想低门槛上手，用 Gemini Developer API；想走企业治理、云权限、生产环境，走 Vertex AI。

第一条是 Gemini Developer API。

这一条更轻，适合开发者快速试。官方价格页明确写了：gemini-embedding-2-preview 当前有 Free Tier，文本、图片、音频、视频输入在免费层里都是 Free of charge。免费层数据 Used to improve our products: Yes；如果切到付费层，这一项会变成 No。付费价格方面：

●标准模式下文本是 $0.20 / 1M tokens

●图片约 $0.00012 / 张

●音频约 $0.00016 / 秒

●视频约 $0.00079 / 帧；

如果用 Batch API，价格大约是标准价的 50%。

第二条是 Vertex AI。

这一条更偏企业与云上生产环境。你需要 Google Cloud 项目、启用 billing、开启 Vertex AI API，并配置认证；而且 AI Studio 的 API key 不能直接用于 Vertex AI。模型页还写明：Gemini Embedding 2 当前支持的是 Standard PayGo，不支持 Provisioned Throughput、Flex PayGo、Priority PayGo 和 Batch Prediction，当前页面列出的区域是 us-central1。Vertex AI 价格页对它的专属条目写的是：

●文本 $0.2 / 1M tokens

●图片 $0.00012 / image

●视频 $0.00079 / frame

●音频 $0.00016 / sec

●输出不收费。

两个很容易踩的坑

第一个坑，是不要把旧向量直接拿来和新模型混用。

gemini-embedding-001 和 gemini-embedding-2-preview 的 embedding spaces 不兼容。也就是说，如果你准备升级到 Gemini Embedding 2，旧数据不能直接拿来比较，你需要重新做一遍 re-embedding。这对已经有存量索引库的团队来说，是非常现实的迁移成本。

第二个坑，是不要把“视频支持时长”写得过于绝对。

目前官方资料里有三种写法：

●Google 博客写的是支持最多 120 秒视频；

●Gemini API 文档写的是视频上限 128 秒；

●Vertex AI 模型页则更细，写成带音频视频上限 80 秒，不带音频视频上限 120 秒。

所以总结来说它当前具备 2 分钟级别的视频原生 embedding 能力，更长的视频仍建议切片后索引。

它不会消灭所有复杂度，但它确实改写了“默认架构”

Gemini Embedding 2没有神奇到让多模态检索从此没有工程问题。

它不会自动帮你解决 metadata、chunking、权限隔离、召回融合、在线延迟、索引更新这些老问题。

但它确实把过去那种“多模态一定要多套模型、多套索引、多阶段拼装”的默认范式，往前推了一大步。

更重要的是，这一步不是停留在“论文层面”的。Google 已经给出了官方接入路径，也已经列出 LangChain、LlamaIndex、Haystack、Weaviate、Qdrant、ChromaDB 和 Vertex AI Vector Search 等生态集成方式。也就是说，这不是一个“看上去很厉害但暂时用不起来”的能力，它已经开始变成开发者今天就能碰、今天就能试、今天就能接进系统里的东西。

所以，Gemini Embedding 2 真正改变的，可能不是“embedding 这个模型又进步了多少”，而是：

Google 终于把多模态检索，从一项需要大量拼装和妥协的工程活，推进成了一种更统一、更自然、更接近基础设施的能力。

最后

如果文本、图片、音频、视频、PDF 真的开始共享一个语义空间，接下来最值得重新思考的问题，也许就不再是：

“我还能接多少模型？”

而是：

在我的系统里，什么才算一个真正值得被检索的对象？

是一段文字，

是一页 PDF，

是一张图，

是一条帖子，

还是一个由图文、声音、视频共同组成的“实体”？

Gemini Embedding 2 给出的，不只是一个新模型。

它更像是在提醒所有做 AI 应用的人：

下一代检索系统要统一的，从来不只是接口，而是我们理解世界的入口。

3 毛钱干大事？用了几天豆包编程模型，我来扒一扒字节这波操作

Mon, 17 Nov 2025 12:58:03 +0000

“

测评人：小盒子（AI 架构仔，Agentic 编程方向，常年被 API 账单搞到头大）测评时间： 2025 年 11 月 11 日发布后的一周

这波价格战，字节是真不想给同行活路了

说实话，我当时 凌晨 1:47 在公司改那个傻 X 的 Kubernetes 配置。看到新闻推送，火山引擎出了个 豆包编程模型 Doubao-Seed-Code，说性能 SOTA，但这不是重点。

重点是价格。它宣称综合成本能比业界平均水平低 62.7%，直接是 国内最低价。我当时正在用 cc 搭配 k2，心想：都说最低价，质量怎么样呢？k2 测完了其实还是不如原装的 claude，所以 doubao-seed-code 如果真是质量高价格低的话，多一个选择也是蛮不错的。

以前我们跑一次复杂的 Agentic 任务，特别是涉及多轮 Bug 修复和重构的，Claude Sonnet 4.5 那个账单，每个月看一次疼一次。

我看官方资料里明晃晃地写着，做一个交互式英语学习网站，用 Doubao-Seed-Code 只需要 0.34 元左右，用 Claude Sonnet 4.5 可是要大概 4 块多。这差距，可以的～

它这个 API 定价，输入 1.20 元/百万 Tokens，输出 8.00 元/百万 Tokens（0-32K 区间），配合那个 Cache 技术，还能再降 80% 的成本。我们现在正在做 Agent 自动化项目，以前成本受限，很多地方要做工程优化，要这样的话，感觉忽然就 经济可行 了。

我立马摸鱼时试了下，冲了它那个 9.9 块首月的 Coding Plan。一杯咖啡钱，买一个号称 SWE-Bench Verified 榜单上 SOTA 的模型（这个榜单是测 Agent 端到端解决问题的能力，很硬核的）。

兼容 Claude Code

感觉最近这都成了编程模型的标配了哈。

作为 Claude Code 用户，感觉接入不是很丝滑的。Doubao-Seed-Code 原生兼容 Anthropic API ，接入方法还是老套路，很简单：

第一种方式

如果是短期测试，可以直接在终端中配置环境变量，在启动 Claude Code 前输入环境变量

1export ANTHROPIC_BASE_URL=https://ark.cn-beijing.volces.com/api/compatible
2export ANTHROPIC_AUTH_TOKEN=<ARK-API-KEY>
3export ANTHROPIC_MODEL=doubao-seed-code-preview-latest

第二种方式

如果是长期使用，可以直接配置文件

1open -e ~/.claude/settings.json
2
3{
4 "api_key": "xxxxxxx",
5 "api_url": "https://ark.cn-beijing.volces.com/api/compatible",
6 "model": "doubao-seed-code-preview-latest"
7}

说句提外话，最近这几家搞 code 模型的，就是明着抢 Claude 的客户，但我支持，哈哈。

切换零成本 + 价格低 60%+ 性能 SOTA 确实有点儿心动。

核心能力体验

“

长上下文和那个 VLM 才是真杀手锏

光便宜和兼容没用，代码写得烂，那也是浪费我时间。

看了一下上下文，256K，还成，跟 K2 一样，感觉现在没个 256K 都不好拿出手。

虽然 Claude 4.5 Sonnet 的上下文声称是 1M，但实际上只有 200K，而且还死贵。 256 好，还多 56K，哈哈

别小看多出来的这点儿。我手头有个遗留项目，Python 写的，几百个文件，那叫一个乱。模型处理 Bug，有时候上下文 Token 一爆，它就变瞎子了，你得手动 RAG 喂它代码，有时候就差那么一两个文件，逼得我重开个 thread，前面都白费劲了。

Doubao-Seed-Code 多出来的这 56K，意味着它能把整个中等规模的项目结构和依赖都装进 “脑子” 里

刚才我让它解决一个跨越十几个文件的逻辑 Bug，以前的模型得来回拉扯五六轮，这次它 一步到位 定位到了问题。而且它不只是修复 Bug，它还会 优化结构，提升代码的可读性和维护性。这才是 Agent 编程，不过客观地讲跟最贵的那位比还是有一定的差距。

VLM：前端仔的末日… 还是福音？

这个视觉理解（VLM）能力， 国内首发。

这个功能并不新鲜，但国内首发，算是跟上了。我现在可以直接把 UI 稿截图，或者手绘草稿扔给它。然后它能给你生成对应的代码。

我一开始以为它就是搞了个图转文字，再让 LLM 去生成代码，这种方法信息折损很大。结果它这个是原生的 VLM 能力，不是靠工具调用。最牛逼的是，它能 自己完成样式修复和 Bug 修复。它生成一个页面，然后拿截图跟你原始的设计稿对比，发现哪里边距不对，哪里颜色溢出了，自己动手改

我当时试了一个复杂的 Dashboard 界面，只给了一张截图，它生成的 React + Tailwind 代码还原度还是非常高的。前端兄弟估计已经麻木了，据我所知，他们自己也在用 vibe coding 干活，哈哈。

聊聊技术底裤

Doubao-Seed-Code 的核心是 Seed-Coder 家族，能 SOTA，说明字节在训练上砸了不少黑科技

官方资料里提了一堆很唬人的词儿, 小盒子来翻译翻译：

“大规模 Agent 强化学习训练系统” ：他们好像是搞了一套巨大的 打怪升级系统，专门用来训练代码 Agent。模型不是靠背书（预训练数据）学编程的，它是直接在 沙盒里 跑代码
构建了覆盖 10 万容器镜像的训练数据集”：为了让模型见过各种稀奇古怪的运行环境（比如 Python 3.7 + PyTorch 1.9 + CUDA 10.2），他们准备了 10 万个容器
“万级并发沙盒 session”：几万个容器同时跑。让模型在里面不断试错，错了就 罚站（接收执行反馈）。这样练出来的 Agent，解决问题的鲁棒性才强

这套机制直接解释了为什么它能在 SWE-Bench Verified 这种需要端到端解决问题的测试里登顶。它不是一个静态的知识库，它是个会 思考、会动手、会自我修正 的开发伙伴

顺便提一句，这个 Seed-Coder 还有开源版本。开源的 Seed-Coder-8B-Reasoning 有 64K 上下文，虽然不如商业 API 的 256K 那么猛，但对于个人研究也够用了。

测试

这里我做了一个测试，目的是看它能不能真的理解 “Vibe Coding”（用户描述一个抽象的、高层的需求，让 Agent 去实现），特别是设计稿的还原和自我纠错能力

找一个 UI 稿截图，越复杂越好。

最终生成的效果如下：

总结

无论最后你是否使用 doubao-seed-code 模型作为你的生产工具，我都推荐你试试，包括 k2 等其他模型，无它，AI 进化的速度很快，先上车！

单纯就 doubao-seed-code 来说，我觉得也还可以：

价格摆在那儿，跑 100 次 Agentic 任务的成本，以前可能只能跑 30 次。
VLM 是未来：前端开发效率的飞跃。
256K 上下文：真正能处理企业级复杂重构任务的基础。

Doubao-Seed-Code 这波操作，是想把 AI 编程从 “昂贵的工具” 变成 “水、电、煤” 一样基础设施。对于追求极致效率和成本控制的团队，值得一试。

怎样才算好文档

Sun, 26 Oct 2025 03:08:25 +0000

优秀文档的核心原则 —— 来自 OpenAI 团队 Cookbook

写文档是一种同理心的体现

文档的核心目标是将有用信息高效注入读者的头脑中，避免读者在信息海洋中迷失。优秀文档不是长篇大论，而是通过结构化、清晰和共情的设计，帮助读者快速解决问题。

让文档易于浏览

读者很少从头到尾线性阅读文档，他们更倾向于跳跃式浏览，寻找直接解决问题的部分。因此，文档应像一张高效的 “信息地图”，降低搜索成本，提高成功率。

●使用描述性标题：标题应是信息完整的句子，而非抽象名词。例如，用 “流式处理将首 token 响应时间缩短 50%” 代替 “结果”，让读者无需深入阅读即可获知要点。

●添加目录：目录如哈希表般加速定位，同时提供文档整体线索，帮助读者判断是否值得阅读。

●保持段落简短：短段落易于扫描；关键点可独立成一句单句段落，避免被长文淹没。

●以独立主题句开头：段落和节的首句应自成一体，不依赖前文。例如，“向量数据库可加速嵌入搜索” 优于 “基于此，让我们讨论更快的方法”，便于跳读者快速理解。

●主题词置于句首：如 “向量数据库加速嵌入搜索” 比 “嵌入搜索可由向量数据库加速” 更高效，因为读者只需读前两词即可把握主题。

●要点前置：将最重要的信息置于文档或节的顶部，避免司马式渐进式展开，先结果后过程。

●多用 bullet 列表和表格：这些格式天然支持扫描，提高可读性。

●加粗关键文本：大胆突出重要内容，帮助读者快速锁定。

这些技巧的核心是“读者优先”：设计时假设读者时间有限、注意力分散。

2. 写出高质量文本

糟糕的文风会消耗读者的认知资源，导致疲劳。优秀文档应追求简洁、流畅，减少解析负担。

●句子简洁：拆分长句、去除副词和冗余词，使用祈使语气（如写作书籍建议）。

●确保无歧义解析：避免词性模糊的句子。例如，“用句子标题节”（Title sections with sentences）易混淆词性；改为 “将节标题写成句子”（Write section titles as sentences）更易解析，即使稍长。

●避免左分支句子：这类句子要求读者短期记忆过多，如 “你需要面粉、鸡蛋、牛奶、黄油和少许盐来做煎饼”。改为右分支：“做煎饼需要面粉、鸡蛋、牛奶、黄油和少许盐”，更符合大脑处理习惯（类似于深度优先搜索）。

●少用指示代词：如 “this” 跨句使用易造成回溯负担。改为具体名词：“基于消息格式，让我们讨论函数调用” 优于 “基于此讨论”。

●保持一致性：统一标题大小写、标点（如尾随逗号）和命名规范（如 Cookbook 中的下划线 + 句首小写），避免读者分心。

●不假设读者心态：避免 “你现在可能想了解函数调用” 这类推测；改为 “To call a function, …”，保持中立。

写作原则源于认知科学：减少大脑负载，让内容自然流动。

3. 广泛有益于读者

文档用户背景多样（从新手到专家、多语言使用者），优秀文档应包容性强，覆盖潜在痛点，而非仅针对 “理想读者”。

●用简单语言：比预期更简化解释（但不低估）。考虑非母语者和术语生疏者，优先清晰而非炫技。

●避免缩写：全写出，如 “instruction following” 而非 “IF”；“retrieval-augmented generation”（或 “搜索 - 询问流程”）而非 “RAG”。专家成本低，新手收益高。

●预解常见问题：即使 95% 读者知晓 Python 包安装，也值得说明 —— 专家可略过，新手避免卡壳。记住，跨语言专家（如 JavaScript 开发者）可能 Python 是新手。

●选用具体准确术语：避开行话，如用 “input” 代替 “prompt”，“max token limit” 代替 “context limit”，更自明且贴合实际。

●代码示例通用自洽：最小化依赖，避免额外库或跨页引用，确保可直接复制运行。

●优先高价值主题：聚焦常见问题（如 token 计数），而非罕见场景（如表情符号数据库优化）。

●避免不良习惯：如 API 密钥勿硬编码示例。

●以广义开场引入主题：如解释推荐系统时，先提及 YouTube、Amazon 等应用场景，增强读者安全感。

这些建议体现共情：文档是为 “所有人” 服务的工具，过多假设会疏离部分用户。

4. 必要时打破规则

这些是指导而非铁律。文档写作是移情练习：代入读者视角，选择最有帮助的方式。最终，灵活应用才能适应具体情境。

给 AI 一双 “慧眼”：深度评测 7 款主流 AI 搜索引擎（Tavily, SerpApi, Exa.ai 等）

Sat, 25 Oct 2025 03:35:29 +0000

给 AI 用的搜索引擎

“给 AI 用的搜索引擎” 是一个专门为软件程序（尤其是人工智能模型）设计的接口，让它们能够以编程方式请求、接收和理解来自网络的信息。

为什么 AI 需要这样的搜索引擎？

大型语言模型（如 GPT、Gemini 等）本身非常强大，但它们存在一些固有局限。搜索引擎是克服这些局限性的关键工具。

1.克服 “知识截止日期”

○问题：AI 模型的知识不是实时的。它的知识被 “冻结” 在它训练数据截止的那个时间点。例如，一个在 2023 年训练的模型不知道 2024 年发生的新闻。

○解决方案：当被问及一个新事件时，AI 可以使用搜索引擎 API 查询最新的新闻和信息，然后根据这些实时信息来生成答案。

○例子：你问 AI：“昨天的股市收盘价是多少？” AI 无法直接回答，但它可以调用一个金融搜索引擎 API，获取数据后再告诉你。

2.提高事实准确性，减少 “幻觉”

○问题：AI 有时会 “一本正经地胡说八道”，即编造一些看似合理但实际上是错误的信息，这被称为 “幻觉” (Hallucination)。

○解决方案：在回答需要精确事实的问题时，AI 可以先通过搜索引擎进行事实核查。它将搜索到的可靠来源（如维基百科、官方新闻稿）作为其回答的基础，而不是凭空捏造。

○例子：你问 AI：“X 公司的 CEO 是谁？” AI 不会直接猜测，而是会先搜索 “X company CEO”，找到官方信息后再给出准确答案。

3.提供信息来源和可信度

○通过搜索引擎，AI 不仅能给出答案，还能提供它获取信息的来源链接。这大大增强了答案的可信度，也允许用户自行验证。证许多现代的 AI 问答产品（如 Perplexity AI, Google’s Gemini）都会在回答下方附上参考链接。

4.执行需要实时数据的复杂任务

○问题：许多现实世界的任务依赖于动态变化的信息。

○解决方案：AI 代理 (AI Agent) 可以利用搜索引擎来完成任务。

○例子：一个 “旅行规划 AI” 需要查询实时的航班价格、酒店空房情况、目的地天气预报等。它会通过调用多个不同的搜索服务 API 来收集所有这些信息，然后为你制定一个完整的旅行计划。

“给 AI 用的搜索引擎” 本质上是将互联网从一个为人类视觉设计的、非结构化的信息海洋，转变成一个为机器准备的、结构化的、可查询的知识库。它赋予了 AI 模型一双能 “看到” 并 “理解” 当前世界的眼睛，使其能够突破自身训练数据的限制，变得更加准确、实时、可信和强大。

流程示意

以下为一个 AI 应用 Action 的示意图：

供应商

提供 web search 能力的供应商有很多，我们选择了几家知名和流行的厂商作为选型参考：

●Tavily :https://www.tavily.com/

●SerpApi:https://serpapi.com/

●Serper API:https://serper.dev/

●Exa.ai:https://exa.ai/

●Ollama Web Search:https://docs.ollama.com/capabilities/web-search

●Jina.ai DeepSearch:https://jina.ai/deepsearch/

●Brave Search:https://brave.com/search/api/

Tavily

Tavily 是一个面向 LLM 与 AI 智能体的 “Web 接入层”—— 提供实时网络搜索与内容提取的 API，常用于 RAG（检索增强生成）和各类智能体工作流，目标是把 “上网检索→抓取→清洗→结构化” 的繁琐流程封装成简单、可控的接口。

核心 API

●Search：发送查询；可调搜索深度、时间范围、域名白/黑名单等，返回已清理的相关片段与链接，并可选生成简短回答/返回图片结果。

●Extract：按给定 URL 抽取网页全文（可选 Markdown 或纯文本，也可返回图片），便于直接供模型使用。

●Crawl：图式并行爬取整站（带内置抽取与智能发现），适合做站点级信息收集。

●Map（Beta）：生成站点地图/URL 列表，可设置深度、广度及路径/域名过滤。

适用场景与优势

●给 RAG、聊天助手、数据富集等提供实时、可追溯的外部信息；返回结果强调带来源引用与面向 LLM 的片段，以降低幻觉并提升可审计性

●官方定位是 “为智能体提供上网能力的基础层”，强调速度、稳定性与与开发者 / 智能体工作流的适配。

生态与集成

提供官方 Python/JavaScript SDK 与在线 Playground；并与 LangChain、LlamaIndex 等框架集成，便于直接接入现有 Agent / RAG 管道。

接入示例：

 1⚡ python片段"""
 2Tavily Search API - 超简洁版
 3"""
 4
 5import os
 6from dotenv import load_dotenv
 7from tavily import TavilyClient
 8
 9load_dotenv()
10
11# 创建客户端
12client = TavilyClient(api_key=os.getenv("TAVILY_API_KEY"))
13
14# 搜索
15query = input("搜索: ")
16response = client.search(query=query)
17
18# 打印结果
19print(response)

价格与配额

SerpApi

SerpApi 是一个付费的第三方 API 服务，它能让你实时地抓取并解析来自 Google、Bing、Baidu 等多个主流搜索引擎的搜索结果页面（SERP），并以结构化的 JSON 格式返回给你。

你可以把它理解成一个 “超级加强版” 的、非官方的搜索引擎 API。它解决的核心问题是：官方的 Google API 返回的结果有限且不完整，而自己去抓取（Scrape）Google 又极其困难。 SerpApi 就是填补这个鸿沟的商业解决方案。

可以看到它的 API 还是很丰富的：

SerpApi 和 Tavily AI 都是服务于 AI 应用的搜索 API，但它们在哲学、目标和返回内容上有着根本性的不同。用一个简单的比喻来开始：

●SerpApi 像是给了你的 AI 一整箱乐高积木的原始零件。它提供了关于搜索结果页面的所有原始、详细、未经处理的数据。

●Tavily AI 像是给了你的 AI 一个根据说明书预先拼好了大半的乐高模型。它为你完成了搜索、筛选、阅读和总结的步骤，直接提供给 AI 一个接近最终答案的、简洁的信息包。

核心 API

SerpApi 的核心是一个简单而强大的 REST API，其本质是 “搜索结果页面即服务” (SERP as a Service) 。

●工作机制: 你通过一个标准的 GET 请求，向 SerpApi 的端点（Endpoint）发送查询，它会返回一个结构化的 JSON 对象，该对象完整地描述了真实搜索引擎的结果页面。

●关键参数:

○api_key: (必需) 用于账户认证的密钥。

○engine: (必需) 指定要查询的搜索引擎。这是其强大功能的体现，例如 google, Maps, google_jobs, bing, baidu, duckduckgo, youtube, amazon 等。

○q: (必需) 你要搜索的关键词。

○location: (可选, 但非常重要) 模拟搜索的地理位置。你可以传递一个具体的城市名、国家，甚至精确的地理坐标，来获取高度本地化的结果。例如，你可以轻松模拟一出来自东京涩谷的搜索请求。

○gl & hl: 分别指定搜索的国家（geolocation）和语言（host language），例如 gl=jp 和 hl=ja 来获取日本的日语结果。

○start, num: 用于翻页，控制搜索结果的偏移量和数量。

●核心产出: API 的输出是其最核心的价值 —— 一个经过深度解析的、结构化的 JSON。这个 JSON 不仅包含自然搜索结果（蓝链），还精确地解析了页面上几乎所有的动态元素，包括：

○广告 (Ads)

○知识图谱 (Knowledge Graph)

○本地包 / 地图包 (Local Pack)

○相关问题 (People Also Ask)

○购物结果 (Shopping Results)

○图片和视频轮播 (Carousels)

适用场景与优势

SerpApi 的价值在于它为需要高质量、真实搜索引擎数据的用户解决了最棘手的技术难题。

●适用场景:

○SEO / SEM 行业: 监控关键词排名、跟踪竞争对手的广告投放策略、分析 SERP 页面特性。

○市场研究与商业智能: 聚合来自 Google Shopping 或 Amazon 的商品价格、分析特定行业的市场趋势、监控品牌在网络上的提及。

○AI 与大语言模型 (LLM): 作为 AI Agent 的 “眼睛”，为其提供高质量、实时的外部世界信息源，用于需要完整页面上下文的 RAG（检索增强生成）系统或事实核查。

○本地化服务: 验证本地商家的地图排名、聚合特定区域的服务信息。

●核心优势:

○数据的完整性与真实性: 最大的优势。它提供的是真实用户所见的完整页面镜像，而非官方 API 提供的阉割版数据。

○规避所有抓取障碍: 用户无需担心 IP 封锁、代理管理、浏览器指纹以及最令人头疼的 CAPTCHA（人机验证）。SerpApi 在后端完全处理了这些问题。

○强大的本地化和定制能力: location 参数功能强大，可以实现全球任意地点的精准模拟搜索。

○广泛的平台支持: 一个 API 接口即可访问全球几十个主流的搜索引擎和电商平台。

生态与集成

SerpApi 非常注重开发者体验，已经建立了一个成熟的生态系统，使其能够轻松地集成到现有工作流中。

●官方编程语言库: 提供了对主流语言的官方支持，包括 Python, Node.js, Ruby, Java, PHP, Go, C# 等。这使得开发者可以在几分钟内就开始调用 API，而无需手动构建 HTTP 请求。

●与 AI 框架的深度集成: 在当前的 AI 浪潮中，SerpApi 已成为标准工具之一。它被深度集成到 LangChain 和 LlamaIndex 等主流 AI 开发框架中，通常作为一个开箱即用的 Tool 或 Wrapper 存在，方便 AI Agent 直接调用。

●无代码 / 低代码平台集成: 支持 Zapier, Make (原 Integromat) 等自动化平台，让非程序员也能利用其强大的数据抓取能力来构建自动化流程。

●完善的文档与工具: 提供了交互式的 API 文档（Playground），用户可以在网页上直接测试各种参数组合，并实时查看返回的 JSON 结果，极大地降低了学习和调试成本。

接入示例：

 1⚡ python片段"""
 2SerpApi Search API - 超简洁版
 3Google 搜索引擎爬取 API
 4"""
 5
 6import os
 7from dotenv import load_dotenv
 8from serpapi import GoogleSearch # type: ignore[import-untyped]
 9
10load_dotenv()
11
12# 创建搜索参数
13query = input("搜索: ")
14params = {
15 "q": query,
16 "api_key": os.getenv("SERPAPI_API_KEY"),
17 "num": 5, # 返回 5 条结果
18}
19
20# 执行搜索
21search = GoogleSearch(params)
22results = search.get_dict()
23
24# 打印结果
25print(f"\n🔍 搜索结果: {query}\n")
26print("=" * 60)
27
28# 显示有机搜索结果
29organic_results = results.get("organic_results", [])
30for idx, result in enumerate(organic_results, 1):
31 print(f"\n【{idx}】 {result.get('title', '无标题')}")
32 print(f"🔗 {result.get('link', '')}")
33 print(f"📝 {result.get('snippet', '无描述')}")
34
35print("\n" + "=" * 60)
36print(f"✅ 共找到 {len(organic_results)} 条结果")

价格与配额

Serper

Serper.dev 在搜索引擎 API 市场中扮演了一个非常独特的、具有破坏性的角色。你可以将 Serper.dev 理解为一个主打极致速度和极具竞争力的低廉价格的挑战者。它专注于做好一件事 —— 提供 Google 搜索结果 —— 并力求比任何竞争对手都更快、更便宜。

Serper.dev 的存在就是为了解决 SerpApi 等传统服务存在的两个痛点：响应慢和价格贵。

1.速度 (Speed): Serper.dev 的首要卖点是其极低的延迟。它通过自建的、高度优化的反向代理和缓存系统，能够在极短时间内返回 Google 的搜索结果。对于需要实时交互的应用（例如，与用户对话的 AI 聊天机器人），这种低延迟是至关重要的。

成本效益 (Cost-Effectiveness): 这是它最大的颠覆之处。Serper.dev 的定价策略非常激进，其单位搜索成本远低于 SerpApi。它提供了一个极其慷慨的免费套餐，并且付费套餐的价格也很有吸引力，这使得它对个人开发者、初创公司和需要大规模搜索但预算有限的项目极具诱惑力。

实测下来，Serper确实是最快的。

核心 API

●API 类型: 同样是简单易用的 REST API。

●端点: 主要提供 /search 端点用于网页搜索，以及 /images 等用于图片搜索的特定端点。

●关键参数: 与 SerpApi 非常相似，包括 q (查询), gl (国家), hl (语言), location (地理位置) 等，使其易于上手和迁移。

●核心产出: 返回与 SerpApi 类似、结构清晰的 JSON 对象，其中包含了 Google SERP 的主要元素，如自然结果、广告、知识图谱、相关问题等。

适用场景与优势

●适用场景:

○实时 AI 对话应用: 当 AI 需要在对话中快速查找信息时，Serper 的低延迟可以避免让用户感到明显的等待。

○大规模数据采集: 当项目需要百万级别的搜索量时，Serper 的低成本优势会变得极为显著。

○初创公司和独立开发者: 慷慨的免费套餐和低廉的付费门槛，使其成为验证想法（MVP）和开发早期产品的理想选择。

○任何以 Google 搜索为主要信息源且对成本和速度敏感的应用。

●核心优势:

○快: 无与伦比的响应速度。

○省钱: 极低的单位搜索成本和慷慨的免费额度。

○简单: API 设计直观，专注于核心功能，没有过多复杂选项。

生态与集成

●与 AI 框架的集成: Serper.dev 同样是 LangChain 和 LlamaIndex 生态系统中的一等公民。它作为一个标准的 Tool 或 Wrapper 被广泛支持，许多教程和项目都因其性价比而推荐使用它。

●编程语言支持: 虽然可能没有像 SerpApi 那样提供十几种语言的官方库，但由于其 API 简单，通过任何支持 HTTP 请求的语言（如 Python, Node.js）进行集成都非常容易。

●社区认知度: 在 AI 开发者社区中，Serper.dev 因其出色的性价比而广为人知，并经常被推荐为 SerpApi 的首选替代品。

接入示例：

 1⚡ python片段"""
 2Serper.dev Search API - 超简洁版
 3更快更便宜的 Google 搜索 API
 4"""
 5
 6import os
 7import requests # type: ignore[import-untyped]
 8from dotenv import load_dotenv
 9
10load_dotenv()
11
12# API 配置
13API_KEY = os.getenv("SERPER_API_KEY")
14API_URL = "https://google.serper.dev/search"
15
16# 搜索
17query = input("搜索: ")
18response = requests.post(
19 API_URL,
20 headers={"X-API-KEY": API_KEY, "Content-Type": "application/json"},
21 json={"q": query, "num": 5},
22)
23
24results = response.json()
25
26# 打印结果
27print(f"\n🔍 搜索结果: {query}\n")
28print("=" * 60)
29
30for idx, result in enumerate(results.get("organic", []), 1):
31 print(f"\n【{idx}】 {result.get('title', '无标题')}")
32 print(f"🔗 {result.get('link', '')}")
33 print(f"📝 {result.get('snippet', '无描述')}")
34
35print("\n" + "=" * 60)
36print(f"✅ 共找到 {len(results.get('organic', []))} 条结果")

价格与配额

这是 Serper.dev 最闪亮的标签。

●免费套餐: 提供每月 2,500 次的免费搜索，足以满足大多数个人项目和小型应用的开发与测试需求。

●付费模式: 订阅制。其付费套餐的性价比极高，例如，每月支付少量费用（例如 10 美元）就可以获得数万次的搜索量，这个数量在 SerpApi 上可能需要花费高出数倍甚至一个数量级的费用。

●定价哲学: 薄利多销。通过低价吸引大量用户，尤其是在 AI 应用爆发增长的背景下，这种策略非常成功。

Exa.ai

如果我们说 SerpApi / Serper 是对传统关键词搜索引擎的 “API 化”，Tavily 是为 AI “优化答案”，那么 Exa.ai (其前身为 Metaphor) 则是一种完全不同类型的搜索引擎。它不是一个传统的 “关键词搜索引擎” 的 API 封装，而是一个为 AI 和大型语言模型 (LLM) 从头构建的 “神经搜索引擎” 或 “概念搜索引擎”。

核心理念：搜索 “概念”，而非 “关键词”

Exa.ai 最根本的不同在于它的搜索方式。它不依赖于你输入精确的关键词，而是让你用自然语言描述你想要找的 “那种” 内容。Exa 的底层是一个大型的 Transformer 模型，它被训练来理解网页内容之间的关系和 “意义”，而不是仅仅索引它们的文字。

举个例子来理解这种差异：

●传统关键词搜索 (SerpApi/Serper/Tavily): 你想找一些关于日本小众旅行地的深度文章，你可能会输入关键词：“日本深度游博客” 或 “Japan hidden gems travel blog”。

○返回的结果会是那些包含了这些关键词的页面，质量良莠不齐。

●Exa.ai 概念搜索: 你可以直接告诉它你的意图: “请给我找一些关于日本旅行的、写得像诗一样优美的个人博客，内容要侧重于当地文化体验，而不是热门旅游景点。”

○Exa 会理解 “诗一样优美”、“侧重文化体验”、“非热门景点” 这些抽象概念，然后返回那些在内容和风格上与你的描述相匹配的链接，即使这些页面中根本没有出现你用到的描述词。

Exa.ai 不是用来替代 Google 搜索的，而是为需要进行深度研究、发现和内容探索的 AI 系统提供了一种全新的、更强大的工具。如果说 SerpApi / Serper 是给了 AI 一张 “地图”，Tavily 是给了 AI 一个 “向导”，那么 Exa.ai 则是给了 AI 一个拥有直觉和品味的 “图书管理员” 或 “研究伙伴”。它开启了让 AI 从 “信息检索者” 向 “知识发现者” 转变的可能性。

核心 API

Exa 的 API 设计完全体现了其 “概念驱动” 的哲学，主要有三个强大的端点：

1./search: 核心的搜索功能。接收一个自然语言描述作为查询，返回一个按相关性排序的链接列表。

2./findSimilar: 极具特色的功能。你给它一个 URL，它会返回一串内容和风格上都与这个 URL “相似” 或 “同类” 的其他链接。这对于构建推荐引擎或进行深度研究非常强大。

3./contents: 检索和内容提取功能。你给它一个或多个搜索结果的 ID，它能直接返回这些页面的干净、去除了广告和无关元素的文本内容，可以直接作为上下文喂给 LLM。这相当于集成了搜索和内容抓取两步。

适用场景与优势

●适用场景:

○高级 AI 研究代理 (Agent): 构建能够进行深度、开放式研究的 AI 代理，而不仅仅是查找孤立的事实。

○内容发现与推荐: 帮助用户发现他们可能喜欢但难以用关键词描述的新博客、文章或资源。

○高质量 RAG: 为 RAG 系统寻找特定领域、特定风格或特定深度的高质量信息源，以提升生成内容的质量。

○个人知识管理: 根据一篇你喜欢的文章，发现更多类似的高质量内容来拓展你的知识边界。

●核心优势:

○超越关键词的理解力: 能够理解抽象的意图和概念，找到 “隐藏的宝藏”。

○发现高质量内容: 其模型倾向于发现更高质量、更独特的内容，而不是被 SEO 优化的普通页面。

○独特的 “相似性” 搜索: /findSimilar 功能是独一无二的，开辟了新的应用可能性。

○端到端的内容获取: /contents API 将搜索和内容提取无缝衔接，极大简化了 RAG 流程。

生态与集成

Exa.ai 在 AI 开发者社区中，尤其是在那些探索 Agentic AI 和高级 RAG 的前沿开发者中，声名鹊起。

●AI 框架: 它是 LangChain 和 LlamaIndex 的官方集成工具，被认为是构建复杂研究型 Agent 的首选工具之一。

●社区定位: 它被社区视为一个 “专家级” 工具，用于解决传统搜索引擎无法处理的、更偏向 “探索与发现” 而非 “查找与验证” 的任务。

接入示例：

 1⚡ python片段"""
 2Exa.ai Search API - 超简洁版
 3专为 AI 设计的语义搜索引擎
 4"""
 5
 6import os
 7from dotenv import load_dotenv
 8from exa_py import Exa # type: ignore
 9
10load_dotenv()
11
12# 创建客户端
13client = Exa(api_key=os.getenv("EXA_API_KEY"))
14
15# 搜索
16query = input("搜索: ")
17results = client.search_and_contents(query, num_results=5, text=True)
18
19# 打印结果
20print(f"\n🔍 搜索结果: {query}\n")
21print("=" * 60)
22
23for idx, result in enumerate(results.results, 1):
24 print(f"\n【{idx}】 {result.title}")
25 print(f"🔗 {result.url}")
26 if result.text:
27 snippet = result.text[:200].replace("\n", " ")
28 print(f"📝 {snippet}...")
29
30print("\n" + "=" * 60)
31print(f"✅ 共找到 {len(results.results)} 条结果")

价格与配额

●定价模型: 采用基于用量的定价模式。通常会有一个免费的开发者额度，用于测试和小型项目。

●计费方式: 它的计费可能比其他服务稍复杂，因为它有不同的 API 端点。通常，一次 /search 或 /findSimilar 调用会消耗一定数量的 “API 单元”，而一次 /contents 调用（因为它涉及实际的网页抓取和解析）会消耗更多的 “API 单元”。

●成本考量: 相对于 Serper 这样的低成本关键词搜索，Exa 的单次查询成本更高。它的价值不在于便宜，而在于它能做到其他搜索引擎做不到的事情。

Ollama Web Search

Ollama 公司官方直接提供了一个云端 Web 搜索 API 服务。个人用户完全免费

核心 API

●服务类型: 一个由 Ollama 公司直接运营和维护的托管式 (Managed) REST API。

●核心功能: 接收用户的自然语言查询，访问互联网，并返回相关的搜索结果。Ollama 在后端处理了所有的复杂性，包括选择搜索引擎、处理反爬虫、解析结果等。对用户来说，它是一个单一、可靠的入口。

●简易性: API 的设计极致简约，如您的代码所示，只有一个端点、一种认证方式和一个核心参数，几乎没有学习成本。

适用场景与优势

●适用场景:

○快速原型开发: 开发者可以立刻为他们的应用添加联网搜索功能，而无需注册和配置多个服务。

○Ollama 生态内的应用: 与在本地运行的 Ollama 模型无缝集成，是官方推荐的、最简单的联网方式。

○任何需要简单、免费搜索功能的项目: 由于其易用性和免费特性，它适用于各种轻量级的 AI 聊天、RAG 应用或自动化脚本。

●核心优势:

○极致简化 (Extreme Simplicity): 这是其最大的优势。开发者不再需要 “Ollama + 第三方搜索 API” 的组合，只需要一个 Ollama 账户和 API 密钥，即可搞定一切。

○免费或极低成本: 根据您的信息，免费提供这一点使其在成本上无与伦比。

○无缝的生态集成: 作为官方服务，它能保证与 Ollama 的其他产品（无论是本地运行的开源工具还是未来可能推出的云端服务）达到最完美的兼容性。

○单一供应商: 无需管理多个供应商的账户、API 密钥和账单，降低了管理复杂性。

生态与集成

●核心定位: 它是 Ollama 自身生态系统的官方、原生搜索解决方案。它的主要目标是服务于使用 Ollama 运行模型的广大开发者。

●通用性: 尽管它与 Ollama 生态紧密相连，但从您的代码可以看出，它是一个标准的 REST API，可以被任何应用程序、任何编程语言独立调用，完全不依赖于本地的 Ollama 运行环境。

●未来潜力: 这种模式为 Ollama 未来的发展铺平了道路，例如推出官方托管的 LLM 推理服务，并与此搜索服务打包，提供一站式的 “模型 + 搜索” 解决方案。

接入示例：

 1⚡ python片段"""
 2Ollama Web Search - 超简洁版
 3文档: https://docs.ollama.com/capabilities/web-search
 4"""
 5
 6import os
 7import requests
 8from dotenv import load_dotenv
 9
10load_dotenv()
11
12# API 配置
13api_key = os.getenv("OLLAMA_API_KEY")
14url = "https://ollama.com/api/web_search"
15
16# 搜索
17query = input("搜索: ")
18response = requests.post(
19 url, headers={"Authorization": f"Bearer {api_key}"}, json={"query": query}
20)
21
22# 打印结果
23print(response.json())

价格与配额

●当前模式: 根据您的信息和代码示例，该服务目前是免费提供的。

●可能的未来: 行业内常见的模式是提供一个非常慷慨的免费层级（Free Tier），足以满足绝大多数个人开发者和小型项目的需求。对于超出免费额度的大规模商业应用，未来可能会推出付费的专业版套餐（Pro Tier），提供更高的请求速率限制、更大的请求量和更强的技术支持。

Jina AI DeepSearch

Jina AI 是一家专注于神经搜索（Neural Search）和多模态 AI 的公司，他们的 DeepSearch 服务是其核心产品之一。DeepSearch 与我们之前讨论的 SerpApi、Serper、Tavily，甚至 Exa.ai 都有所不同，它更侧重于语义理解和基于向量嵌入（Embeddings）的内容搜索，而不是简单地抓取关键词或提供预设的答案摘要。

可以将 DeepSearch 理解为一个允许你构建和查询自己的语义搜索引擎的平台。它不仅仅是帮你 “搜索 Google”，更是帮你 “理解和搜索你自己的数据，以及整个网络上与你概念相关的数据”。

Jina AI 的 DeepSearch 代表了搜索引擎的未来方向之一：从基于字符串匹配的 “关键词搜索” 转向基于语义理解和概念匹配的 “神经搜索”。它对于需要构建能够真正 “理解” 用户意图并发现深层相关内容的 AI 应用来说，是一个强大而高级的工具。如果你的项目需要超越传统搜索的语义能力，尤其是在处理非结构化数据、进行深度内容发现和构建智能 RAG 系统时，DeepSearch 是一个非常值得考虑的选择。

核心 API

Jina AI DeepSearch 的核心是一个强大的神经搜索 API，其能力基于向量嵌入和语义匹配。

●核心理念: 它不依赖于关键词匹配，而是通过将文本、图像、视频等各种模态的数据转化为高维向量（Embeddings）。当用户发起查询时，查询本身也被转化为向量，然后在大规模的向量数据库中进行语义相似性匹配，找到概念上最相关的内容。

●主要功能:

○语义搜索: 用户可以用自然语言描述其意图或提供一个内容片段（文本、URL），DeepSearch 会返回语义上最相关的内容，即使这些内容不包含任何关键词。

○多模态搜索: 能够处理和搜索不同类型的数据，理论上包括文本、图片、音频、视频等（尽管其网页搜索功能主要集中在文本和图片上）。

○自定义数据集索引: 用户可以将自己的数据（例如公司的文档库、产品目录、内部知识库）上传并索引到 DeepSearch 中，构建一个完全语义化的内部搜索引擎。

○网页抓取与索引: DeepSearch 提供了抓取网页并将其内容向量化的能力。这意味着你可以用它来构建一个基于语义的、针对特定网站或整个网络的索引。

○上下文增强: 返回的不仅仅是链接，通常还会包含抓取到的、与查询相关的页面文本片段，非常适合作为 LLM 的上下文。

●产出: API 会返回一个包含相关结果的列表，每个结果通常包括：原始 URL、页面标题、抓取到的相关文本片段，以及一个表示语义相关性的得分。

适用场景与优势

DeepSearch 的优势在于其深度语义理解能力，使其在传统关键词搜索力不从心的地方大放异彩。

●适用场景:

○高级 RAG 系统: 为 LLM 提供高度相关的、语义化的上下文。当 LLM 需要的不是 “包含这些关键词的页面”，而是 “概念上与此主题最接近的深度分析” 时，DeepSearch 就能发挥作用。

○内部知识库搜索: 企业可以利用它构建一个能够理解员工自然语言提问、并提供最相关内部文档的搜索引擎。

○内容推荐与发现: 基于用户阅读过的内容（URL 或文本），通过语义相似性发现更多高质量、风格或主题相似的内容。

○创新型搜索引擎: 构建更智能、更具洞察力的搜索引擎，例如根据产品描述找到最相似的产品，或根据图片找到相关描述的文本。

○开放域问答: 提供超越关键词匹配的、更智能的答案来源。

●核心优势:

○语义理解: 最核心的优势。它理解查询和内容背后的 “意义”，而非表面的词语。这避免了 “关键词陷阱” 和同义词问题。

○高质量的相关性: 能够发现传统搜索难以找到的、但在概念上高度相关的内容。

○多模态潜力: 为未来处理更复杂的多模态信息奠定基础。

○高度可定制: 允许用户索引自己的数据，构建定制化的神经搜索体验。

○解决 “搜索长尾” 问题: 对于非常具体、小众、难以用关键词描述的查询，其语义匹配能力更强。

生态与集成

Jina AI 在开源社区和 AI 框架中都有很强的存在感，DeepSearch 也受益于此。

●Jina 生态系统: Jina AI 提供了包括 Jina Core (构建神经搜索应用的框架)、DocArray (用于处理多模态数据的库) 等一系列工具。DeepSearch 是这个生态中的一个商业化服务。

●与 LLM 框架集成: 作为先进的搜索解决方案，DeepSearch 也被集成到 LangChain 和 LlamaIndex 等主流的 AI 框架中，作为 Retriever（检索器）或 Tool（工具）使用。

●开发者工具: Jina AI 提供了易于使用的客户端库和详细的文档，方便开发者快速集成其 API。

接入示例：

 1⚡ python片段"""
 2Jina AI DeepSearch API - 超简洁版
 3AI 驱动的深度搜索引擎
 4"""
 5
 6import os
 7import requests # type: ignore[import-untyped]
 8from dotenv import load_dotenv
 9
10load_dotenv()
11
12# API 配置
13API_KEY = os.getenv("JINA_API_KEY")
14API_URL = "https://s.jina.ai/"
15
16# 搜索
17query = input("搜索: ")
18headers = {
19 "Authorization": f"Bearer {API_KEY}",
20 "Accept": "application/json",
21}
22
23response = requests.get(f"{API_URL}{query}", headers=headers)
24results = response.json()
25
26# 打印结果
27print(f"\n🔍 搜索结果: {query}\n")
28print("=" * 60)
29
30data = results.get("data", [])
31for idx, result in enumerate(data[:5], 1):
32 print(f"\n【{idx}】 {result.get('title', '无标题')}")
33 print(f"🔗 {result.get('url', '')}")
34 description = result.get("description", result.get("content", ""))
35 if description:
36 snippet = description[:200].replace("\n", "")
37 print(f"📝 {snippet}...")
38
39print("\n" + "=" * 60)
40print(f"✅ 共找到 {len(data)} 条结果")

价格与配额

相较于关键词抓取服务（如 Serper），或者纯粹的答案摘要服务（如 Tavily），由于其底层的向量嵌入和语义匹配计算成本较高，DeepSearch 的单次查询或数据处理成本可能相对更高。但其提供的是更高的价值和更深层次的语义理解。

Brave Search

Brave Search 代表了搜索引擎领域中一股独特而强大的力量：真正的独立性。与我们之前讨论的许多依赖于 Google 或 Bing 数据的服务不同，Brave 从头构建了自己独立的网络索引，这使其在市场上独树一帜。

Brave Search 的诞生源于对 Google 和 Bing 在搜索领域双头垄断的担忧。其核心使命是提供一个不依赖于大型科技公司、注重隐私、并能提供无偏见结果的替代品。它的 API 让你能够以编程方式访问这个独特的、独立的索引。

核心 API

https://api-dashboard.search.brave.com/app/documentation/web-search/get-started

●独立索引 (Independent Index): 这是它最核心、最与众不同的特点。当你调用 Brave Search API 时，你查询的是 Brave 自己爬虫和算法构建的数据库，而不是 Google 或 Bing 的 “二手数据”。这意味着你能得到一套可能完全不同的、未经主流引擎过滤的结果。

●Goggles 功能: 这是一个非常独特的创新功能，也通过 API 提供。Goggles 允许用户创建或使用自定义的 “规则集” 来重新排序搜索结果。例如，你可以应用一个 “反科技巨头” 的 Goggle，它会自动降低大型科技公司网站的排名；或者应用一个 “学术优先” 的 Goggle，来优先显示学术论文和研究。

●多类型搜索: API 支持多种搜索类型，包括网页搜索 (web)、新闻搜索 (news)、视频搜索 (videos) 等。

●简洁的 API 设计: API 的端点和参数设计得非常直观，包括 q (查询), country, search_lang 等标准参数，易于开发者上手。

●核心产出: 返回一个干净的、结构化的 JSON 对象，其中包含了各种类型的搜索结果，以及丰富的元数据。

适用场景与优势

选择 Brave Search API 通常是基于对其核心理念的认同，以及对其独特优势的需求。

●适用场景:

○注重隐私的应用: 对于不想将用户数据和查询历史发送给 Google 或 Bing 的应用来说，Brave 是理想选择。

○需要 “第二意见” 的工具: 在研究、分析或事实核查应用中，可以同时调用 Brave API 和其他主流 API，为用户提供一个对比视角，打破 “信息茧房”。

○构建新型 AI Agent: 为 AI 代理提供一个非主流、可能更少偏见的信源，以获得更多样化的观点和信息。

○新闻聚合与分析: 利用其独立的新闻索引来发现可能被主流引擎忽略的报道。

●核心优势:

○真正的独立性: 结果不受 Google 或 Bing 排名算法的影响，提供了真正的多样性。

○隐私保护: 继承了 Brave 浏览器对用户隐私的承诺，API 调用不会被用于用户画像分析。

○无偏见的结果: Brave 声称其排名算法旨在提供最相关、最公正的结果，减少商业化和 SEO 的过度影响。

○创新的 Goggles 功能: 提供了前所未有的结果定制能力，让开发者可以根据特定需求对结果进行重新排序。

生态与集成

作为一个现代化的 API 服务，Brave Search 非常注重开发者生态。

●AI 框架集成: 它被迅速地集成到了 LangChain 和 LlamaIndex 等主流 AI 开发框架中。开发者可以非常轻松地将其作为一个 Tool 或 Retriever 添加到自己的 AI 应用中，这极大地推动了它在 AI 社区的普及。

●易于使用: 作为一个标准的 REST API，它可以被任何编程语言轻松调用。官方文档清晰，API 控制台 (api-dashboard) 直观易用。

●社区支持: 围绕 Brave 的隐私和独立理念，已经形成了一个强大的开发者和用户社区。

接入示例：

 1⚡ python片段"""
 2Brave Search API - 超简洁版
 3独立索引的隐私优先搜索引擎 API
 4"""
 5
 6import os
 7import requests # type: ignore[import-untyped]
 8from dotenv import load_dotenv
 9
10load_dotenv()
11
12# API 配置
13API_KEY = os.getenv("BRAVE_API_KEY")
14API_URL = "https://api.search.brave.com/res/v1/web/search"
15
16if not API_KEY:
17 print("❌ 错误：请设置 BRAVE_API_KEY 环境变量")
18 print("提示：在 .env 文件中添加：BRAVE_API_KEY=your_key_here")
19 exit(1)
20
21# 搜索
22query = input("搜索: ")
23headers = {
24 "Accept": "application/json",
25 "Accept-Encoding": "gzip",
26 "X-Subscription-Token": API_KEY,
27}
28params = {"q": query, "count": 5}
29
30try:
31 response = requests.get(API_URL, headers=headers, params=params)
32 response.raise_for_status()
33 results = response.json()
34except requests.exceptions.RequestException as e:
35 print(f"❌ 请求错误: {e}")
36 ifhasattr(e.response, "text"):
37 print(f"响应: {e.response.text}")
38 exit(1)
39
40# 打印结果
41print(f"\n🔍 搜索结果: {query}\n")
42print("=" * 60)
43
44web_results = results.get("web", {}).get("results", [])
45if not web_results:
46 print("⚠️ 未找到搜索结果")
47 print(f"API 响应: {results}")
48else:
49 for idx, result in enumerate(web_results, 1):
50 print(f"\n【{idx}】 {result.get('title', '无标题')}")
51 print(f"🔗 {result.get('url', '')}")
52 description = result.get("description", "")
53 if description:
54 # 移除 HTML 标签
55 clean_desc = description.replace("<strong>", "").replace("</strong>", "")
56 snippet = clean_desc[:200].replace("\n", "")
57 print(f"📝 {snippet}...")
58
59 print("\n" + "=" * 60)
60 print(f"✅ 共找到 {len(web_results)} 条结果")

价格与配额

Brave Search API 的定价模型旨在吸引从个人开发者到大型企业的各类用户，具有很强的竞争力。

●免费套餐 (Free Plan): 提供一个非常慷慨的免费层级，通常每月提供多达 2,000 次的免费查询。这足以满足绝大多数个人项目、开发测试和小型应用的需求。

●付费套餐 (Paid Plans): 对于需要更高查询量的用户，提供了多个付费订阅套餐。

○付费套餐的起步价非常亲民（例如，每月几美元即可获得数万次查询）。

○其单位查询成本在整个行业中都非常有竞争力，使其成为 SerpApi 等高端服务的低成本、高质量替代品。

●定价哲学: 通过提供高性价比的服务来鼓励开发者使用其独立的索引，从而挑战现有市场格局，推动一个更开放、更多样化的网络。

其他厂家

还有一些其它的厂商也提供类似服务，比如国内的：

●https://open.bochaai.com/

●https://aisearch.anspire.cn/

选型建议

我们快速回顾一下各个供应商的核心定位：

●Tavily: 专为 AI Agent 和 RAG 设计的 “答案层” API，强调对搜索结果的清洗、总结和整合，直接输出对 LLM 友好的内容

●SerpApi: 功能最全面的 “数据层” API，精确抓取并解析 Google、Bing、Baidu 等几十个平台的完整 SERP（搜索结果页面），数据极其丰富

●Serper: SerpApi 的挑战者，主打极致的速度和极低的价格，专注于提供 Google 搜索结果

●Exa.ai: “概念搜索引擎”，使用自然语言描述进行搜索，能理解抽象意图，擅长内容发现和深度研究，而非简单的关键词匹配

●Ollama Web Search: Ollama 官方提供的免费云端 API 服务，极致简化，与 Ollama 生态无缝集成

●Jina.ai DeepSearch: 强大的 “神经搜索引擎”，基于向量嵌入进行语义搜索，支持自定义数据索引和多模

●Brave Search: 建立在独立网络索引之上的搜索引擎，主打隐私保护和不受主流引擎影响的 “第二意见” 结果

综合对比与分析

我们将从响应速度、成本、功能、易用性和适用场景五个维度进行详细对比。

响应速度

经过本地实测，响应速度上 Brave Search 和 SerpApi 是伯仲之间

 1⚡ 代码片段======================================================================
 2🏆 响应速度排名（从快到慢）
 3======================================================================
 4🥇 1. SerpApi 627ms
 5🥈 2. Brave Search 662ms
 6🥉 3. Tavily 976ms
 7 4. Serper.dev 1.35s
 8 5. Exa.ai 2.29s
 9 6. Jina AI 4.66s
10
11======================================================================

成本

成本是选型的关键，我们从业余 / 开发阶段到大规模生产阶段进行考量

成本排序（从低到高）：

Ollama > Serper > Brave > Tavily > Exa.ai > Jina.ai > SerpApi

功能

易用性

●最简单: Ollama Web Search。官方原生，一个 API Key 解决所有问题，无需任何第三方配置。

●非常简单: Serper, Brave, Tavily。都是标准的 REST API，API 设计直观简洁，且都深度集成了 LangChain 等 AI

●中等: SerpApi。功能非常多，参数复杂，但因为有完善的文档、工具和多语言库，集成也相对顺畅

●较复杂 / 需理解新概念: Exa.ai, Jina.ai。它们引入了新的搜索范式（概念搜索、神经搜索），需要开发者改变传统的 “关键词思维” 才能发挥其最大价值

适用场景

●需要最高性价比、大规模获取 Google 结果: Serper 是不二之选

●快速原型、个人项目或 Ollama 生态内应用: Ollama Web Search 的免费和简易性使其成为首选

●注重隐私、需要独立 / 差异化结果源: Brave Search 是最佳选择。

●构建高质量 RAG 或 AI Agent: Tavily 经过优化的输出能显著提升效果和效率，是此场景的理想选择

●需要完整、真实的 SERP 数据用于 SEO 或市场分析: SerpApi 的数据完整性和多平台支持无可替代。

●需要进行深度研究、内容发现或构建推荐系统: Exa.ai 的概念搜索和相似性搜索能力是独一无二的

●需要构建企业内部的语义知识库或进行高级语义搜索: Jina.ai 的自定义索引和神经搜索能力最为强大

选型建议

综合以上分析，以下是针对不同需求的选型建议：

1.个人开发者 / 初创公司 / 预算极度敏感项目：

○首选：Ollama Web Search。完全免费且极致简单，没有任何理由不优先考虑它

○备选：Serper 或 Brave Search。当 Ollama 不可用或需要更高查询量时，这两者提供了业内最慷慨的免费额度和最低的付费门槛

2.构建标准 RAG 或 AI Agent 应用：

○首选：Tavily。它专为此场景设计，能直接提供清洗和总结后的高质量上下文，有效降低幻觉，节省你自己处理数据的成本和 LLM 的 Token 消耗

○备选：Serper。如果你的 RAG 流程需要自己控制总结逻辑，且对成本和速度要求很高，可以使用 Serper 作为快速的数据获取层

3.专业的 SEO / 市场分析 / 需要多平台数据的企业级应用：

○唯一选择：SerpApi。尽管价格昂贵，但其数据的完整性、真实性以及对全球几十个搜索引擎和电商平台的支持是其他所有服务都无法比拟的

4.探索前沿 AI 应用 / 需要进行深度内容发现和研究：

○首选：Exa.ai。如果你需要 AI 去 “发现” 而不是 “查找”，或者需要基于一篇好文章找到更多同类内容，Exa 的概念搜索和相似性搜索能力是你的不二之选

○备选：Jina.ai DeepSearch。如果你不仅要搜索网络，还想构建一个能理解内部文档的、强大的语义知识库，Jina 提供了更完整的平台级解决方案

另外，从风险评估的角度总结来说：

LangChain：是银弹，还是 “技术债”？

Tue, 23 Sep 2025 05:46:17 +0000

引言

当前，智能 Agent 的开发正面临两条截然不同的路径选择。一方面，高代码方式通过 SDK 和 API 编码提供灵活性，但带来了巨大的复杂性负担——开发者需要深入理解模型集成、工具调用、记忆管理和分布式协调等复杂概念，显著提高了开发门槛和维护成本。另一方面，像百炼，Dify、Coze 为代表的低代码平台以其出色的易用性迅速占领市场，通过可视化界面让用户能够快速构建 “Model+Prompt+MCP+RAG+Memory” 的标准 Agent 模式。

高代码与低代码

高代码

优势

●控制粒度高：检索、重排、记忆淘汰策略、工具容错、并发/一致性都能精细掌控。

●可移植/可替换：模型、向量库、存储、消息队列可按需换，避免深度锁定。

●性能上限高：可针对热路径做缓存/批量化/并行/算力亲和等优化。

●合规友好：易于纯内网/私有化落地，满足数据边界与审计需求。

劣势

●上手成本高：需要理解模型行为、工具协议、状态管理、分布式、测试/评测。

●开发周期长：原型到生产的路径更长，对团队工程能力要求高。

●维护复杂：提示/数据/评测/日志/灰度与回滚都要自己做治理。

适用场景

●对稳定性、性能、合规要求高的核心业务流程（客服、风控、运维、知识中枢）。

●强定制：复杂工具链（多后端系统、定制检索策略、多段对话状态机）。

●内网/私有化：外网受限、需与既有基建深度耦合（监控、鉴权、审计）。

低代码

优势

●速度快：原型与迭代极快，业务同学也能参与搭建与验收。

●门槛低：抽象好了调用、编排、上下文缓存、简单评测与发布。

●运维成本低：平台内置监控/日志/版本管理（能力视平台而定）。

劣势

●可扩展性受限：复杂状态机、精细化检索/重排、跨域事务一致性等较难。

●性能上限有限：难做深度批处理、算力亲和、跨服务并行等工程优化。

●供应商/能力锁定：某些特性依赖平台实现，迁移成本较高。

●私有化差异：部分平台更偏 SaaS；若需纯内网，要筛选支持私有化/离线模型的方案。

适用场景

●探索/验证期：快速做 PoC、AB 实验、用户调研与演示。

●中轻量业务：知识问答、表单处理、运营活动、内部助理等非关键路径。

●混合团队：产品/运营可直接改提示与流程，工程只需提供数据/工具接口。

场景选型

高代码和低代码有各自的特点和适用场景，那我们该如何决策呢？下面是一个快速决策矩阵：

总结来说：要“快试错”选低代码，要“硬落地”选高代码；两者并不对立，适合“原型低代码 + 核心高代码”的混合路线。

具体来说：

●2 周内交付可用原型、验证需求是否真实 → 低代码

●承载 7×24 核心业务，SLA/审计/内网合规很硬 → 高代码

●大量业务同学参与、频繁改提示与流程 → 低代码 +（必要时）接入自研工具

●把 RAG/记忆/工具编排做成“组织级能力层” → 高代码（沉淀为平台/服务）

●先做 Demo，再逐步把关键链路“工程化” → 低→高的混合迁移

这里需要注意的是，要避免反模式：

●把复杂状态机硬堆在低代码画布里，后期难以维护与回放。

●过早全高代码，导致验证周期太长、需求未定先造轮子。

●忽视提示/知识/评测的版本化与可回滚。

混合实践

对于我们来说，现在正好处于一个 “混合迁移” 的阶段，我们即在使用低代码平台 Dify,也在某些具体的场景下感到了 Dify的不适。所以对于某些项目要进行必要的工程化迁移和改造，具体思路是：

●前台用低代码（业务侧快速改动、AB/评测、需求验证）；

●后台用高代码沉淀“能力层”（RAG 服务、工具/MCP、回溯评测、观测/追踪、策略引擎）。

●平台只做编排与呈现，能力层提供稳定 API。

●形成“能力可复用、前台可迭代、核心可控”的结构。

一句话总结：低代码赢在速度，高代码赢在确定性；用低代码把事儿“做成”，再用高代码把事儿“做稳且做大”。

LangChain

概念说明

提到 LangChain 我们要先厘清一下概念，因为这里有两个概念：

第一，LangChain Inc. 是一家总部位于美国旧金山的前沿人工智能技术公司。公司成立于 2022 年，由 Harrison Chase 和 Ankush Gola 共同创立，2023 年正式独立成立公司实体。公司注册于 2023 年 1 月 31 日，总部地址位于加利福尼亚州旧金山市 Decatur 街 42 号。

第二，LangChain 还是一个用来开发基于 LLM 的 AI 应用框架。

从 LangChain 公司官网和官方文档提供的产品架构图中可以看出，LangChain公司提供的主要产品有：

●开发框架

○LangChain（OSS-免费开源软件)

○LangGraph（OSS-免费开源软件）

●平台

○LangSmith (COMMERCIAL-商业收费)

○LangGraph Platform (COMMERCIAL-商业收费)

在下文中如无特殊说明，LangChain 一律指代第二个概念，即开源的开发框架。

大模型应用开发核心矛盾

当下的 LLM 本身如同一个 “博学但无手无脚的大脑”，它无法感知实时信息、无法操作外部工具、也无法与我们的私有数据交互。这个 “从 “模型能力” 到 “应用能力” 的鸿沟” 正是所有 LLM 应用开发者面临的首要难题。

LangChain 不是一个 “新发明”，而是一个 “高效的连接器和编排器”。它的战略价值在于，它是当前弥合 “模型能力” 与 “应用能力” 鸿沟的最成熟的工程化解决方案之一。

框架介绍

LangChain 的核心思想是“链”，它将 LLM 应用程序的各个组件连接在一起，形成一个完整的工作流。这种模块化的方法可以将复杂的人工智能系统分解为可重用的部分。LangChain 提供了一系列工具和抽象，帮助开发人员将 LLM 与外部数据源（如数据库、API等）连接起来，从而创建功能更强大的应用程序。

LangChain 能够解决的五类问题

LangChain 能够解决五个核心领域（按复杂度递增）

1. 模型与提示（I / O 层）

要解决什么？ 稳定、可替换地调用任意 LLM，并拿到可解析、可复用的输出。

关键点：BaseChatModel、ChatPromptTemplate、OutputParser、LCEL invoke/stream/batch。

一般来说入门 LangChain 都是从第一层起步：prompt | llm | parser

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_core.prompts import ChatPromptTemplate
 3from langchain_core.output_parsers import StrOutputParser
 4from langchain_openai import ChatOpenAI
 5
 6prompt = ChatPromptTemplate.from_messages([
 7 ("system", "你是精炼的中文助手。"),
 8 ("human", "用一句话解释：{topic}")
 9])
10
11chain = prompt | ChatOpenAI(model="gpt-4o-mini") | StrOutputParser()
12print(chain.invoke({"topic": "LCEL 是什么？"}))

2. 链式编排（流程层）

要解决什么？ 把多个步骤（清洗→生成→解析→后处理）按顺序 / 并行可靠执行。

关键点：Runnable 统一协议、| 管道、并行 map、重试与超时、缓存

适用：流程确定、依赖明确的任务（如格式转换、规则后处理、批处理）。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_core.runnables import RunnableLambda
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_core.output_parsers import StrOutputParser
 5from langchain_openai import ChatOpenAI
 6
 7pre = RunnableLambda(lambda x: {"q": x["q"].strip()[:200]}) # 预处理：清理&截断
 8post = RunnableLambda(lambda s: s.rstrip("。") + "。") # 后处理：补全句号
 9
10prompt = ChatPromptTemplate.from_messages([
11 ("system", "用简洁中文回答。"),
12 ("human", "把这些要点合成一句话：{q}")
13])
14
15chain = pre | prompt | ChatOpenAI(model="gpt-4o-mini", temperature=0) | StrOutputParser() | post
16print(chain.invoke({"q": "LCEL, Runnable, invoke/batch/stream"}))

3. 检索增强生成 RAG（数据层）

要解决什么？ 当模型 “知道的不够”，要从外部资料中取对内容。

关键点：Loader/TextSplitter → Embeddings → VectorStore → Retriever（可带重排 / 压缩）。

 1⚡ python片段# pip install -U langchain langchain-openai langchain-community faiss-cpu
 2
 3from langchain_openai import ChatOpenAI, OpenAIEmbeddings
 4from langchain_core.prompts import ChatPromptTemplate
 5from langchain_core.output_parsers import StrOutputParser
 6from langchain_core.runnables import RunnablePassthrough, RunnableLambda
 7from langchain_community.vectorstores import FAISS
 8
 9# 1) 准备示例知识（演示使用；实际替换为你的文档）
10texts = [
11 "LCEL 是 LangChain 的可组合执行协议，用 | 串联组件（prompt、llm、parser）。",
12 "RAG（检索增强生成）通过向量检索把外部资料接入模型，以降低幻觉并注入最新知识。"
13]
14vs = FAISS.from_texts(texts, OpenAIEmbeddings())
15retriever = vs.as_retriever(k=3)
16
17# 2) RAG Prompt（把检索到的资料塞进上下文）
18prompt = ChatPromptTemplate.from_messages([
19 ("system", "你是知识助手，必须基于提供的资料回答。"),
20 ("human", "问题：{question}\n\n资料：\n{context}\n\n请用中文简洁作答，并在句末用[]引用关键词。")
21])
22
23# 3) 组合：question → retriever → prompt → llm → parser
24format_docs = RunnableLambda(lambda docs: "\n\n".join(d.page_content for d in docs))
25chain = (
26 {"context": retriever | format_docs, "question": RunnablePassthrough()}
27 | prompt
28 | ChatOpenAI(model="gpt-4o-mini", temperature=0)
29 | StrOutputParser()
30)
31
32print(chain.invoke("什么是 RAG？"))

4. 智能代理（自主层）

要解决什么？ 目标不完全明确、步骤不固定，需要选择工具、反复试探（行动 - 观察 - 反思）。

关键点：BaseTool/工具调用、函数调用、AgentExecutor（或用 LangGraph 做有状态策略）、记忆 / 护栏。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_openai import ChatOpenAI
 3from langchain_core.tools import tool
 4from langchain_core.messages import SystemMessage, HumanMessage, ToolMessage
 5
 6# 1) 定义一个可被模型调用的工具（OpenAI Tool Calling）
 7@tool
 8def multiply(a: int, b: int) -> int:
 9 "精确乘法"
10 return a * b
11
12# 2) 绑定工具，让模型自行决定是否调用
13llm = ChatOpenAI(model="gpt-4o-mini", temperature=0).bind_tools([multiply])
14
15# 3) 行动-观察-再思考（最小一次循环）
16msgs = [
17 SystemMessage("你是严谨助手，涉及计算必须调用工具，不要心算。"),
18 HumanMessage("先算 12×34，再把结果乘以 2，给出最终数值即可。"),
19]
20
21ai = llm.invoke(msgs) # 行动：模型决定要不要调用工具
22msgs.append(ai)
23for tc in ai.tool_calls: # 观察：执行工具并把结果回传给模型
24 out = multiply.invoke(tc["args"])
25 msgs.append(ToolMessage(str(out), tool_call_id=tc["id"]))
26
27final = llm.invoke(msgs) # 再思考：基于工具结果给最终答案
28print(final.content)

5. 评估与观测（质量层）

要解决什么？ 度量 “是否正确/有用/鲁棒”，以及在真实流量中看得见链路与瓶颈。

关键点：基准指标（EM/F1/检索命中率）、LLM 判分、回放/对比、LangSmith（或自建追踪）。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_openai import ChatOpenAI
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_core.output_parsers import StrOutputParser
 5from langchain.evaluation import load_evaluator
 6
 7# 被评对象：最小 QA 链（LCEL）
 8qa = (ChatPromptTemplate.from_template("用一句话回答：{q}")
 9 | ChatOpenAI(model="gpt-4o-mini", temperature=0)
10 | StrOutputParser())
11
12q = "LCEL 是什么？"
13ref = "LCEL 是 LangChain 的统一执行协议，用 | 将组件串联成可组合管道。"
14
15pred = qa.invoke({"q": q})
16
17# LangChain 自带评估器：按“准确&简洁”两条标准打分+给理由
18evaluator = load_evaluator(
19 "labeled_criteria",
20 llm=ChatOpenAI(model="gpt-4o-mini", temperature=0),
21 criteria={"accuracy": "是否与参考一致且不捏造", "conciseness": "是否一句话且清晰"}
22)
23grade = evaluator.evaluate_strings(input=q, prediction=pred, reference=ref)
24
25print("答案：", pred)
26print("评分：", grade.get("score"), "理由：", grade.get("reason"))

总结如下：

架构图

LangChain 是一个以组合性为核心哲学的大语言模型应用开发框架

其设计理念是 “通过组合性构建LLM应用”，具体来说：

1.可组合性 (Composability)：所有组件都是 Runnable，可以像乐高积木一样组合；使用 LCEL（LangChain Expression Language）轻松构建复杂流程

2.标准化接口 (Standardization)：统一的输入输出接口；一致的同步/异步/批处理/流式处理方法

3.可扩展性 (Extensibility)：通过继承基类轻松添加新实现；插件化架构，易于集成第三方服务

4.类型安全 (Type Safety)：使用泛型和类型提示；编译时类型检查，减少运行时错误

架构层次

LangChain 采用严格的分层架构，从底层的核心抽象到上层的应用组件，确保了良好的模块化和可扩展性。

 1⚡ text片段LangChain
 2├── langchain-core/ # 核心抽象层
 3│ ├── language_models/ # 基础模型抽象
 4│ ├── runnables/ # LCEL 核心
 5│ ├── prompts/ # 提示抽象
 6│ └── ...
 7│
 8├── langchain/ # 主实现层
 9│ ├── llms/ # LLM 实现
10│ ├── chat_models/ # Chat 实现
11│ ├── chains/ # 链实现
12│ └── ...
13│
14└── langchain-community/ # 社区集成
15 └── partners/ # 第三方集成
16 ├── openai/
17 ├── anthropic/
18 └── ...

模块结构

LangChain 主要包含以下模块：

1.核心语言模型模块

○llms/ - 传统 LLM（85+ 个实现）

○chat_models/ - 对话模型（35+ 个实现）

○embeddings/ - 嵌入模型（51+ 个实现）

2.输入输出模块

○prompts/ - 提示模板

○output_parsers/ - 输出解析器（23+ 种）

○prompt_values/ - 提示值处理

3.数据处理模块

○document_loaders/ - 文档加载器（166+ 种）

○document_transformers/ - 文档转换器

○text_splitter.py - 文本分割

○indexes/ - 索引管理

4.存储与检索模块

○vectorstores/ - 向量数据库（76+ 种）

○retrievers/ - 检索器（78+ 种）

○memory/ - 记忆管理（39+ 种）

○storage/ - 存储抽象

○docstore/ - 文档存储

5.链与编排模块

○chains/ - 各种链（144+ 个文件）

○runnables/ - 可运行组件

○agents/ - 智能体（146+ 个文件）

6.工具与集成模块

○tools/ - 工具集（186+ 种）

○agent_toolkits/ - 工具包

○utilities/ - 实用工具（59+ 个）

○utils/ - 辅助函数

7.回调与监控模块

○callbacks/ - 回调处理器（46+ 种）

○tracers/ - 追踪器

○evaluation/ - 评估工具（32+ 个）

8.特殊功能模块

○chat_loaders/ - 聊天记录加载

○graphs/ - 图处理

○sql_database.py - SQL 数据库支持

○cache.py - 缓存管理

Runnable 抽象

LangChain 的架构精髓在于 Runnable 接口 —— 一个"可以被调用、批处理、流化、转换和组合的工作单元" 。这个抽象提供了六种核心执行模式：

●invoke/ainvoke: 单次同步/异步执行

●batch/abatch: 并行同步/异步批处理执行

●stream/astream: 同步/异步流式输出执行

所有组件都实现 Runnable 接口，从检索器到代理系统，确保了组件间的无缝互操作性，使得 LangChain 组件具有极高的可组合性。

1⚡ 代码片段# 示例：链式组合
2chain = prompt | model | parser

LCEL：声明式表达语言

LangChain Expression Language (LCEL) 是框架的"声明式方法构建生产级程序" 。通过管道操作符（|）实现组件的优雅组合，天然支持异步、批处理和流式操作，这使得基于LCEL的程序能够更好地扩展以处理更高的并发负载。

LCEL 不仅仅是语法糖。它是一种声明式的编程范式。开发者只需声明 “数据如何流动”，而框架负责处理底层的执行、流式传输、并行化和日志记录。

 1⚡ python片段# pip install -U langchain langchain-openai
 2
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_openai import ChatOpenAI
 5from langchain_core.output_parsers import StrOutputParser
 6
 7# 1) Prompt：定义输入模板
 8prompt = ChatPromptTemplate.from_messages([
 9 ("system", "你是精炼、可靠的中文助手。"),
10 ("human", "用一句话回答：{question}")
11])
12
13# 2) LLM：任意 OpenAI 兼容服务均可（公有云/企业网关/vLLM 等）
14llm = ChatOpenAI(
15 model="gpt-4o-mini", # 换成你的模型名即可
16 api_key="YOUR_KEY", # 也可用环境变量 OPENAI_API_KEY
17 base_url="http://localhost:8000/v1" # 选填：本地或内网的 OpenAI 兼容地址
18)
19
20# 3) Parser：把模型返回的消息对象转成纯字符串
21parser = StrOutputParser()
22
23# LCEL：像搭乐高一样用“|”把组件串起来
24chain = prompt | llm | parser
25
26# ——最简单的单次调用（演示用）——
27print(chain.invoke({"question": "LCEL 是什么？"}))
28
29# ——可选：流式演示（边生成边打印）——
30for chunk in chain.stream({"question": "给出一条使用 LCEL 的建议"}):
31 print(chunk, end="")
32print()
33
34# ——可选：批量演示（一次处理多条）——
35print(chain.batch([
36 {"question": "一句话解释 LangChain"},
37 {"question": "一句话解释 LCEL 的优势"}
38]))

Schema 与类型系统

LangChain 的类型系统建立在 Python 的类型提示和 Pydantic模型之上，提供了一套完整的类型定义来支持 LLM 应用开发。LangChain 的类型系统具有以下特点：

1.强类型: 基于 Python 类型提示和 Pydantic，提供编译时和运行时类型检查

2.可组合: 通过 Runnable 接口实现组件的灵活组合

3.可序列化: 所有核心类型都继承自 Serializable

4.灵活性: 支持多种 Schema 定义方式（Pydantic、TypedDict、JSON Schema）

5.流式支持: 原生支持同步、异步、批处理和流式处理

6.标准化: 统一的输入输出类型定义，便于组件互操作

Pydantic 由 Samuel Colvin 创建，核心思想是：“使用类型注解定义数据模型，Pydantic 自动帮你验证和转换数据。” 它基于 Python 3.6+ 的类型提示系统（如 str, int, List, Optional 等），通过定义继承自 BaseModel 的类，来描述期望的数据结构。

想象一下，你正在指挥一个非常聪明但有点 “随心所欲” 的机器人。如果你只是模糊地说 “给我找点关于猫的资料”，它可能会给你一篇科学论文，一张猫的图片，或者一段猫叫的音频。这太不可预测了。LangChain 的 Schema 和类型系统，就像是给这个机器人的一套精确的 “指令图纸” 和 “数据表格”。它让你能够用一种机器人能精确理解的方式下达指令，并要求它以你想要的、规整的格式返回结果。下面我们通过几个场景和代码例子，来看看这些 “图纸” 和 “表格” 是怎么工作的。

场景 1: 从简单的闲聊到有角色区分的对话

一开始，我们和 AI 的交互很简单，就是 “一问一答”。

最基础的类型: Text (字符串): 这就是最原始的交互方式。

1⚡ 代码片段# 这其实就是最基础的文本 Schema
2my_question = "你好，你叫什么名字？"
3ai_response = "我是AI助手。"

但这很快就不够用了。在一个持续的对话中，AI 需要知道哪句话是谁说的，才能更好地理解上下文。

进阶类型: ChatMessage

ChatMessage 就是为了解决这个问题而生的 “对话表格”。它规定了每条消息都应该有 role (角色) 和 content (内容) 两列。主要角色有：

○SystemMessage: 系统指令。给 AI 设定一个 “人设” 或总体的行为准则。

○HumanMessage: 你的话。

○AIMessage: AI 的话。

每个元素都有明确的role 和content。这让 AI 不再混乱，能够更好地进行多轮对话。

场景 2: 我需要 AI 给我一个结构化的数据，而不是一段话

假设你想让 AI 帮你生成用户信息，并存入数据库。如果你只对它说 “生成一个用户，名叫张三，25 岁，邮箱是 zhangsan@email.com”，它可能会返回：

●" 好的，用户信息如下：姓名：张三，年龄：25，邮箱：zhangsan@email.com"

●" 张三，25 岁，邮箱 zhangsan@email.com"

●" 这是一个名叫张三的用户，他今年 25 岁了，你可以通过 zhangsan@email.com 联系到他。"

这些都是字符串，程序很难处理！我们需要的是一个干净的、可以直接用的 JSON 对象。这时，我们就要给 AI 一张 “图纸”，告诉它我们想要的输出格式。在 LangChain 中，最常用的 “绘图工具” 就是Pydantic 库。

 1⚡ python片段# 伪代码，演示核心逻辑
 2from langchain_core.pydantic_v1 import BaseModel, Field
 3from langchain_core.output_parsers import JsonOutputParser
 4from langchain_openai import ChatOpenAI
 5from langchain_core.prompts import PromptTemplate
 6
 7# 1. 用 Pydantic 画一张“图纸”，定义你想要的输出结构
 8classUserProfile(BaseModel):
 9 name: str = Field(description="用户的全名")
10 age: int = Field(description="用户的年龄")
11 email: str = Field(description="用户的电子邮件地址")
12 is_active: bool = Field(description="用户账户是否活跃")
13
14# 2. 创建一个输出解析器，告诉它要用哪张“图纸”
15parser = JsonOutputParser(pydantic_object=UserProfile)
16
17# 3. 在提示中，告诉AI要按照“图纸”的格式来回答
18prompt = PromptTemplate(
19 template="""
20 根据下面的用户信息，生成一个JSON对象。
21 用户信息：{user_info}
22 {format_instructions}
23 """,
24 input_variables=["user_info"],
25 # 把“图纸”的说明书（格式指令）插入到提示中
26 partial_variables={"format_instructions": parser.get_format_instructions()}
27)
28
29# 4. 创建模型并链接所有部分
30# model = ChatOpenAI(temperature=0)
31# chain = prompt | model | parser
32#
33# response = chain.invoke({"user_info": "创建一个用户，名叫李四，30岁，邮箱是 lisi@email.com，账户是活跃的。"})
34
35# 期望的 response 会是一个干净的 Python 字典，而不是字符串
36# print(response)
37#
38# 输出:
39# {'name': '李四', 'age': 30, 'email': 'lisi@email.com', 'is_active': True}

看到妙处了吗？通过定义UserProfile 这个 Schema，我们强制 AI 的输出符合我们预设的结构，让它的输出变得 100% 可预测和可用。

场景 3: 让 AI 使用我们定义的工具

假设你想让 AI 能够查询天气。AI 本身是不知道今天天气的，但你可以提供一个查询天气的函数（工具）给它。但是，AI 怎么知道这个函数是干嘛的？需要哪些参数？

LangChain 的 @tool 装饰器可以自动读取你函数的 “类型提示”(Type Hinting) 和文档字符串 (docstring)，并把它们变成一份 AI 能看懂的 “工具说明书”。

 1⚡ python片段# 伪代码，演示核心逻辑
 2from langchain_core.tools import tool
 3
 4@tool
 5def search_weather(city: str, unit: str = "celsius") -> str:
 6 """
 7 根据城市名称查询实时天气。
 8 :param city: 城市的名字，例如：北京
 9 :param unit: 温度单位，可以是 'celsius' (摄氏度) 或 'fahrenheit' (华氏度)
10 """
11 # 这里的代码会真实地去调用天气API
12 if city == "北京":
13 return f"北京现在的天气是 25°{unit}"
14 elif city == "上海":
15 return f"上海现在的天气是 28°{unit}"
16 else:
17 return f"抱歉，我查询不到 {city} 的天气。"
18
19# 当你把这个工具提供给一个支持工具调用的AI模型时，
20# LangChain会自动生成类似这样的“说明书”给AI看：
21# Tool Name: search_weather
22# Tool Description: 根据城市名称查询实时天气。
23# Tool Arguments:
24# - name: city, type: string, description: 城市的名字，例如：北京
25# - name: unit, type: string, description: 温度单位，可以是 'celsius' (摄氏度) 或 'fahrenheit' (华氏度)
26
27# 当你问AI：“北京今天天气怎么样？”
28# AI会分析你的问题，发现需要查询天气，然后查看它手上的“工具说明书”。
29# 它会找到 search_weather 工具，并自动生成调用参数：{"city": "北京", "unit": "celsius"}
30# 然后执行函数，得到结果，最后把结果用自然语言告诉你。

这里的 city: str 和 unit: str 就是 Schema 的一部分，它明确规定了工具需要什么类型的输入。文档字符串 “”"…""" 则成了 AI 理解工具功能的关键。

核心抽象组件

LangChain 的架构围绕以下几个基本抽象组件构建，这些抽象组件共同构成了 LangChain 的核心架构，让开发者能够快速构建复杂的 LLM 应用。每个组件都有明确的职责，通过 Runnable 接口相互连接，形成了一个强大而灵活的框架。

Language Models (语言模型)

提供文本生成、对话、推理等核心 AI 能力

●BaseLanguageModel: 所有语言模型的基类,它继承自 RunnableSerializable，并定义了语言模型交互的通用接口。它通过其 generate_prompt() 方法接受 PromptValue 对象。

●BaseChatModel: 对话模型（GPT-4、Claude）- 处理消息序列

●BaseLLM: 文本生成模型 - 处理字符串输入输出

Prompts (提示模板)

输入构造层，支持变量替换、少样本示例、消息格式化

●BasePromptTemplate: 动态构造模型输入

●ChatPromptTemplate: 构造对话消息序列

●PromptTemplate: 构造文本提示

Messages (消息)

对话交互的基本单元

●BaseMessage: 所有消息的基类

●HumanMessage: 用户消息

●AIMessage: AI 回复

●SystemMessage: 系统指令

●ToolMessage: 工具调用结果

Documents (文档)

知识存储的基本单元，是 RAG（检索增强生成）的基础数据结构

●Document: 包含 page_content（内容）和 metadata（元数据）

●用于表示任何文本数据：网页、PDF、数据库记录等

Retrievers (检索器)

知识检索层，RAG 架构的核心组件

●BaseRetriever: 是文档检索系统的抽象基类，它实现了 Runnable 接口以实现可组合性。它定义了基于查询检索相关文档的标准接口。

●连接向量数据库、搜索引擎、数据库等

Vector Stores (向量存储)

语义搜索的基础设施

●VectorStore: 向量数据库的抽象接口

●存储和检索文档的向量表示

●支持相似度搜索、混合搜索等

Embeddings (嵌入)

文本向量化，提供了嵌入模型的抽象接口，定义了将文本转换为向量表示的方法。它要求实现 embeddocuments() 和 embedquery() 方法。是语义搜索和相似度计算的基础。

●Embeddings: 将文本转换为向量表示

●支持各种嵌入模型（OpenAI、Hugging Face 等）

Output Parsers (输出解析器)

结构化输出，确保模型输出符合预期格式

●BaseOutputParser: 解析模型输出为结构化数据

●PydanticOutputParser: 解析为 Pydantic 模型

●JsonOutputParser: 解析为 JSON

Tools (工具)

BaseTool 是供智能体（Agents）使用的工具（Tools）的抽象基础，继承自 RunnableSerializable，并为与外部系统交互提供了标准化接口。是 Function Calling 和 Agent 的基础。

●BaseTool: 定义模型可调用的外部功能

●让模型能执行计算、查询数据库、调用 API 等

Callbacks (回调)

观察和控制执行流程，提供执行过程的可见性

●BaseCallbackHandler: 监听和响应执行事件

●用于日志记录、调试、监控、流式输出等

Memory/Cache (记忆/缓存)

状态管理，对话历史管理、会话状态保持

●BaseCache: 缓存 LLM 响应，避免重复调用

●BaseStore: 键值存储抽象

对照表

这里是一个快速对照表，来将上文的 LangChain 模块与核心抽象组件之间做个对应。

模块就像房间（客厅/厨房/卧室），抽象就像插座与标准接口（任意电器都能插上电并协同工作）。

●主要模块 = 按 “职能分区” 的功能板块（编排、模型、检索、Agent、记忆、部署等），回答 “系统里有哪些能力”。

●核心抽象 = 跨模块通用的接口 / 基类（如 Runnable、BaseChatModel、BaseRetriever…），回答 “各模块如何被替换与拼装”。

Agent

LangChain 框架完全可以构建 Agent，并且这是它自诞生以来最核心、最吸引人的功能之一。经典的 Agent（如 ReAct 范式）通过 AgentExecutor 实现一个 “思考 -> 行动 -> 观察” 的循环。LLM 在这个循环中扮演决策者，决定下一步调用哪个工具（Tool）。对于绝大多数单 Agent 任务，LangChain 的原生 Agent 完全够用。

但是，当 Agent 的逻辑变得极其复杂，例如：

1.需要循环和分支：当流程不是线性，而是需要在多个步骤之间来回跳转。

2.需要多 Agent 协作：例如，一个 “分析师 Agent” 生成报告，交给 “代码生成 Agent” 编写代码，再由 “测试 Agent” 进行验证，如果测试失败，流程需要返回给 “分析师 Agent” 重新分析。

3.需要持久化的状态管理：在复杂的交互中，需要精确控制每一步的状态。

这时 LangGraph 框架应运而生。它将 Agent 的工作流显式地定义为一个状态图 (State Graph)。每个节点是一个工作单元（一个 LLM 调用或一个工具调用），每条边是状态的转移。它不是取代了 LangChain Agent，而是为构建更强大、更可控的 “状态化 Agent 系统” 提供了新的范式。

LangGraph

LangGraph 可以独立使用，但它也可以无缝集成到任何 LangChain 产品中。

LangGraph 提供了比 LangChain 更底层、更灵活的控制能力，特别适合需要状态管理、人机协作和复杂流程编排的场景。而 LangChain 则更适合快速原型开发和简单的链式处理任务。两者可以协同使用：LangChain 的组件可以作为 LangGraph 的节点，但 LangGraph 也可以完全独立于 LangChain 使用。

如果不用 LangGraph 开发，选择其他框架，推荐使用 CrewAI。

LangGraph 架构

LangGraph 的执行流程遵循以下算法：

LangChain 与 LangGraph 适用场景对比：

LangChain 与 LangGraph 代码对比

LangChain（使用 AgentExecutor）:

 1⚡ python片段# pip install -U langchain langchain-openai
 2import os
 3from datetime import datetime
 4
 5from langchain_openai import ChatOpenAI
 6from langchain_core.tools import tool
 7from langchain_core.prompts import ChatPromptTemplate
 8from langchain.agents import create_tool_calling_agent, AgentExecutor
 9
10# ========== Tools ==========
11@tool
12def multiply(a: float, b: float) -> float:
13 """Return a*b."""
14 return a * b
15
16@tool
17def get_time(fmt: str = "%Y-%m-%d %H:%M:%S") -> str:
18 """Return current local time formatted by fmt."""
19 return datetime.now().strftime(fmt)
20
21tools = [multiply, get_time]
22
23# ========== LLM ==========
24llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
25
26# ========== Agent ==========
27prompt = ChatPromptTemplate.from_messages([
28 ("system", "You are a concise tool-using agent. Use the tools when helpful. Reply in Chinese."),
29 ("human", "{input}")
30])
31
32agent = create_tool_calling_agent(llm, tools, prompt)
33executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
34
35# ========== Demo ==========
36res = executor.invoke({
37 "input": "先用 multiply 计算 7×12，再调用 get_time 给出当前时间。答案只要一行。"
38})
39print("Final:", res["output"])

我来画出详细的流程图，展示这个 LangChain Agent 的执行过程：

LangGraph 代码：

 1⚡ python片段# pip install -U langgraph langchain langchain-openai
 2from datetime import datetime
 3from typing import Sequence
 4from typing_extensions import TypedDict
 5
 6from langchain_core.tools import tool
 7from langchain_core.messages import AnyMessage, HumanMessage
 8from langchain_openai import ChatOpenAI
 9
10from langgraph.graph import StateGraph, END # END 表示图的终点
11from langgraph.prebuilt import ToolNode, tools_condition # 预置的“工具节点”和“是否需要走工具”的路由函数
12
13# ===== 工具定义：用 @tool 自动生成 JSON Schema，便于模型函数调用 =====
14@tool
15def multiply(a: float, b: float) -> float: # 定义乘法工具
16 return a * b
17
18@tool
19def get_time(fmt: str = "%Y-%m-%d %H:%M:%S") -> str: # 定义获取时间工具
20 return datetime.now().strftime(fmt)
21
22tools = [multiply, get_time] # 工具列表（给模型/工具节点用）
23
24# ===== 绑定工具到模型：让 LLM 知道有哪些可调用的函数（工具） =====
25llm = ChatOpenAI(model="gpt-4o-mini", temperature=0).bind_tools(tools)
26# bind_tools(...) 的效果：
27# 1) 把 tools 的参数签名/描述转成 JSON Schema 给模型；
28# 2) 让模型在需要时产生 tool_calls（函数调用）结构，而不是直接“胡说答案”。
29
30# ===== 定义“状态”的数据结构：LangGraph 的节点之间传的就是这个 State =====
31classS(TypedDict):
32 messages: Sequence[AnyMessage] # 一串消息（人类/AI/工具消息），作为“对话上下文”
33
34# ===== 定义一个“模型节点”：输入 State，调用 LLM，输出一条 AI 消息 =====
35def agent_node(state: S):
36 # 关键：把现有 messages（含用户、人类消息、工具结果等）喂给 LLM
37 ai_msg = llm.invoke(state["messages"]) # 可能返回带 tool_calls 的 AIMessage
38 return {"messages": [ai_msg]} # LangGraph 会把这条消息合并到全局 state
39
40# ===== 搭建“有向图”：节点 + 边，决定执行路径 =====
41g = StateGraph(S) # 新建一个“状态图”，S 是状态类型（结构）
42
43# ——① 注册节点（起名叫 "agent" 和 "tools"）——
44g.add_node("agent", agent_node) # 把上面的函数包装成一个图节点
45g.add_node("tools", ToolNode(tools)) # 预置的工具节点：会读取 AI 的 tool_calls 并执行
46
47# ——② 设置“入口节点”：从哪个节点开始跑——
48g.set_entry_point("agent") # ★ 从 "agent" 开始（也就是先问一次模型）
49# 解释：这句相当于“第一步进图先走哪个节点”。如果不设，编译时会报错或不知道从哪开始。
50
51# ——③ 配置“条件边”：根据模型输出决定接下来走哪条边——
52g.add_conditional_edges(
53 "agent", # 从 "agent" 节点出来时
54 tools_condition, # 用预置的判断函数：看 AIMessage 是否包含 tool_calls
55 {"tools": "tools", "end": END} # 如果需要工具→去 "tools"；否则→直接结束
56)
57# 解释：tools_condition 会检查最新一条 AI 消息。
58# - 若模型产生了函数调用（tool_calls），返回路由键 "tools"
59# - 若没有需要的工具调用，返回路由键 "end"
60# 这行把路由键映射为真正的边：“tools”→去 tools 节点，“end”→走到 END（图的终点）。
61
62# ——④ 把工具节点执行完后的边接回“agent”，形成闭环——
63g.add_edge("tools", "agent")
64# 解释：当 tools 节点执行完所有函数调用，会把结果（ToolMessage）追加到 state.messages，
65# 然后回到 "agent" 再问一次模型。直到模型不再发起新的 tool_calls。
66
67# ——⑤ 编译成可运行的“应用”对象——
68app = g.compile()
69# 解释：compile() 会把上面定义的节点/边/合并策略等打包成可执行的图（可 invoke/stream）。
70
71# ===== 运行：给一条人类消息，按图的“入口节点”开始执行 =====
72final = app.invoke({
73 "messages": [HumanMessage(content="先用 multiply 计算 7×12，再调用 get_time 报当前时间。只要一行中文。")]
74})
75# 解释：invoke 会：
76# step1: 进入入口 "agent" → LLM 读到 HumanMessage，判断要不要调用工具；
77# step2: 如果需要工具 → 路由到 "tools" 执行（得到 ToolMessage）→ 回到 "agent"；
78# step3: 重复 step1~2，直到不需要工具 → 按条件边路由到 END → 返回最终状态。
79
80print(final["messages"][-1].content) # 打印最后一条 AI 的自然语言回复

LangGraph 详细执行流程：

竞品

如果不使用 LangChain 开发 AI/LLM 应用，以下是主要的替代框架选择：

以下是按要求整理的表格内容：

框架	定位/标签	语言/平台	核心优势关键词	典型场景	🔎RAG	👥Agent	🏢企业	🎯输出控制	🪶轻量
LlamaIndex	RAG 与数据检索专家	Py/TS	多索引策略、查询路由、强检索、结构/非结构数据	知识库问答、文档分析、RAG	★★★★★	★★☆☆☆	★★★☆☆	★★☆☆☆	★★★☆☆
CrewAI	多智能体团队协作	Py	角色/任务、顺序/并行/层级协作、社区活跃	多智能体系统、内容流水线、任务分解	★★☆☆☆	★★★★★	★★★☆☆	★★☆☆☆	★★★☆☆
Semantic Kernel	企业级 AI 编排	C#/Py/Java	技能/规划器、Azure 深度集成、微软背书	企业应用、复杂规划、微软技术栈	★★★☆☆	★★★☆☆	★★★★★	★★☆☆☆	★★☆☆☆
Haystack	NLP/搜索系统专家	Py	Pipeline 清晰、文档处理强、评测完善、重隐私	QA 系统、语义搜索、信息抽取	★★★★☆	★★☆☆☆	★★★★☆	★★☆☆☆	★★★☆☆
AutoGen	自动化对话与代码生成	Py	代码生成/执行、多 Agent 对话、自动化流程、人机协作	代码生成、数据分析自动化、技术任务	★★☆☆☆	★★★★☆	★★★☆☆	★★☆☆☆	★★★☆☆
Guidance	精确输出控制	Py	模板语言、强格式约束、轻量高效	结构化输出、格式化生成、提示工程	★☆☆☆☆	★☆☆☆☆	★★★☆☆	★★★★★	★★★★☆

还有一些新兴 / 特色框架：

以下是按要求整理的表格内容：

框架	定位/标签	语言/平台	核心优势关键词	典型场景	🔎RAG	👥Agent	🏢企业	🎯输出控制	🪶轻量
LiteLLM	统一 LLM API	Py	100+ 模型统一接口、超轻量、零依赖	简单 LLM 调用、多模型切换、原型	★☆☆☆☆	★☆☆☆☆	★★★☆☆	★★☆☆☆	★★★★★
DSPy	声明式/自动提示优化	Py	可学习模块、自动调参、学术完善	指标导向优化、研究/实验	★★★☆☆	★★☆☆☆	★★☆☆☆	★★★☆☆	★★★☆☆
txtai	轻量 Transformers 框架	Py	HF 生态、内置向量库、性能好	轻量语义搜索、嵌入式应用	★★★☆☆	★☆☆☆☆	★★☆☆☆	★★☆☆☆	★★★★☆
MetaGPT	“AI 软件公司”模拟	Py	角色分工、项目级生成、代码产出	自动化软件开发、代码生成	★☆☆☆☆	★★★★☆	★★☆☆☆	★★☆☆☆	★★☆☆☆

在实际开发中，如不用 LangChain，选型范围会缩小到最流行的几个竞品，比如：

●🦙 LlamaIndex：原名 GPT-Index，是一个开源的数据框架，专门用于构建大型语言模型 (LLM) 应用。它主要解决了如何将 LLM 与外部数据有效连接的问题，使开发者能够创建更强大的知识密集型应用。

●🚢 CrewAI：多智能体团队协作框架，CrewAI 是一个轻量、快速的 Python 框架，完全从零构建，与 LangChain 或其他代理框架完全无关。它为开发者提供高级别的简洁性和精确的底层控制，非常适合创建适用于任何场景的自主 AI 代理。

●🔧 Haystack：一个端到端的大型语言模型（LLM）框架，它允许你构建由 LLM、Transformer 模型、向量搜索等功能驱动的应用程序。

●🚀 AutoGen：用于创建能够自主行动或与人类协作的多智能体AI应用的框架

需要注意的是：这些框架不是互斥的，可以组合使用（如 LlamaIndex + CrewAI）

常见陷阱与挑战

抽象泄漏 (Leaky Abstraction)

定义: 一个 “抽象” 旨在隐藏底层实现的复杂性。当这个抽象无法完全隐藏底层细节，导致你必须理解底层是如何工作的才能正确地使用它或排查问题时，就发生了 “抽象泄漏”。

LangChain 中的具体例子 (以旧版的 RetrievalQA 链为例):

●美好的抽象: RetrievalQA 链看起来很简单，你只需要给它一个 llm 和一个 retriever，它就能帮你完成 RAG。你期望它能 “神奇地” 工作。

●泄漏的现实:

a.Prompt 在哪里？你发现问答效果不好。为什么？因为 RetrievalQA 内部使用了一个默认的、隐藏的 Prompt 模板 (类似 “Use the following pieces of context to answer the user’s question…")。这个默认模板可能不适合你的模型（比如某些中文模型），或者不符合你的业务场景。

b.文档如何组合？当 retriever 返回了 4 个文档块 (Chunks) 时，这些文档是如何被塞进最终的 Prompt 里的？是简单拼接吗？如果超过了模型的上下文窗口怎么办？RetrievalQA 有一个 chaintype 参数（如 stuff, mapreduce）来控制这个行为。

问题的根源: 为了解决上述问题，你被迫去阅读 LangChain 的源码，去理解 RetrievalQA 内部隐藏的 Prompt 和文档组合逻辑。这时，RetrievalQA 这个本应让你省心的 “高级抽象”，反而成了你理解和调试的障碍。抽象 “泄漏” 了底层的实现细节。

如何应对？

拥抱 LCEL: LCEL 在很大程度上解决了这个问题。通过 prompt | model | parser 的方式， Prompt 是显式的，数据流是清晰的。你可以完全控制每一个环节，没有 “魔法” 和隐藏的逻辑。这是一种更 “白盒” 的构建方式，虽然初看起来代码多了一点，但可控性和可调试性大大增强。当然还有一种方案就是 “取其精华，去其糟粕”，LangChain 框架引入后，只用必要的部分组件，其余需要灵活处理的部分，全手写。

调试的 “黑盒感”

问题: 链的最终输出不符合预期，但中间过程完全不可见，不知道是 Prompt 错了、检索出的文档错了，还是模型理解错了。

解决方案: LangSmith。这是解决此问题的标准答案。设置环境变量 LANGCHAINTRACINGV2=“true” 即可开始追踪。用不了 LangSmith 的话，也可以用开源的 langfuse 替代。

对简单任务过度设计

问题: 你的任务只是需要根据一个模板调用一次 OpenAI API。这种情况下，引入 LangChain 的 LLMChain 相比直接使用 openai 库的 client.chat.completions.create()，增加了不必要的复杂性。

解决方案: 保持务实。如果你的应用逻辑非常简单，就是一个单一的 LLM 调用，那么直接使用原生 SDK 可能更清晰、更轻量。当且仅当你需要编排多个步骤（如 RAG）、管理记忆、或使用 Agents 时，LangChain 的价值才能最大化。

LangChain 的版本演进

v1.0 alpha：和 v0.x 的关键差异

v1.0 alpha（2025-09）是 LangChain 的一次 “面向长期” 的大改版

核心变化

●消息模型统一：新增 .content_blocks（标准化的 “内容块” 视图），把不同厂商的 “推理、引用、服务端工具调用、多模态” 等表示成同一种类型，减少 provider 差异带来的胶水代码；对旧 .content 后向兼容。

●Agent 重心调整：create_agent() 成为默认入口，底层基于 LangGraph 的图式运行时（持久化、流式、人审 / 中断、错误处理更规范）。

●包面积极度收敛：langchain 更聚焦 “标准接口 + 预置 Agent / 链”；历史面迁到 langchain-legacy，便于兼容老代码再慢慢重构。

●默认行为与平台要求：

○Python 需 ≥3.10；Chat 模型返回类型固定为 AIMessage；OpenAI Responses API 的默认输出版本调整（可用 LCOUTPUTVERSION=v0 退回）；Anthropic max_tokens 默认值上调。

○JS / TS 侧：核心原语（createAgent、ToolNode、tool、消息类型）直接从 langchain 导出；Node.js 需 ≥20；大量老子路径导出清理。

三个常见场景

1.“会用工具、可结构化返回” 的 Agent

v0.x（典型写法）：构建 Agent + Executor，再自己管结构化解析 / 二次调用

 1⚡ python片段# 旧式（示意）：AgentExecutor + 自行处理结构化输出
 2from langchain_openai import ChatOpenAI
 3from langchain.agents import AgentExecutor, initialize_agent
 4from pydantic import BaseModel
 5
 6class Weather(BaseModel):
 7 temperature: float
 8 condition: str
 9
10llm = ChatOpenAI(model="gpt-4o-mini")
11tools = [get_weather]
12
13agent = initialize_agent(tools, llm, agent="zero-shot-react-description")
14result = agent.run("What's the weather in SF?")
15# 再用正则/二次调用或手写解析把 result 转成 Weather(...)

v1.0 alpha（新写法）：一个入口 create_agent，在主循环里直接产出结构化结果（避免多一次 LLM 调用、少走弯路）

 1⚡ python片段from langchain.agents import create_agent
 2from pydantic import BaseModel
 3
 4class Weather(BaseModel):
 5 temperature: float
 6 condition: str
 7
 8agent = create_agent(
 9 "openai:gpt-4o-mini", # 也可传入已实例化 model
10 tools=[get_weather],
11 response_format=Weather # 结构化输出内建
12)
13out = agent.invoke({"messages": [{"role": "user", "content": "Weather in SF?"}]})
14print(out["structured_response"]) # -> Weather(...)

2.“跨厂商、多模态/推理/引用” 的消息处理

v0.x：不同厂商字段名不同（如 reasoning、thinking、citations、server tool 等），常见一堆 if provider == … 的分支。

v1.0 alpha：直接读 .content_blocks（统一、强类型），必要时再序列化回标准块。

1⚡ python片段from langchain_core.messages import AIMessage
2
3msg = some_llm.invoke("Explain with sources & brief reasoning")
4# v1 统一读取：
5for block in msg.content_blocks:
6 if block["type"] == "reasoning":
7 use_reasoning(block["reasoning"])
8 if block["type"] == "text" and "annotations" in block:
9 use_citations(block["annotations"])

3.“工具错误/人审/长对话摘要” 的生产级控制

v0.x：这些能力多靠自写回调或外层控制流拼起来。

v1.0 alpha：内置 Middleware 三钩子（beforemodel / modifymodelrequest / aftermodel）+ 现成中间件（摘要、人审、Anthropic Prompt Caching），还能 “跳转 / 中断”。

 1⚡ python片段from langchain.agents import create_agent
 2from langchain.agents.middleware import SummarizationMiddleware, HumanInTheLoopMiddleware
 3
 4agent = create_agent(
 5 "openai:gpt-4o",
 6 tools=[...],
 7 middleware=[
 8 SummarizationMiddleware(max_tokens_before_summary=4000),
 9 HumanInTheLoopMiddleware(tool_configs={"write_file": {"allow_approve": True}})
10 ],
11)

LangSmith 🦜️⚒️

●解决 LLM 应用开发中最头疼的调试、追踪和评估问题，这是其商业化的核心（收费）。一个应用越复杂，就越离不开 LangSmith，形成用户粘性。

●LangSmith = LLM 应用的 “一体化可观测 + 评测平台”：用来给 Agent / RAG / 多模态应用做全链路追踪（Tracing）、离 / 在线评测（Evals）、监控告警、成本与时延看板、Prompt 协作等；既可配合 LangChain / LangGraph，也支持非 LangChain 项目、OTEL 接入。

可以开源免费的 langfuse 替代 LangSmith

LangServe 🦜️🏓

●打通 “最后一公里”，让开发者能一键将用 LangChain 构建的应用 API 化

●LangServe 可以把 LangChain 的 Runnable/Chain 一键暴露成 REST API 的开源库，基于 FastAPI + Pydantic，自带 /invoke、/batch、/stream、/streamlog、/streamevents 等端点、自动推断 I / O Schema、内置 Playground，并可把追踪接到 LangSmith

收费吗？

库本身不收费。但其许可证限制：不得把 LangServe 作为托管 / 托管式服务提供给第三方（SaaS）。也就是说，你可以用它部署自己的应用，但不能把 “LangServe 平台” 卖给其他公司用。另外，LangChain 官方更推荐新项目用 LangGraph Platform（LangServe 只接受社区 bug 修，不再收新特性）。如果要 “托管式平台”，那是另一条产品线（付费）

LangChain 的使用争议

关于 LangChain 最开始的时候是一片盛赞，几乎全是正面评价，但随着开发者使用的深入，不断有负面评价出现。

LangChain 在使用上的主要争议，或者说让开发者后来“抛弃” 它的主要原因有：

1.API 频繁改、文档滞后，维护成本高

○2023–2025 年间最常见吐槽：接口 / 导入路径经常变、语义化版本执行不严、文档跟不上，导致线上项目要反复改代码与迁移；社区讨论与帖子里这一点重复被提及。官方后来在 0.2 才引入 “版本化文档”以缓解这个痛点。Reddit

2.抽象层过重/“抽象泄漏”

○本来想简化 LLM 应用，但层层抽象（Chains/Agents/Memory/Tools…）让简单事变复杂；当跨供应商（OpenAI/Anthropic）或多模态/工具调用时，还是要理解底层差异并写分支，抽象并未完全 “挡住细节”，很多人因此更倾向 “直接调 API / 自己拼装”。

3.性能 / 成本开销与 “隐形调用”

○经验帖里常见：token 使用低效、默认批量/重试/校验带来额外请求与延迟；默认设置偏原型友好，不一定适合生产（缓存、批处理、上下文裁剪都要自己细调）。DEV Community

4.调试与可观测性难（不用配套工具时）

○没接追踪时，多层封装中的报错 / 耗时难以定位，“像在雾里调试”；不少团队因此上了自家的可观测或放弃高阶封装。

5.学习曲线与 “过度框架化”

○许多工程团队反映：学习成本与收益不匹配，做简单的 RAG / 工作流时，直接 SDK + 少量自写代码更快可控；把 LangChain 当工具库（utility）用反而更顺。

6.生态分拆、选择困难与 “框架漂移”

○LangChain/ LangGraph/ LangServe/ LangSmith 产品边界不断演进；多数对比文章建议：流程化任务用 LangChain，复杂状态 / 多轮 agent 用 LangGraph—— 很多团队索性选更贴合场景的替代或 “手写”。DEV Community

上面这些点，不是说 LangChain “不能用”，而是在规模化、稳定性要求高的团队里，可预期性 / 可控性往往比 “快速堆组件” 更重要。

负面评价

这里我引用一些具体的负面评价，通过开发者真实的体验和文章来了解一下 LangChain 的问题。

为什么我们不再使用 langchain 来构建我们的AI代理

●来源： https://octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents

●结论：作者最初喜欢 LangChain 因为其丰富组件和易用性，但后来因其抽象复杂、灵活性差而不推荐。

初期为何喜欢使用 LangChain

作者在项目初期选择 LangChain，主要因为它具备以下优点：

●丰富的工具和组件：LangChain 提供了大量现成的模块，能快速搭建 LLM 应用。

●易于集成：框架承诺“让开发者一个下午就能从想法变成可运行代码”，适合原型开发和快速试错。

●人气高、社区活跃：2023 年 LangChain 热度很高，生态完善，容易找到资料和支持。

这些特性让作者在项目早期能专注于业务逻辑，而不用过多关心底层实现细节。

后期为何不再推荐 LangChain

随着项目复杂度提升，作者逐渐发现 LangChain 带来的问题：

1.抽象层级过多，代码复杂

○LangChain 引入了大量抽象（如 Prompt 模板、输出解析器、链等），让简单任务变得繁琐。

○代码难以理解和维护，调试时需要花大量时间研究框架内部逻辑。

2.灵活性不足，难以定制

○框架对底层细节封装过度，开发者很难根据实际需求修改或扩展功能。

○当需求超出 LangChain 设计假设时，反而成为限制，必须“将需求转化为适合 LangChain 的方案”，而不是直接实现业务逻辑。

3.适应快速变化的 AI 领域能力有限

○AI 和 LLM 领域变化极快，LangChain 的抽象和设计难以跟上新技术和新需求。

○框架的“嵌套抽象”导致开发者需要理解庞大的堆栈和内部机制，增加了认知负担。

4.团队协作和维护成本高

○团队成员需要花大量时间理解和调试 LangChain，而不是专注于功能开发。

○框架的复杂性让代码维护变得困难，影响开发效率。

反思与建议

作者认为，虽然 LangChain 在原型阶段有用，但长期来看，直接用基础库（如 OpenAI API）开发更简单、灵活。大多数 LLM 应用只需少量核心组件，无需复杂框架。对于 AI Agent 等复杂场景，建议在 Agent 模式成熟前保持简单，避免过度依赖抽象。

“一旦我们删除了它，我们就不再需要将我们的需求转化为适合 LangChain 的解决方案。我们只需编写代码即可。”

作者的经历体现了技术选型中“早期便利 vs. 长期灵活性”的权衡，也反映了 AI 应用开发领域对“抽象与简单”的持续思考。

2025 年了，LangChain 还是个无底洞。

https://www.reddit.com/r/LocalLLaMA/comments/1iudao8/langchainisstillarabbitholein_2025/?tl=zh-hans

给研发团队的建议

●“轻 LangChain”：保留少量 LCEL/Runnable 原语（或只用部分解析 / 工具封装），核心链路直接用供应商 SDK 实现，减少抽象层。

●“换轨到 LangGraph”：涉及复杂状态/长对话/人审/错误恢复的 agent，改用图式运行时（LangGraph / 其他工作流框架）。

●“专用 RAG 框架 / 自研”：检索、重排、结构化输出走 LlamaIndex / 自研管线

总之，手写代码是一条自主可控的道路，而梭哈 LangChain 可能会是一条不归路。

不止于工具：PromptPilot如何将AI开发从“手工作坊”推向“工业时代”？

Sun, 03 Aug 2025 10:09:58 +0000

“

在AI应用的最后一公里，我们面临一个深刻的悖论：我们拥有了前所未有强大的大模型“引擎”，却常常在如何精确“驾驶”它这件事上捉襟见肘。我们真正缺的，或许不是更强的模型，而是更准的“缰绳”。

概览

最近，火山引擎开了一场发布会，端出了两道“硬菜”：一个是性能更强的豆包大模型1.6，另一个则是我们今天要深挖的主角——PromptPilot。

这篇文章会把这两件事给你一次性讲明白。读完本文，你会清晰地了解到：

为何要关注豆包1.6：首先，我们会快速过一遍豆包大模型1.6的升级亮点，并列出它在中文处理、成本、长文本等方面的几个硬核优势，让你明白为何它值得被选入你的生产环境。
主角PromptPilot如何解决痛点：接着，我们会深入本文真正的主角——PromptPilot。带你从头到尾走一遍它的全流程，看它到底是如何通过“生成→调试→评测→优化”的闭环，将写提示词这件“玄学”彻底工程化的。
横向对比：把它放到市场中，与谷歌、微软等大厂的同类产品做对比，看清它的真实水平和独特价值到底在哪。

豆包大模型 1.6

豆包大模型升级了。2025 年 6 月 11 日在火山引擎 FORCE 原动力大会上正式发布豆包大模型 1.6 版本

从原来的 1.5 到现在的 1.6，间隔仅有 140 天（豆包大模型 1.5 版本于 2025 年 1 月 22 日正式发布）。4 个多月出新版本，算得上是很快了。我想团队内部遇到的困难、挑战一定不少，在这些困难下，工程师们交出的结果却一点儿不差，令人尊重。

现在你可以通过 https://www.volcengine.com/experience/ark?model=doubao-seed-1-6-flash-250715 来体验 1.6 版本的模型，会送 50 万 token。

大概介绍一下 1.6 模型，主要有以下两个子模型：

Doubao-Seed-1.6-thinking｜250715：模型思考能力大幅强化，对比 Doubao-1.5-thinking-pro，在 Coding、Math、逻辑推理等基础能力上进一步提升，支持视觉理解。支持 256k 上下文窗口，输出长度支持最大 16k tokens。
Doubao-Seed-1.6-flash｜250715：推理速度极致的多模态深度思考模型，TPOT 仅需 10ms；同时支持文本和视觉理解，文本理解能力超过上一代 lite，纯文本能力大幅提升近 10%。支持 256k 上下文窗口，输出长度支持最大 16k tokens。

从我个人的使用体验上看，1.6 比 1.5 强了很多。据悉，在众多权威评测集上，豆包大模型 1.6 的得分均位居国际第一梯队。

可能很多人有这样一个问题：有那么多模型，我为什么要选择豆包？

嗯，确实，市面上众多模型，开源的也好，闭源的也罢，除了国民级别的豆包 APP，好像豆包大模型的存在感不太高。然而实际上可能只是你不知道，我来列举一些，你可能真的想在生产应用中使用豆包大模型的原因：

中文准确度必须顶尖（教育、政务、法律），比如在 2025 年高考数学新高考卷实测拿到 144/150，中文复杂推理居国内榜首
国内首个 256 K token 对话模型，单条上下文 > 128 K（长合同、源代码库、历史聊天）
成本：0–32 K 输入只要 ¥0.8/百万 token，综合成本是上一代模型的 1/3
能够“看图说话”或读视频（电商质检、巡检、短视频客服）：60 项公开多模态基准 38 项第一
通过中国网信办算法备案：豆包已完成“网信算备 110108823483901230031”备案，可直接商用

心动吗？如果你要做一个 AI 应用，我想以上每一项都对你的模型选型很重要。

PromptPilot

随着豆包大模型 1.6 更新的，还有今天的主角 PromptPilot

众所周知，Prompt（提示词）作为大模型的核心输入指令，直接影响模型的理解准确性和输出质量。优质的 Prompt 能显著提升大语言模型处理复杂任务的能力，如逻辑推理、步骤分解等。

作为 AI 应用的资深玩家，写提示词几乎成了每天必须要做的事情，我不但使用 AI 工具，还开发 AI 产品。就拿最近做的一个 RAG 项目来说，在整个 RAG pipeline 中，有一个很重要的环节就是 “响应生成”。顾名思义，就是通过 prompt 驱动 LLM 生成结果。其实 prompt engineering（提示词工程）在整个 AI 应用中的性价比是极高的，要知道对整个技术工程进行优化的成本其实是相当大的，而且往往有时候投入产出不成正比，但 prompt engineering 不一样，一个好的提示词返回的结果质量可能比一个差的提示词强 10 倍，这在我们研发团队内部是有共识的。

prompt engineering 看起来是叫“提示词工程”，但在实践中，它缺少传统工程的严谨范式，它不像其他可工程化的技术那样有明确的流程和标准，甚至与传统‘技术’的关联也显得不那么紧密。写提示词不用懂技术，不用会编程，语文和表达力好就够用了。

然而这正是这个问题的症结所在，没法工程化，写提示词不成了管理的玄学了吗？系统、应用可不能由着你的性子玩儿“抽卡”啊，技术上一定要落地，一定要明确才行。但整个 AI 生态上，大家都在忙于开发模型，忙于开发基于模型的应用，或者大家觉得写提示词太简单？总之并没有很好地把写提示词这个问题工程化地解决好，对于 prompt engineering ，从我的经验看，至少有以下几个痛点：

太容易上手但又不容易写好
写出来效果不满意不知道怎么优化
没有客观的评价标准，很难说什么是好的提示词
经常变更，写了新版忘了旧版，版本和生命周期全靠手动维护

随着我们项目开发的深入，以上这些问题我们也使用了一些办法，比如：

利用提示词模板固定提示词，将变量提出，前期手动管理提示词和提示词模板的版本与生命周期，后期开发系统功能来管理。
与客户一起编写 Q/A 手册，一来为了将问题和标准回答定义清晰，二来为了验收做准备。研发团队基于 Q/A 可以有的放矢地对整个工程以及提示词进行优化。
虽然客户不一定懂 prompt engineering，但知道什么是满意的结果什么是不满意的结果，通过点头 Yes 摇头 No 的方式来逐步固定提示词的衡量标准

其实从项目和工程的角度，诸如以上的办法我们还有一些，但作为一个开发者，这些办法一点儿“技术的味道” 都没有，它很别扭，不是说我们要为了技术而技术，而是技术是确定性的，可落地的，有保障的东西，没有工程来管理这个事儿，总让我不踏实。整个 prompt engineering 的过程可以说一点儿都不丝滑。里面有很多人工、手动、流程和制度的东西，太原始了，啥呀这是，什么时代了，一定有更好的解决办法才对。所以我一直在找，幸运的是我没找太久就看到了 PromptPilot ，只一眼，我就知道，就是它了，它能解决我的问题！

PromptPilot 简介

“

火山引擎出品的 PromptPilot 提供全流程智能优化，涵盖生成、调优、评估和管理全阶段。

我引入了官方文档的一句话，我想这句话就够了，一句话就解决了我之前所说的几乎所有痛点。

目前可以通过两个入口使用（限时免费 90 天 2025.06.11-2025.09.11）：

独立站：https://promptpilot.volcengine.com/home
火山方舟：https://console.volcengine.com/ark/region:ark+cn-beijing/autope/startup?

下面我分别说一下它是怎么解决我的痛点的。

从生成一个 prompt 开始

我经常看到一些刚接触 AI 大模型的伙伴，在起初面对大模型时手足无措，不知道应该怎么写 prompt ，实际上我开始也不太清楚要怎么写，但好在我经常写文章，还有一些经验，至少我能把事儿说明白，大模型给我的反馈也还不错，我把我的这种方法称为 “白描”。然而并不是所有的事情都可以通过“白描” 来解决，有时候你用对了一个专业词汇就能够提升 90% 的效果，而正常情况下我们不太可能对所有领域的专业知识都精通，所以用不对词汇，写不好提示词几乎成了常态。

于是我们好像很崇拜那些把提示词写的很好的人，纷纷效仿、分享、学习提示词，比如李继刚，他写的提示词用到了编程语言 Lisp 的一些特点。Lisp? 别说外行了，就是专业的程序员也很少有会的了。

那我们怎么办呢？就像你明明来到了装有宝藏的房间大门前，却说不出打开门的咒语，一个劲儿地在那儿：“阿巴阿巴” ，像个傻子一样。

promptpilot 给了我答案，那就是：“用魔法打败魔法，最终实现 prompt 袪魅”

这里我输入了一行自己写的 prompt： “判断舆论的内容对出行行业的影响”，点击 “生成 prompt” 就会在右边自己生成一个结构化的 prompt:

 1你的任务是判断给定舆论内容对出行行业的影响。请仔细阅读以下舆论内容，并根据出行行业的特点进行评估。
 2舆论内容：
 3<public_opinion>
 4{{PUBLIC_OPINION}}
 5</public_opinion>
 6在评估舆论对出行行业的影响时，请按照以下步骤进行分析：
 71. 仔细阅读整个舆论内容，明确其核心观点和主要信息。
 82. 思考出行行业的各个方面，如交通方式、市场需求、企业运营、政策法规等。
 93. 分析舆论内容可能对出行行业的这些方面产生的直接或间接影响。
104. 考虑舆论的传播范围、影响力和受众反应，以及这些因素如何放大或缩小对出行行业的影响。
115. 形成初步判断，并再次检查，确保没有遗漏重要细节。
12
13在<思考>标签中详细分析舆论对出行行业的影响，考虑其可能涉及的各个方面。然后在<判断>标签中给出明确的影响判断结果，如“积极影响”“消极影响”“无明显影响”等。最后，在<解释>标签中详细解释你的判断理由。
14<思考>
15[在此详细分析舆论对出行行业的影响]
16</思考>
17<判断>
18[在此给出明确的影响判断结果]
19</判断>
20<解释>
21[在此详细解释判断的理由]
22</解释>
23请确保你的判断客观公正，并基于对舆论内容和出行行业的综合分析。如果舆论内容对出行行业的影响模棱两可，请在解释中说明你的考虑过程。

promptpilot 不但生成了结构化的 prompt，还自动提取出了变量 {{PUBLIC_OPINION}}。此外在现有结构化 prompt 的基础上还可以点击功能按钮持续优化。

这个功能总结来说就是：“简单描述你的需求，一键生成结构化的 prompt，输入你的修改意见，即刻智能改写。也可以框选局部文字，精准调整每个细节，帮你初步获得一个不错的 prompt”

不知道是不是我的错觉，因为最近一直在 vibe coding，所以用着用着 promptpilot 总感觉他们产品的很多功能可能就是 AI 写的，哈哈。

我们稍微想一想这个功能的实现原理。我给他一段自己写的 prompt，他给我一段丰富的结构化的 prompt，还能继续优化，这一看就是用提示词让 AI 对我的提示词进行了重写啊。这不就是 “用魔法打败魔法” 吗？所以对 prompt 袪魅吧朋友们，也没啥难的，但我一直对 AI 是有警觉的，我的意思是工具你可以用，好的工具更可以用，你完全可以放心大胆的使用 promptpilot，但请你看一看这个名字里有个 pilot，领航员。看过拉力赛车吧，坐主驾旁边念路书的那哥们，很重要，但是没他人家主驾也能开车。《飞驰人生 2》中张驰在最终的比赛时，能不靠路书心不慌、面对使坏的对手大胆碰撞超车，赢得比赛的胜利,靠的是自己的经验和能力。

promptpilot 或任何 AI 工具给你的东西，至少你要看一下，最好跟着他学习成长起来，如果渐渐地把自己的主动思考“让渡” 出去，最终你可能会成为个 “废物” ，最简单的提示词你都不会写了，这不是什么危言耸听，看看《机器人总动员》中，远在宇宙飞船中的人类因为过度依赖机器人自己什么都不干变得又胖又无能的样子，那可能就是你的未来。

调试 prompt

写好了 prompt 以后，我们还需要调试，点击“验证 prompt" , 进入调试界面：

进入到调试页面后，我们可以设置变量、继续改写与优化 prompt、选择不同的大语言模型，并生成模型回答，总之就是不断调试并查看 prompt 的最终生成效果如何。

在你不断优化 prompt 的过程中无需关心版本的问题，系统会自动记录并管理提示词版本，你可以放心回退：

评测

在完成调试后，接下来就该进行评测了。

评测的目的是：在不同数据情况下验证 prompt 的效果如何，用各种 case 来检验 prompt 写的有没有问题，进而有针对性的进行优化。

了解了目的，我想下一步你一定猜到了，那就是准备评测数据。

哎呀，准备数据，这就有点儿烦人了，但没关系，promptpilot 帮你做了一个“AI 生成变量” 功能，之前生成的 prompt 不是已经自动帮我们提取出了变量了吗？在此基础上，它还可以再帮我们生成变量的数据，这评测数据不就有了吗？

如上图所示，一键生成了三行数据，三个变量自动生成，我们只需要根据自己的实际情况稍微调整一下内容，再点击一下蓝色按钮就可以批量生成模型回答了。

当然你也可以自己做评测数据，根据要求上传个带变量名字段的文件就可以：

你还可以对模型回答的结果进行评分，就是看回答的内容是否是按照你的提示词要求给的，质量如何。

评分甚至可以让 AI 自动评，评分规则也可以自己写或让 AI 帮你写。

可能你注意到了有一列是 “理想回答”，我个人认为这一列非常重要，所谓定标准，就是要告诉人家什么是好的，一个问题问出去，如果你自己都不知道什么是好的答案，那 AI 其实也无能为力，它还没有那么聪明。这一点可能对于大部分 C 端用户不太好接受，因为就像你没有使用苹果手机前你是不知道你想要一个 iPhone 的，长期以来你被创造出来的需求所满足，习惯了，你觉得别人告诉你喜欢什么很正常，你自己不知道也很正常。

对，是很正常，那是因为场景不同。在面对不同客户，不同需求，不同场景下，我们的解决方案也不同。对于 C 端场景可能真的就是那样，商家可以创造需求，创造价值。但对于 B 端客户是需要解决问题、满足需求，不要乱创造你以为的价值。

在 B 端场景下，需求必须是明确的，解决的问题是清晰的，问题的答案是满意还是不满意也一定得是确定的。这是项目落地的必要条件！

就像考试的试题有标准答案一样，当有了标准答案，自然就有清晰的方向和路径来解题了。所以 “理想回答” 这一列的重要性不言而喻。无论对于评分还是后续的智能优化都有极大的帮助，原因很简单，目标有了，剩下的就是如何达到目标的事儿了。

智能优化

当你完成了评测，就可以点击右上角的 “智能优化”

大模型将对 Prompt 进行优化（模型回答和评分齐全的数据会用于智能优化），优化完成后你将获得：1.AI 智能优化后的 Prompt；2. 使用新 Prompt 生成的回答与评分

优化完成后，还将输出一份内容详实的优化报告

这一步其实还是对我最初的 prompt 进行优化，只不过因为有了更多的评测数据以及评分作为依据，优化方向更为明确，那么优化结果也一定更切合实际。

视觉理解

因为 prompt 是文本，promptpilot 最终生成、优化的也一定是 prompt 文本。也就是说输出是定死了的，就是“文本”，但输入可是多样的，除了文本的理解，promptpilot 还支持视觉理解。别误会，目前只支持图片。

我们来举一个具体的例子，我来一步一步操作一下整个流程。

首先我们创建提示词，我的初始提示词是：

1“为了安全生产，你需要根据生产车间的图片，判断生产车间是否存在违规操作设备和未佩戴安全帽的情况，需要给出违规类别。”

我看了下右边生成的 prompt 觉得变量名太长，于是我想改一下，把变量名改成 image_url，就直接鼠标选中变量名进行改写

改写生成后的 prompt 是这样：

 1你是一位专业的图像分析专家，专注于安全生产领域。你的任务是根据提供的生产车间图片，判断车间是否存在违规操作设备和未佩戴安全帽的情况，并给出违规类别。
 2
 3## 输入：
 4- 生产车间图片：{{image_url}}
 5
 6## 判定标准与违规类别定义：
 71. **`是否存在违规操作设备`**: （字符串，"是"/"否")
 8 - **判定**: 图像中是否存在工人违规操作设备的情况？
 9 - "是": 至少有一人正在违规操作设备。
10 - "否": 无人违规操作设备，或者图像中无人操作设备。
11 - **违规类别**: 若判定为“是”，违规类别标记为“违规操作设备”。
12
132. **`是否存在未佩戴安全帽`**: （字符串，"是"/"否")
14 - **判定**: 图像中是否存在工人未佩戴安全帽的情况？
15 - "是": 至少有一人未佩戴安全帽。
16 - "否": 所有人都佩戴了安全帽，或者图像中无人。
17 - **违规类别**: 若判定为“是”，违规类别标记为“未佩戴安全帽”。
18
19## 输出格式：
20请按照以下 JSON 格式输出你的判断结果。所有字段的值必须是字符串 “是” 或 “否”，违规类别若存在多个以逗号分隔，若不存在违规则标记为“无”。
21{
22 "是否存在违规操作设备": "是",
23 "是否存在未佩戴安全帽": "否",
24 "违规类别": "违规操作设备"
25}

接着我们开始调试这个视觉理解的 prompt：新建一个内容理解任务，点击加号

复制之前改写好的完整 prompt 到调试 prompt 栏里面

上传一个图片数据，这里采用 url 上传，并点击确定

1https://img0.baidu.com/it/u=1094762033,1331895175&fm=253&fmt=auto&app=138&f=JPEG?w=500&h=561

选择 target model，即：推理模型，多模态选择带 thinking 的模型

保存并生成模型回答

获取理想回答：平台对同一个 case，提供了不同模型回答的结果给用户参考，用户可以自由选定好的答案，并基于选定的答案进行反馈拿到理想回答。这里作为示例，取模型回答 2 的结果，并点击应用。

感觉他的思考过程太重复啰嗦了。因此做如下反馈：

1思考过程简洁一点

然后就可以保存并添加到评测集了。后面就是添加评测数据，你可以一行一行编辑，也可以直接上传个文件，比如

最终的效果类似这样：

然后就可以按照前文一步一步地进行 prompt 调优、打分、智能优化并生成优化报告了。

你看，总之，图片它也是能够理解的，甚至还有更复杂的任务也可以（不过还处于 beta 状态），比如在一个复杂场景下检查人数：

promptpilot 使用流程

前文写的内容有点儿多，这里我们总结一下 promptpilot 的使用流程，我们从官方文档中找个图来说明一下

初看可能有点儿复杂，但只要你真正用几回 promptpilot 再看这个图就会感觉无比的清晰了。

我们通过视频再快速回顾一下 promptpilot 的核心功能

已关注

Replay Share Like

观看更多

退出全屏

切换到竖屏全屏**退出全屏

小盒子的技术分享已关注

Share Video

，时长01:35

0/0

00:00/01:35

切换到横屏模式

继续播放

进度条，百分之0

Play

00:00

01:35

倍速

全屏

倍速播放中

0.5倍 0.75倍 1.0倍 1.5倍 2.0倍

超清流畅

Your browser does not support video tags

继续观看

不止于工具：PromptPilot如何将AI开发从“手工作坊”推向“工业时代”？

观看更多

转载

不止于工具：PromptPilot如何将AI开发从“手工作坊”推向“工业时代”？

小盒子的技术分享已关注

Share点赞Wow

Added to Top StoriesEnter comment

Video Details

提示词工程产品对比

横向对比

其实还有其他的主流的提示词工程解决方案，比如：

Azure Prompt Flow（微软）
Vertex AI Studio（谷歌）
Amazon Bedrock Prompt Playground（亚马逊）

篇幅限制，我就不一一介绍了，这里简单介绍一下 Vertex AI Studio，通过对比，你会对 PromptPilot 的水平有更深刻地了解。

Google 家的 Vertex AI studio 提供了一个直观界面，让你能够以低代码或甚至无代码的环境来构建 GenAI 应用，你能通过 Prompt, 连接后台，最后反馈结果。

关于提示词工程部分，它的核心功能有：零次提示（Zero-shot prompting）、单次提示（One-shot prompting）和少量提示（Few-shot prompting）。

零次提示：是指在不提供任何例子的情况下，直接向模型发出请求，使其适应特定的行为。
单次提示：是指向模型提供单个任务示例，以此来引导模型的输出。
少量提示：则是提供少量的任务示例。

然后就没有然后了，对，就这些，界面很 google 很简单。

我看了一下 Azure Prompt Flow 和 Amazon Bedrock Prompt Playground 感觉产品逻辑和 Vertex AI studio 差不多。

你可能已经发现，与 PromptPilot 相比，谷歌、微软、亚马逊这三大云服务商在提示词工程上的产品功能显得相对单薄。这主要是因为它们的产品方向和侧重点有所不同：三大云把 Prompt 工程塞进整条 LLM DevOps 流水线，它们把 Prompt 当作 LLM 应用流水线里的一环，仅提供“写＋测”或“写＋存＋跑”，深度要靠开发者自己拼接脚本或流水线。而 PromptPilot 把“提示词”当作核心产品做了纵深。把 “提示词” 的写 → 调 → 测 → 版本管理等全部动作做了深耕。

因此，当你的主要痛点就是“写好提示词”而非“布好全链路”，PromptPilot 会显得顺手；而当项目需要管部署、监控、成本、接第三方工具时，Prompt Flow 等全栈 IDE 的价值就会凸显出来。

而类似三大云厂商做的那种 LLM 流水线产品可以在火山引擎上找到，在 AI 时代，阿里云、腾讯云、火山引擎是我比较喜欢的国内云厂商三巨头。之前也用过华为云，它的市场占有率也很高，但可能客户群体和技术方向的问题，在 AI 时代，它的声音并不多。

纵向对比

从深耕提示词工程的角度来说，PromptPilot 身上也有不少优秀产品的影子，比如：promptlayer、Prompt Optimizer 。

有这么多优秀的产品，足以见得提示词工程的需求在一段时间内还是存在的，需要被满足。但对比多家产品，我觉得 PromptPilot 目前做的是最好的，没有之一。

最后

PromptPilot 的最大价值在于通过自动“写+测+改” 把写 Prompt 这件“小事” 完全工程化产品化，让使用者几乎零门槛的使用，无论对于开发者还是小白都非常友好，我猜测将来甚至可以直接集成到企业级 AI 开发流水线中。

另外不得不提一下的是，豆包大模型是商业模型，那么火山引擎作为一个云平台一定会引导用户用自家的大模型，所以构建“护城河” 这个事儿是一个常规操作，很正常。目前除了自家的豆包大模型，promptpilot 也支持 DeepSeek 等其他模型。

我相信未来在模型使用上，火山的策略不会那么激进，而会采用融合、共赢，权重优先的方式，长期允许多模型共存，但一定会在自家模型的推广和销售上大做文章。

最后，我想说，在 AI 领域，未来一定会有越来越多的新产品出现，而所有这些产品都像是一个时代的注脚，你需要明白的是，时代不同了，AI应用开发正在从“炼丹师”式的个人英雄主义，走向体系化的工业生产阶段。在这个过程要解决的问题和相应的机会会很多，但只有真正务实地的解决问题的团队才能够赢得未来，因为他们行动深刻表达了四个字：“价值创造”。

AI圈的新宠：Context Engineering

Tue, 22 Jul 2025 03:32:03 +0000

AI 的发展真是 “日新月异” ，新概念也是满天飞。去年还在折腾 “提示工程”（Prompt Engineering），今年就整出了 “上下文工程”（Context Engineering）

最近看到大佬们像 Andrej Karpathy、Harrison Chase 都在热议这个词。

Manus 这篇文章《AI 智能体的上下文工程：构建 Manus 的经验教训》更是对于做 Agent 的同行很有借鉴意义。

Context Engineering，到底是个啥？

想象一下你正在和一个姑娘约会，你只了解了姑娘的基本信息，于是你绞尽脑汁地想话题，想和姑娘接下来聊点儿什么，但你的知识储备、记忆力也一般，于是你买了个 AI 眼镜，但这玩意就像某度一样，问什么答什么，其他没问的一概不知，而且有时候还 “胡说八道”，于是你给姑娘带来了像机器人一样的约会体验，然后就没有然后了。…..

不得不说你是一个有“上进心”的人，觉得不能再给双方如此糟糕的体验了，为了自己的终身大事于是你决定要升级装备，你发现 AI 眼镜有 Plus 版本，你决定再给它一次机会。下单-约会-实战开始！

这一次，你按照 “指南” 提前给设备塞了点儿 “备忘录”——比如你们最近的聊天记录、姑娘的相关资料、甚至工具怎么用。于是你根据姑娘和你的共同喜好，组织了好多双方感兴趣的话题，成功引起了姑娘的兴趣，再深入了解下去发现你们有更多共同的兴趣和朋友，甚至精神层面也有共鸣，你们探讨了最近看的书，三观，以及处世哲学，然后时间不早了，你根据姑娘和你的综合情况在 AI 的帮助下快速选定了一家餐厅，邀请姑娘共进午餐，姑娘欣然接受。

可以说这次约会是成功的，AI 眼镜秒变神助攻！

这就是 Context Engineering 的本质：不是简单扔个问题给 AI，而是精心准备一堆“上下文”，让 AI 知道该怎么思考、怎么行动。简单说，它管着 AI“看到”的所有东西：系统提示、聊天历史、从数据库扒出来的数据、工具说明，甚至长期记忆。

Context Engineering 看起来比 “提示工程” 靠谱多了

“提示工程听起来就像日常聊天里随便问问，但工业级 AI 应用里，Context Engineering 才是艺术加科学——怎么塞对信息进上下文窗口，让 AI 一步步干活。”

而且现在时机成熟了，因为 AI 模型的“记忆窗口”从几千字扩到百万字了（像 GPT-4o 或 gemini-2.5），光靠一个完美提示不够用，得动态管理上下文，避免 AI“迷路”或胡说八道

老梗翻新？

老实说，初看起来 Context Engineering 多少有点儿新瓶装旧酒的意思，但细看起来确实有新意。

AI 从简单聊天工具进化到“代理”（agent），这些代理得处理复杂任务，比如帮你分析法律文件、写代码或管客户支持。单纯的提示工程像扔个球给 AI，Context Engineering 则是建个球场、定规则、备道具。

实际上 agent 开发者早就在干这活儿了，提炼出个概念来能吸引更多人注意，推动工具开发。哈哈，炒作的效果。

所以也有人吐槽：

“Context Engineering 不就等于语义搜索吗？很多人忘了老排名机制的重要性，非得追新潮。”
“dumping 数据进 AI 就算工程了？”

我发现 coder 这个群体嘴有时候是真臭啊，哈哈。

不过说的也没毛病，Context Engineering 就是整合了检索增强生成（RAG）、内存管理这些老技术，早期的 RAG 系统就已经在玩儿上下文检索了。所以，它不是从天而降的革命，而是对现有实践的升级包装。

我们做个表格来对比一下 Prompt Engineering 和 Context Engineering

总结

总之呢，AI 越来越复杂，得从“艺术”转向“工程”。但如果你只是随便玩玩 AI，不用纠结——它更适合开发者或企业。

参考

manus 的文章： https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

Rag chunk 之：Excel 文档解析

Fri, 06 Jun 2025 01:39:11 +0000

前言

处理 Excel 文件时会遇到一些独特的挑战。与典型的结构化格式不同，由于合并单元格、多个表头、嵌入式图表和非传统的布局（这些布局主要设计用于人阅读而非机器解析）等元素，这些文件在数据提取和处理方面存在障碍。

在处理 Excel 时可能会遇到各种 Excel 文件格式，从现代的 .xlsx 到旧版的.xls 或宏启用版的 .xlsm 文件，每种格式都需要不同的解析方法和库。跨工作表或单个工作表内的数据不一致进一步使过程复杂化。非标准文件通常缺乏统一性，呈现不同的列顺序、不一致的日期格式或列内混合的数据类型，需要强大的错误处理和数据验证机制。

合并单元格对解析算法来说尤其成问题，因为它们可以跨越多行或多列，使数据关联变得复杂。必须编写程序逻辑来准确处理这些合并区域。隐藏的行、列或工作表增加了另一层复杂性，需要彻底检查整个工作簿以确保完整的数据提取。

为应对这些挑战，必须开发稳健、灵活的解析解决方案。这通常涉及结合多种方法，例如使用专门的 Excel 解析库、为特定文件结构实现自定义逻辑，以及采用机器学习技术对半结构化数据进行模式识别。

预处理

在分块前处理合并单元格、复杂公式和非表格数据。这些属于预处理。

合并单元格问题

在对 Excel 进行分块之前，必须先把「合并单元格导致的信息缺失」消除，否则嵌入时会出现 NaN 或空字符串，严重影响检索召回。

为什么要先处理合并单元格？

我们以一个 “功能清单.xlsx” 为例：

读取时只保留左上角值：无论 openpyxl 还是 pandas.read_excel，合并区域内除左上角外其余格值会被置空。
行级分块会丢字段：合并了“模块名称”或“子系统”的行，在转换成文本时会缺列，导致检索无法定位。
RAG 检索依赖元数据：若模块名丢失，metadata_filter 将失效，回答准确率显著下降（内部测试下降 15–25 pp）。

解决方案

思路：

利用 ws.merged_cells.ranges 拿到所有合并区域
读取左上角值，遍历填充到区域内每个单元格。
调用 ws.unmerge_cells() 取消合并，再保存临时文件供 pandas / Unstructured 后续处理。

 1from openpyxl import load_workbook
 2
 3def explode_merged_cells(path_in: str, path_out: str):
 4 wb = load_workbook(path_in)
 5 for ws in wb.worksheets:
 6 for rng in list(ws.merged_cells.ranges): # 复制，以免迭代中修改
 7 ws.unmerge_cells(str(rng)) # 先解除，否则无法写值
 8 tl_cell = ws[rng.min_row][rng.min_col - 1] # 左上角 Cell
 9 for r in range(rng.min_row, rng.max_row + 1):
10 for c in range(rng.min_col, rng.max_col + 1):
11 ws.cell(r, c).value = tl_cell.value
12 wb.save(path_out)

核心 API 参考：unmerge_cells() 、merged_cells

Chunking 策略

我手头有一些《功能清单》和《工时评估表》就以这些文件为例，讨论一下具体的 chunking 策略，具体来说，是使用 两级分块

什么是“两级分块”？

两级分块本质固定：父 = 模块/功能域，子 = 行记录。

Azure 官方指南将这种把大块再拆子块的做法称作“层次化 chunking/hierarchical chunking”，可与 Auto-Merging Retrieval 等检索算法天然配合

功能清单与工时评估表本质是一条条功能点记录；行级粒度最能保持“一问就能命中一行”的高精检索。
单纯行级又易丢失上下文，例如“所属子系统”；用业务模块字段先聚合可在召回时带来更丰富的背景。
如果某模块非常大，使用递归切分（递归字符或 token 限长）可以在不破坏结构的情况下继续拆分。

具体来说是：模块 → 行先聚后拆，更适合 Excel 表中已有明确模块列、需要用向量库分区或 metadata 过滤的系统

处理流程上务必：

先处理合并单元格
行文本带列名
metadata 保留 module 字段，以便精准过滤与 Auto-Merging 聚合。而元数据的处理（模块、行号、sheet 名），决定了查询过滤与答案上下文的可控性。

详细说明

两级分块中的父和子，具体来说是：“摘要型父块 + 行级子块”

父块

父块的存在价值在于提供业务背景 + 索引锚点。比如 “模块 A：支付结算；记录 426 行” 。
父块采用“header + 小块”策略

为什么父块可只包含结构信息？

父块不包含子行信息，因为子块检索命中后，通过父 ID 回溯获得模块级上下文，提高回答完整度。
在层次化 (hierarchical) 分块体系里，“父块 (parent document)” 的核心职责是让检索器知道一批子块属于哪个业务语境，而不是存放子块的全文内容。
通常父块只保存模块级背景（例如模块名、描述、记录数等），不再内嵌每一行子块的具体文本；这样既保上下文，又避免重复嵌入

代码：父块仅含结构信息的实现

 1
 2import pandas as pd
 3from langchain.docstore.document import Document
 4from langchain.text_splitter import RecursiveCharacterTextSplitter
 5
 6df = pd.read_excel("functions_flat.xlsx", engine="openpyxl")
 7
 8# ➊ 生成父块——只保背景
 9parent_docs = [
10 Document(page_content=f"模块名称: {m}\n总记录数: {len(sub)}",
11 metadata={"module": m, "level": "parent"})
12 for m, sub in df.groupby("模块")
13]
14
15# ➋ 生成子块——行文本
16row_docs = []
17for _, row in df.iterrows():
18 md = "\n".join(f"**{c}**: {v}"for c, v in row.items())
19 row_docs.append(Document(page_content=md,
20 metadata={"module": row['模块'], "level": "child"}))
21
22# ➌ 可选：对子块再递归切分，确保 <2048 chars
23splitter = RecursiveCharacterTextSplitter(chunk_size=2048, chunk_overlap=256)
24child_chunks = splitter.split_documents(row_docs)

ParentDocumentRetriever 在检索时会先命中 child_chunks，随后自动用父 ID 把对应模块摘要拼回上下文。如需“关键列拼接”模式，只需把 row[[‘ID’,‘Name’]] 等字段 join 到父块内容。

子块

在“模块 → 行”层次化分块里，子块（child chunk）就是把 Excel 中“一行业务记录”转成能让向量检索与 LLM 都看得懂的最小语义单元。它既要携带行内全部有效信息，又不能冗余到超出模型窗口。

子块典型 Markdown／JSON 结构：

 1## 模块: 支付结算
 2**功能ID**: PAY-001 
 3**功能名称**: 创建收款单 
 4**功能类型**: 核心 
 5**COSMIC FP**: 6 
 6
 7{
 8 "module": "支付结算",
 9 "功能ID": "PAY-001",
10 "功能名称": "创建收款单",
11 "功能类型": "核心",
12 "COSMIC_FP": 6
13}

推荐生成流程（代码片段）:

 1import pandas as pd
 2from langchain.docstore.document import Document
 3from langchain.text_splitter import RecursiveCharacterTextSplitter
 4
 5df = pd.read_excel("functions_flat.xlsx", engine="openpyxl")
 6
 7child_docs = []
 8for idx, row in df.iterrows():
 9 module = row["模块"]
10 # —— 1) 行→Markdown
11 body = "\n".join(f"**{c}**: {v}"for c, v in row.items())
12 # —— 2) 写入 Document
13 child_docs.append(
14 Document(
15 page_content=f"# 模块: {module}\n{body}",
16 metadata={
17 "module": module,
18 "row_id": idx + 2, # Excel 行号（含表头补1）
19 "sheet": "功能清单"
20 }
21 )
22 )
23
24# 3) 控制长度，避免超窗口
25splitter = RecursiveCharacterTextSplitter(
26 chunk_size=2048, chunk_overlap=256
27)
28child_chunks = splitter.split_documents(child_docs)

标题行

行级子块一定写列名-值对
父块按需保存一次表头或仅存摘要

父子块生成策略

在 Excel → 向量库的 RAG 管道里，最省事、也最被 LangChain/LlamaIndex/Haystack 等工具链推荐的做法，就是 “在同一遍遍历中同时生成父块和子块，并用 module 或 parent_id 把两者关联起来”。这样既避免二次扫描，又保证所有子块天生带着正确的父信息，检索器便能先召回精确的行级子块，再顺着指针把对应的模块级父块自动补进上下文，实现“精召回 + 背景补全”的最佳组合。

一遍循环生成父子块的核心流程

步骤 0：展开合并单元格用 openpyxl 的 unmerge_cells 把合并区域拆开，再把左上角值填满整块；或用 pandas.ffill() 向下补齐。这样每行都能拿到正确的模块字段

步骤 1：遍历行 → 同时产出父块与子块

 1import pandas as pd
 2from langchain.docstore.document import Document
 3from langchain.text_splitter import RecursiveCharacterTextSplitter
 4
 5df = pd.read_excel("functions_flat.xlsx", engine="openpyxl").ffill()
 6parent_seen, parents, children = {}, [], []
 7splitter = RecursiveCharacterTextSplitter(chunk_size=2048, chunk_overlap=256) # 控长:contentReference[oaicite:7]{index=7}
 8
 9for idx, row in df.iterrows():
10 mod = row["模块"] # ① 遇到新模块先建父块
11 if mod notin parent_seen:
12 parent_seen[mod] = Document(
13 page_content=f"模块: {mod}",
14 metadata={"module": mod, "level": "parent"}
15 )
16 parents.append(parent_seen[mod])
17
18 body = "\n".join(f"**{c}**: {v}"for c, v in row.items()) # ② 行→Markdown，保留列名
19 child = Document(
20 page_content=body,
21 metadata={
22 "module": mod,
23 "parent_id": id(parent_seen[mod]), # 或直接存 module
24 "row": idx + 2
25 }
26 )
27 children.extend(splitter.split_documents([child])) # 行过长再递归切

父块只存简短摘要（如模块名、记录数），避免重复嵌入。
子块带齐列名-值对、行号及父引用，保证可追溯。社区经验贴也强调“列名+值”比裸值更利于语义检索

步骤 2：写入向量库只向量化子块，将 module 作为 partition key 或 metadata。父块可放旁路索引，或与子块一同存但不做向量化。

步骤 3：检索时自动拼接用 LangChain ParentDocumentRetriever、LlamaIndex AutoMergingRetriever 或 Haystack Auto-Merging Retriever：

先做向量检索拿到 k 个子块；
按 parent_id/module 查父块；
拼 “父摘要 + 命中子块(±近邻)” 送入 LLM。

检索流程

过滤：查询时先用 filter={“module”: <候选模块>} 做向量库精搜；Milvus 文档示例说明 filtered search 会先裁剪候选集再做 ANN，比全库检索快 2-4×
Auto-Merging：若一次命中同模块多行，LlamaIndex/Haystack 会把这些行和父摘要合并，避免窗口碎片化

注意事项

其他 chunking 策略

基于工作表和基于行的分块
基于列的拆分
混合与滑动窗口技术

用于 Excel 分块的工具和库

pandas

Python 的 pandas 库是许多 Excel 处理任务的核心，为读取 Excel 文件提供了强大的分块支持。 read_excel() 函数的 chunksize 参数允许进行内存高效、固定大小的分块

openpyxl

对于更复杂的 Excel 结构，openpyxl 库提供了对 Excel 文件解析的粒度控制，使其适用于基于内容的分块方法，能够有效处理合并单元格、公式和其他非标准元素。

xlrd

xlrd 库虽然主要针对较旧的.xls 格式，但对于遗留系统仍然具有相关性，并提供快速解析功能，在混合分块方法中，当速度至关重要时，这些功能非常有用。

RAG 系统文本切分：从固定长度到智能检索的六种方法解析

Mon, 02 Jun 2025 03:18:54 +0000

一、固定大小切分（Fixed-size chunking）

优势

顾名思义且容易实现。由于直接分割可能会破坏语义流程，建议在两个连续的片段之间保持一些重叠。

劣势

破坏语义结构：固定大小切分可能在句子或段落中间进行切分，导致语义信息被割裂，影响模型对文本的理解。
上下文信息丢失：由于切分不考虑文本的语义边界，相关信息可能被分散到不同的块中，导致模型在处理时缺乏必要的上下文支持。
缺乏灵活性：固定大小切分无法适应不同文本结构的变化，对于结构复杂或格式不一致的文档，可能导致切分效果不佳。
影响检索效果：在基于检索的生成任务中，固定大小切分可能导致相关信息被分散，降低检索的准确性和生成结果的质量。
处理长文本的挑战：对于包含长句子的文本，固定大小切分可能无法完整保留句子信息，影响模型的理解和处理能力。

缺点较多，不建议在大多数真实生产场景中使用。

二、语义切分（Semantic chunking）

原理概述

语义分块的核心思想是通过计算相邻句子的嵌入向量之间的相似度，识别语义上的断点，从而将文本划分为语义连贯的块。具体步骤包括：

句子分割：将文本按标点符号（如句号、问号等）分割成句子。
嵌入计算：使用嵌入模型（如 OpenAI Embedding）计算每个句子的向量表示。
相似度计算：计算相邻句子之间的语义相似度。
断点识别：当相邻句子的相似度低于设定阈值时，认为存在语义断点，进行分块。
块生成：将相似度高的句子合并为一个语义块。

这种方法旨在确保每个块内部的语义连贯性，从而提高检索和生成的准确性。

优势

语义完整性：通过识别语义断点，避免将相关内容分割到不同的块中，保持信息的完整性。
提高检索准确性：语义连贯的块有助于向量检索系统更准确地匹配用户查询，提高检索效果。
减少冗余信息：避免将无关信息混合在一个块中，减少噪声干扰。

劣势

计算成本高：需要计算大量句子之间的相似度，计算资源消耗大，处理速度较慢。
实现复杂：涉及嵌入计算、相似度分析等步骤，算法实现相对复杂。
效果依赖数据类型：在某些数据集上，语义分块的效果可能不如固定大小分块或递归分块。

语义分块在保持文本语义完整性方面具有优势，适用于对语义连贯性要求高的任务，如复杂问答系统。然而，其高计算成本和实现复杂度使其在资源受限或对处理速度要求高的场景中不太适用。相比之下，递归切分方法实现简单、处理速度快，适用于结构清晰的自然语言文本。因此，选择合适的分块策略应根据具体任务需求、数据类型和可用资源综合考虑。

三、基于文档结构的切片（Document structure-based chunking）

文档结构化分块（Document Structure-Based Chunking）是一种利用文档自身结构进行内容切分的策略。其核心思想是根据文档的自然组织形式（如标题、段落、章节、函数等）进行分块，以保留语义完整性和上下文连贯性，从而提升检索和生成的效果。

“Document structure-based chunking”（基于文档结构的切分）不是按固定长度或句子切，而是“按逻辑块”划分内容，常见于 Word、PDF、HTML 等格式的企业文档处理中，尤其适合处理说明书、规约、设计文档的场景。

原理概述

文档结构化分块的基本原理是：

结构感知：识别文档中的结构元素（如 Markdown 的标题、HTML 的标签、代码中的函数或类等），并以这些元素作为分块的边界。
语义完整：确保每个分块在语义上是完整的，避免将相关内容拆分到不同的块中。
上下文保留：通过保留文档的结构信息，维护内容之间的逻辑关系，增强模型对上下文的理解。

例如：在处理包含 Markdown 格式的文档时，可以使用 LangChain 提供的 MarkdownHeaderTextSplitter 类，根据标题层级（如 #、##、###）进行分块，从而保留文档的层次结构。

原理解析

1. 结构识别

从文档中提取结构元素，包括但不限于：

标题层级（如 H1/H2/H3、1.、1.1、1.1.2）
段落、表格、列表、分隔线
样式信息（加粗、缩进、字号、字体）
页面结构（页眉页脚、分页、目录）

这些结构在不同文档格式中的表现形式不同，例如：

Word：段落样式 + Outline Level
PDF：字体大小、粗细、缩进等视觉特征
HTML：DOM 节点层级

2. 结构驱动的切分逻辑

常见策略：

按每一个小节（如 1.1、1.2.1）作为一个 chunk，或多个小节合并为一个 chunk
同一标题下的所有段落视为一个逻辑块
若小节内容过多，则再结合递归切分或 token 限制切分

关键不是按“多少 token”切，而是“从属于哪个结构单元”切。

3. 结构标签保留（可选）

切分后的 chunk 还可保留其结构标识，如：

1{
2 "chunk": "本系统支持 7 层安全防护措施……",
3 "section": "2.3 安全架构设计"
4}

这便于：

检索时进行 rerank
LLM 回答时增强上下文定位感（结构提示）

举个例子:

给定这样一段 Word 文档内容：

11. 系统概述
2 介绍系统的设计目标与背景。
32. 功能模块
4 2.1 用户管理
5 包括登录、注册、权限分配等功能。
6 2.2 设备管理
7 支持设备的接入、控制与监控。

Structure-based Chunking 结果可能是：

Chunk 1: 1. 系统概述介绍系统的设计目标与背景。
Chunk 2: 2.1 用户管理包括登录、注册、权限分配等功能。
Chunk 3: 2.2 设备管理支持设备的接入、控制与监控。

docx2python 示例：

示例目录：

我们将把 Word 文档解析成如下结构：

 1[
 2 {
 3 "id": "1",
 4 "title": "1. 系统概述",
 5 "level": 1,
 6 "content": "……正文内容……"
 7 },
 8 {
 9 "id": "1.1",
10 "title": "1.1 功能模块",
11 "level": 2,
12 "content": "……正文内容……"
13 },
14 {
15 "id": "2",
16 "title": "2. 技术架构",
17 "level": 1,
18 "content": "……正文内容……"
19 }
20]

完整代码：解析 Word 文档结构和正文内容

 1from docx2python import docx2python
 2import re
 3import json
 4
 5def get_level_and_id(title: str):
 6 """
 7 从标题行中提取编号和层级（例：1.2.3 → level 3）
 8 """
 9 match = re.match(r"^(\d+(\.\d+)*)(\s+|$)", title.strip())
10 if match:
11 id_str = match.group(1)
12 level = id_str.count(".") + 1
13 return id_str, level
14 returnNone, None
15
16def parse_docx_structure(docx_path: str):
17 doc_result = docx2python(docx_path)
18 body = doc_result.body
19
20 parsed_chunks = []
21 current_chunk = None
22
23 for section in body:
24 for para_group in section:
25 for para in para_group:
26 text = para.strip()
27 ifnot text:
28 continue
29
30 # 如果段落以编号开头，视为新段落标题
31 id_str, level = get_level_and_id(text)
32 if id_str:
33 # 存储上一段内容
34 if current_chunk:
35 parsed_chunks.append(current_chunk)
36
37 current_chunk = {
38 "id": id_str,
39 "title": text,
40 "level": level,
41 "content": ""
42 }
43 else:
44 # 不是新段落标题，加入当前内容
45 if current_chunk:
46 current_chunk["content"] += text + "\n"
47 else:
48 # 文档开头没有编号，强行起一块
49 current_chunk = {
50 "id": "",
51 "title": "",
52 "level": 0,
53 "content": text + "\n"
54 }
55
56 if current_chunk:
57 parsed_chunks.append(current_chunk)
58
59 return parsed_chunks
60
61# 示例使用
62chunks = parse_docx_structure("example.docx")
63
64# 美观打印输出
65for chunk in chunks:
66 print(f"\n=== {chunk['id']} ({chunk['title']}) ===")
67 print(chunk["content"])
68
69# 可选：保存为 JSON
70with open("parsed_chunks.json", "w", encoding="utf-8") as f:
71 json.dump(chunks, f, ensure_ascii=False, indent=2)

在实际应用中，可以根据文档的格式选择合适的分块工具和方法：

Markdown 文档：使用 MarkdownHeaderTextSplitter，根据标题层级进行分块。
HTML 文档：使用 HTMLHeaderTextSplitter，根据 HTML 标签（如 <h1>、<h2>）进行分块。
代码文件：使用 PythonCodeTextSplitter 等工具，根据函数或类的定义进行分块。
表格数据：将表格内容格式化为模型易于理解的形式（如 HTML 的 <table> 标签、CSV 格式等），以保留表格的结构信息

这些工具通常会在分块的同时添加元数据（如标题、层级信息等），以便在后续的检索和生成过程中提供更丰富的上下文。

优势与适用场景

优势：

语义完整性强：每个分块通常对应一个完整的主题或功能单元，便于模型理解。
上下文清晰：保留了文档的结构信息，增强了内容之间的逻辑关系。
检索效果好：结构化的分块有助于提高向量检索的准确性。

适用场景：

结构清晰的文档，如技术文档、API 文档、法律文本等。
需要保留文档层次结构的应用，如知识库问答系统、文档摘要生成等。

注意事项:

文档结构不清晰时效果有限：对于结构混乱或缺乏明显结构的文档，结构化分块可能无法发挥优势。
块大小不均：不同结构单元的长度可能差异较大，需结合其他分块策略（如递归分块）进行优化。
实现复杂度较高：需要根据不同的文档格式设计相应的解析和分块逻辑。

文档结构化分块是一种有效的分块策略，特别适用于结构清晰、层次分明的文档。在实际应用中，可以结合其他分块方法（如递归分块、语义分块）进行混合使用，以获得更好的效果。

四、递归切分（Recursive Splitting）

“

实际上递归切分（Recursive Splitting）也是固定大小文本切块

在 RAG（Retrieval-Augmented Generation）系统中，递归切分（Recursive Splitting）是一种常用的文本分块策略，旨在将长文本有效地划分为适合处理的小块（chunk），以便后续的嵌入、检索和生成任务

工具：RecursiveCharacterTextSplitter (LangChain)
参数建议：
chunk_size=512 （适合多数 Embedding 模型）
chunk_overlap=128 （平衡上下文连贯性与冗余）
separators=["\n\n", "\n", "。", "？", "！", "；", "..."]（中文场景优化分隔符）
优势：先按大结构（标题）切，再按段落/句子细化，避免硬切关键信息。

原理概述

递归切分的核心思想是使用一组预定义的分隔符（如段落符、句号、空格等）按层次递归地将文本拆分成更小的块，直到每个块的长度满足设定的要求。

具体步骤如下：

初步切分：使用第一个分隔符（例如换行符 \n）对文本进行初步切分。
检查块大小：对于每个切分得到的块，判断其长度是否超过设定的最大块大小（chunk_size）。
递归处理：如果某个块的长度仍然超过 chunk_size，则使用下一个分隔符（例如句号。）对该块进行进一步切分。
继续递归：重复上述过程，依次使用预定义的分隔符列表中的下一个分隔符，直到所有块的长度都不超过 chunk_size，或者无法再进行切分。
合并块（可选）：在某些实现中，如果相邻的文本块合并后长度不超过 chunk_size，则可以将它们合并，以确保块的长度尽可能接近 chunk_size，同时保留上下文完整性。

这种方法的优点在于它能够尽量保留文本的语义结构，例如段落和句子边界，从而在保持上下文连贯性的同时，生成大小合适的文本块。

示例（LangChain）：

LangChain 提供了 RecursiveCharacterTextSplitter 类来实现递归切分。以下是一个使用示例：

 1from langchain.text_splitter import RecursiveCharacterTextSplitter
 2text_splitter = RecursiveCharacterTextSplitter(
 3 chunk_size=200,
 4 chunk_overlap=50,
 5 length_function=len,
 6 separators=["\n", "。", " ", ""]
 7)
 8text = "..." # 待处理的文本
 9texts = text_splitter.create_documents([text])
10for doc in texts:
11 print(doc)

在这个示例中：

chunk_size=200：设置每个文本块的最大长度为 200 个字符
chunk_overlap=50：设置相邻文本块之间的重叠长度为 50 个字符，以保留上下文
separators=["\n", "。", " ", ""]：定义了分隔符的优先级顺序，依次为换行符、句号、空格和空字符串。

这种方式确保了文本在切分时尽量保持语义的完整性和上下文的连贯性。

优势

保持语义结构：递归切分优先使用自然语言中的分隔符（如段落、句子等）进行切分，有助于保留文本的语义结构，减少信息碎片化的风险。
灵活的分块大小：通过递归使用不同的分隔符，能够根据文本的实际结构动态调整分块大小，适应不同长度和结构的文本。
适用于多种文本格式：递归切分方法适用于多种文本格式，包括自然语言文本、Markdown、HTML 等，能够处理结构复杂或层次分明的文档。
减少上下文割裂：通过在相邻文本块之间引入重叠部分（chunk_overlap），有助于保留上下文信息，提高模型对文本的理解能力。

适用场景

自然语言文本：如新闻文章、博客、书籍等，文本结构清晰，适合使用递归切分方法。
结构化文档：如 Markdown、HTML 等，具有明确的结构层次，递归切分能够有效地保留其结构信息。
需要保持语义完整性的任务：如问答系统、摘要生成等，对文本的语义连贯性要求较高，适合使用递归切分。

劣势

处理速度较慢：递归切分需要多次遍历文本，尤其是在处理大型文档时，可能导致处理速度较慢。
块大小不一致：由于依赖于自然语言的分隔符，生成的文本块大小可能不一致，这可能影响后续的处理效果。
计算资源消耗大：多次递归切分和合并操作可能导致较高的计算资源消耗，尤其是在大规模数据处理时。
对文档结构依赖强：递归切分依赖于文档的结构清晰度，对于结构不明确或格式混乱的文档，效果可能不佳。

不适用场景

结构化数据（如 Excel 表格）：Excel 表格中的数据通常以行和列的形式组织，递归切分无法有效保留其结构和语义信息。
代码或标记语言文档：对于包含代码块或标记语言（如 HTML、Markdown）的文档，递归切分可能会破坏其语法结构，影响后续处理。
多语言或混合语言文档：在处理包含多种语言的文档时，递归切分可能无法正确识别和处理不同语言的分隔符，导致切分效果不佳。
对块大小有严格要求的应用：某些应用对输入块的大小有严格限制，递归切分生成的不一致块大小可能不满足这些要求。

五、句子窗口检索（Sentence-Window Retrieval）

准确地讲，Sentence-Window Retrieval（检索期再扩窗）不是切片方式，而是检索策略 —— 先以“单句 chunks”建索引，命中后再把前后 N 句拼回去给 LLM。

原理概述

传统的 RAG 系统通常将文档按固定长度或段落进行切分，并对每个块进行向量化处理。然而，这种方法可能导致语义相关的信息被切割，影响检索效果。

句子窗口检索通过以下步骤优化这一过程：

按句子切分文档：将文档按句子进行切分，每个句子作为一个最小的检索单元。
构建句子窗口：对于每个句子，记录其前后若干个句子，形成一个“窗口”。这个窗口包含了目标句子及其上下文信息。
向量化处理：仅对目标句子进行向量化处理，而将其窗口信息作为元数据存储。
检索与生成：在检索阶段，根据用户查询与句子向量的相似度，找到最相关的句子，并将其对应的窗口信息提供给语言模型，以生成更准确的答案。

这种方法结合了细粒度的检索和丰富的上下文信息，提升了检索的精确度和生成的质量。

示例（LlamaIndex）

在 LlamaIndex 中，可以通过 SentenceWindowNodeParser 实现句子窗口检索： from llama_index.node_parser import SentenceWindowNodeParser

1node_parser = SentenceWindowNodeParser.from_defaults(
2 window_size=3,
3 window_metadata_key="window",
4 original_text_metadata_key="original_text",
5)

window_size=3：表示窗口包含目标句子前后各 3 个句子，共 7 个句子。
window_metadata_key 和 original_text_metadata_key：用于在元数据中标识窗口内容和原始句子

在检索阶段，可以使用 MetadataReplacementPostProcessor 将检索到的句子替换为其对应的窗口内容，提供给语言模型进行生成。

LlamaIndex 的 SentenceWindowRetriever 实践显示，对长段落文档回答的 F1 明显提升。
常用窗口：中心句 ± 3 句；别忘了把原句位置做 metadata，方便精确引用。

优势

提高检索精度：通过细粒度的句子级检索，提升了与查询的匹配度。
丰富上下文信息：窗口机制提供了更完整的上下文，有助于语言模型生成更准确的答案。
灵活的窗口大小：可以根据具体需求调整窗口大小，以平衡上下文信息量和模型处理能力。

适用于需要高精度检索和丰富上下文支持的场景，如问答系统、文档摘要等。

注意事项

窗口大小的选择：窗口过小可能导致上下文不足，过大则可能引入噪声信息。需要根据具体任务进行调整。
计算资源消耗：虽然只对目标句子进行向量化处理，但在检索和生成阶段，仍需处理较大的上下文窗口，可能增加计算负担。
模型输入限制：需要注意语言模型的输入长度限制，避免窗口内容过长导致截断。

六、自动合并检索（Auto-merging retrieval）

Auto-merging Retrieval（自动合并检索）本质上是一种检索策略，而非单纯的 chunk（文本切分）方法。要实现这一策略，确实需要配合特定的 chunk 策略，尤其是层次化的 chunking（Hierarchical Chunking）。

我们前文说的 “Document structure-based chunking”（基于文档结构的切分）就属于“Hierarchical Chunking”（层次化切分）策略的一种。

原理概述

自动合并检索的核心思想是将文档划分为多个层次的块（chunk），形成父子关系的树状结构。在检索过程中，如果多个相关的子块属于同一个父块，系统会自动将这些子块合并为其父块，从而提供更完整的上下文信息给大语言模型（LLM）

实现步骤

文档层次化拆分：使用如 LlamaIndex 的 HierarchicalNodeParser 或 Haystack 的 HierarchicalDocumentSplitter，将文档按预设的块大小（如 2048、512、128）递归拆分，构建出多层级的节点结构。
索引构建：将最小的叶子节点（最小块）进行向量化，并存入向量数据库中，供后续检索使用。
检索与合并：

在用户查询时，系统首先检索与查询最相关的叶子节点。
如果检索到的叶子节点中，有多个属于同一个父节点，并且超过设定的阈值（例如，超过该父节点子节点数量的50%），则系统会自动将这些子节点合并为其父节点，作为最终的检索结果返回

优势

增强上下文完整性：通过合并相关的子块，提供更连贯的上下文信息，减少信息碎片化。
提高生成质量：更完整的上下文有助于大语言模型生成更准确、相关性更高的回答。
降低幻觉风险：提供更全面的信息，减少模型因上下文不足而产生的错误回答。

注意事项

合理设置层次结构：根据文档的结构和内容，选择合适的 chunk 大小和层数，避免层次过多或过少影响检索效果。
调整合并阈值：根据具体应用场景，设置合适的合并阈值，确保在需要时合并相关子块，同时避免引入不相关的信息。
利用元数据管理父子关系：在构建层次结构时，确保每个子块都包含其父节点的引用信息，以便在检索时能够正确合并。

Document structure-based chunking 结合 Auto-merging Retrieval

要将“基于文档结构的切分”（Document Structure-Based Chunking）与“自动合并检索”（Auto-merging Retrieval）结合应用于 RAG（Retrieval-Augmented Generation）系统，可以按照以下步骤进行开发：

1 基于文档结构的层次化切分

目标：利用文档的结构信息（如标题、段落、列表等）进行多层次的切分，构建父子关系的树状结构。

实现方法：

使用工具：可以使用如 LlamaIndex 的 HierarchicalNodeParser 或 Haystack 的 HierarchicalDocumentSplitter。这些工具允许根据文档结构进行层次化切分。
设置参数：
block_sizes：定义每一层的最大块大小，例如 {2048, 512, 128} 表示父块最大为 2048 个单位，子块最大为 512 个单位，叶子节点为 128 个单位。
split_by：指定按何种单位进行切分，如按词（“word”）或句子（“sentence”）。
构建层次结构：通过上述工具和参数设置，将文档切分为多个层次的块，形成父子关系的树状结构。

2 构建向量索引与文档存储

目标：将最小的叶子节点进行向量化，并存入向量数据库中，同时保留父节点的信息以供后续合并使用。实现方法：

向量化叶子节点：使用如 OpenAI 的 text-embedding-3-small 或 SentenceTransformers 等模型，对叶子节点进行向量化。
存储向量：将向量化后的叶子节点存入向量数据库中，如 FAISS、Pinecone、Weaviate 等。
保留父子关系：在存储过程中，保留每个叶子节点与其父节点之间的关系信息，以便在检索时进行合并。

3 配置自动合并检索器

目标：在检索过程中，根据设定的阈值自动将相关的子块合并为其父块，提供更完整的上下文信息。实现方法：

使用工具：可以使用如 Haystack 的 AutoMergingRetriever 或 LlamaIndex 的 AutoMergingRetriever。
设置参数：
threshold：设定合并的阈值，例如 0.5 表示当超过 50% 的子块被检索到时，合并为父块。
document_store：指定包含父节点的文档存储。
检索流程：
根据用户查询，检索与查询最相关的叶子节点。
统计被检索到的叶子节点中，属于同一父节点的数量。
如果某个父节点下的被检索到的子节点数量超过设定的阈值，则将这些子节点合并为其父节点，作为最终的检索结果返回。

总结

在构建基于大语言模型（LLM）的检索增强生成（RAG）系统时，文本分块策略的选择对系统性能和生成质量具有决定性影响。本文深入探讨了六种主流的文本分块方法，分别是：固定大小切分、语义切分、基于文档结构的切分、递归切分、句子窗口检索和自动合并检索。以下是对这些方法的综合比较与应用建议：

1. 固定大小切分（Fixed-size Chunking）

优势：实现简单，计算效率高，适用于对语义完整性要求不高的场景。
劣势：可能破坏语义结构，导致上下文信息丢失，影响模型理解和检索效果。
应用建议：适用于结构简单、对语义连贯性要求不高的文本，如短消息、日志等。

2. 语义切分（Semantic Chunking）

优势：保持语义完整性，提高检索准确性，减少冗余信息。
劣势：计算成本高，实现复杂，效果依赖于数据类型。
应用建议：适用于对语义连贯性要求高的任务，如复杂问答系统、法律文档分析等。

3. 基于文档结构的切分（Document Structure-based Chunking）

优势：保留文档的层次结构，增强上下文理解，提高检索效果。
劣势：对文档结构依赖强，块大小可能不均，需结合其他策略优化。
应用建议：适用于结构清晰的文档，如技术文档、API文档、法律文本等。

4. 递归切分（Recursive Splitting）

优势：灵活适应不同文本结构，保持语义结构，减少上下文割裂。
劣势：处理速度较慢，块大小不一致，计算资源消耗大。
应用建议：适用于自然语言文本和结构化文档，需在处理速度和语义完整性之间权衡。

5. 句子窗口检索（Sentence-Window Retrieval）

优势：提高检索精度，丰富上下文信息，灵活的窗口大小。
劣势：窗口大小选择需谨慎，计算资源消耗较高，需注意模型输入限制。
应用建议：适用于需要高精度检索和丰富上下文支持的场景，如问答系统、文档摘要等。

6. 自动合并检索（Auto-merging Retrieval）

优势：增强上下文完整性，提高生成质量，降低幻觉风险。
劣势：需合理设置层次结构和合并阈值，依赖元数据管理父子关系。
应用建议：适用于结构清晰、层次分明的文档，结合其他分块方法使用效果更佳。

在实际应用中，选择合适的文本分块策略应根据具体任务需求、数据类型和可用资源综合考虑。对于结构清晰的文档，建议优先采用基于文档结构的切分方法，并结合递归切分优化块大小；对于对语义连贯性要求高的任务，可采用语义切分方法；对于需要高精度检索和丰富上下文支持的场景，可采用句子窗口检索或自动合并检索策略。此外，根据实际情况以上 chunk 策略不必拘泥于任何一种，可以混合使用。

Milvus 向量数据库快速入门（人话版）

Sun, 01 Jun 2025 04:03:27 +0000

Milvus 到底是干嘛的？

它是“给向量找对象”的超高速数据库——存向量、比相似、返回前 K 名。

Milvus 就是给「向量」找对象的数据库——它能帮你把一堆高维向量存好、管好、飞快地按“相似度”把最像的几条挑出来。

和普通数据库比，Milvus天生会“模糊配对”，不是 exact match 而是“谁更像”。
内核走的是“先分桶/建图，再局部暴力”，所以大规模也能搜得飞快。
2.x 版本把「数据落盘」「分布式容灾」都外包给 RocksDB + MinIO + etcd——省了你很多心。

先认几个关键词

部署使用

五步跑通「单机体验」+ 三步升级「小集群」

单机 5 步

拉镜像 docker run milvusdb/milvus:v2.4.3
建楼 create_collection()——确定字段维度、主键、向量字段。
搬人 insert() → flush()。
装电梯 create_index()；小数据直接 FLAT，大数据先 IVF，再视情况换 HNSW。
开门找人 load() → search()/query()；用完可 release().

变成 3 节点小集群

最常用的 5 步操作

建楼：create collection，把字段都定义好
搬人：insert，把向量和元信息塞进去；记得 flush() 真正落盘
装电梯：create index，选对索引类型，未来搜索才快
请保安开门：load，没 load 就像门锁着，啥也搜不到
找人：search（可加条件 expr），或者只按字段 query

索引怎么挑？

索引调优口诀

小样本先 FLAT 做 baseline——它慢但最准，方便肉眼看 Recall。
百万级优先 IVF_FLAT：调 nlist=√N 起步；提高 nprobe 越准越慢。
千万级冲 HNSW：关键参 M (边数) 和 efConstruction (建图宽度)，调高两倍能大幅增 Recall。
超高并发记得“机＋内存”一起扩——索引放内存，多副本才分摊 QPS。

别踩这些坑 💡

向量维度要统一：128 就全 128，别混着来。
插完别忘 flush：不 flush 就像东西放购物车没结账，搜索不到。
没 load 就搜索：会报错，先 load()。
内存不够全加载：用 Partition，分批 load()。
精度不满意：调 nprobe（IVF）或换 HNSW 试试。

十大踩坑 + 急救方案

再进阶一点点

Hybrid Search：边比向量相似度，边过滤价格 < 500 这种条件，SQL 味道更浓。
一致性模式：默认够用；真要跨机房强一致性就选 Strong。
持久化：Milvus 本身用 RocksDB ＋ MinIO 存数据，你不用操心怎么落盘。
与 RAG 的关系：大模型把文本→向量，Milvus 负责“最近邻检索”，再把查到的文档喂回模型。

跟其它工具怎么配？

LangChain / LlamaIndex：把 Milvus VectorStore 接进去即可，RAG 极速上线。
Spark / Flink：批量离线写入 Milvus；确保分批 1 万条以内避免 RPC 超时。
Airflow：定时 ETL → Embedding → Milvus；flush、compact 都能写成 task。

“到底需要多大机器？”——粗算公式

内存 ≈ （向量维度 × 4 bytes × 向量条数 × 1.4 倍索引系数）﹢ 元数据大小
例：1 亿条 768 维 → 768×4×1e8×1.4 ≈ 430 GB（得至少 512 GB 机器，或分区加载）。
硬盘 ≈ 内存 × 1.2（索引 + RocksDB + 日志）。

512G 内存看起来有点儿夸张，所以如果内存吃紧，可以参考以下方法进行优化：

Python 端到端 Demo （含增删改查）

 1from pymilvus import connections, Collection, utility, DataType, FieldSchema, CollectionSchema
 2import numpy as np
 3
 4connections.connect(host="localhost", port="19530")
 5
 6# 1. 建楼（如果已存在就删掉重建）
 7if utility.has_collection("demo"): utility.drop_collection("demo")
 8
 9schema = CollectionSchema([
10 FieldSchema("id", DataType.INT64, is_primary=True, auto_id=True),
11 FieldSchema("title", DataType.VARCHAR, max_length=200),
12 FieldSchema("price", DataType.FLOAT),
13 FieldSchema("emb", DataType.FLOAT_VECTOR, dim=128)
14])
15col = Collection("demo", schema)
16
17# 2. 插 10 条数据
18titles = [f"商品{i}"for i in range(10)]
19prices = [i * 10.0for i in range(10)]
20vecs = np.random.random((10, 128)).tolist()
21col.insert([titles, prices, vecs]); col.flush()
22
23# 3. 建 IVF 索引 & 加载
24col.create_index("emb", {"index_type":"IVF_FLAT","metric_type":"L2","params":{"nlist":64}})
25col.load()
26
27# 4. 搜索 + 过滤价格 < 50
28qv = [np.random.random(128).tolist()]
29hits = col.search(qv, "emb", {"metric_type":"L2","params":{"nprobe":8}}, limit=5, expr="price < 50")
30print([(h.entity.get('title'), h.distance) for h in hits[0]])
31
32# 5. 删除一条，再查
33del_id = hits[0][0].id
34col.delete(f"id in [{del_id}]"); col.flush()

RAG on 小盒子的技术分享

Google 刚刚把多模态检索，从“拼装工程”变成了“基础能力”

它到底强在哪，不只是“支持多模态”

最值钱的地方，是它终于不再要求你先做“翻译官”

一个特别容易被低估的能力：它可以表示“实体”，不只是“素材”

3072 维不是重点，重点是你终于可以按成本来调“语义密度”

免费吗？多少钱？

第一条是 Gemini Developer API。

第二条是 Vertex AI。

两个很容易踩的坑

它不会消灭所有复杂度，但它确实改写了“默认架构”

最后

3 毛钱干大事？ 用了几天豆包编程模型，我来扒一扒字节这波操作

兼容 Claude Code

第一种方式

第二种方式

核心能力体验

VLM：前端仔的末日… 还是福音？

聊聊技术底裤

测试

总结

怎样才算好文档

写文档是一种同理心的体现

让文档易于浏览

2. 写出高质量文本

3. 广泛有益于读者

4. 必要时打破规则

给 AI 一双 “慧眼”：深度评测 7 款主流 AI 搜索引擎（Tavily, SerpApi, Exa.ai 等）

给 AI 用的搜索引擎

为什么 AI 需要这样的搜索引擎？

流程示意

供应商

Tavily

核心 API

适用场景与优势

生态与集成

价格与配额

SerpApi

核心 API

适用场景与优势

生态与集成

价格与配额

Serper

核心 API

适用场景与优势

生态与集成

价格与配额

Exa.ai

核心 API

适用场景与优势

生态与集成

价格与配额

Ollama Web Search

核心 API

适用场景与优势

生态与集成

价格与配额

Jina AI DeepSearch

核心 API

适用场景与优势

生态与集成

价格与配额

Brave Search

核心 API

适用场景与优势

生态与集成

价格与配额

其他厂家

选型建议

综合对比与分析

响应速度

成本

功能

易用性

适用场景

选型建议

LangChain：是银弹，还是 “技术债”？

引言

高代码与低代码

高代码

3 毛钱干大事？用了几天豆包编程模型，我来扒一扒字节这波操作