当PydanticAI撞上RAG，我的一些探索和踩坑记录

从测试转开发三年了，坐标北京西二旗。最近半年组里技术讨论的风向明显变了——以前聊微服务拆分、消息队列调优，现在动不动就是Agent、多模态、RAG。Sora那波刷屏让不少人对“AI能干什么”的想象力彻底被打开。不过作为一个偏后端方向的开发，我对Sora更多是看热闹，真正让我上心的是PydanticAI这个框架，以及它跟RAG结合时那些工程化层面的坑。这篇文章就当是最近三个月技术探索的阶段性总结。

为什么是PydanticAI

组里去年年底接了一个内部知识库问答项目：把公司内部的文档、Wiki、历史工单灌进去，让员工能用自然语言提问。技术选型时我第一反应是LangChain，但那套抽象层叠得有点晕，文档更新速度跟不上版本迭代，调试起来经常要翻源码。

后来在GitHub上刷到PydanticAI，第一眼就被它的类型安全设计吸引住了。我是从测试转过来的，对“结构不清晰”这件事有天然的抗拒。PydanticAI把Agent的输出用Pydantic模型约束起来，这意味着我可以拿到一个强类型的Response对象，而不是一个需要不断parse的字典。尤其当需要把Agent的输出接到下游API、数据库或前端页面时，类型安全能省掉一大把防御性代码。

举个例子，我们的知识库问答需要返回引用来源。用PydanticAI，直接定义：

from pydantic import BaseModel
from pydantic_ai import Agent

class AnswerWithSources(BaseModel):
    answer: str
    sources: list[str]
    confidence: float

agent = Agent(
    "openai:gpt-4o-mini",
    result_type=AnswerWithSources,
    system_prompt="你是内部知识库助手，回答必须附带来源引用。"
)

跑起来之后，result.data直接就是一个AnswerWithSources实例，IDE里有完整的字段提示。那种感觉就像从JavaScript裸写突然换到TypeScript，世界都安静了。

RAG的“最后一公里”问题

RAG本身的概念不复杂：检索相关文档片段，塞进Prompt，让模型基于上下文回答。但真正落地时，80%的精力都耗在“检索质量”和“上下文组织”上。

第一版用的是最简单的方案：固定长度切片，OpenAI embedding，pgvector做向量库。上线一周，用户反馈集中在两类：一是“答非所问”，二是“引用来源对不上”。前者是检索精度问题，后者是切片策略导致元数据丢失。

印象最深的一个Bug：用户问“去年Q3的服务器扩容方案是谁审批的”，系统检索到的片段里确实提到了扩容方案，但切片把审批人那一行切到了另一个chunk里，结果模型开始一本正经地编造。后来我们做了几件事：

第一，切片策略从固定长度改成结构化切片。 文档本身有标题层级、表格、列表，这些结构信息在固定长度切分时全丢了。我们写了一个预处理脚本，基于Markdown的标题层级做递归切分，表格单独处理，每个chunk带上完整的“文档标题-章节标题-段落位置”元数据。

第二，检索策略从纯向量检索改成混合检索。 向量检索对语义相近但关键词不匹配的情况友好，但精确匹配场景（比如搜工单号、版本号）就抓瞎了。加了BM25关键词检索，两路结果做加权融合，精确查询类准确率提升很明显。

第三，Prompt里加了严格的引用约束。 要求模型只能基于提供的上下文回答，如果上下文中没有足够信息，必须明确说“未找到相关信息”，而不是发挥想象力。这个约束配合PydanticAI的结构化输出，效果意外地好。

Sora的启发：从文本到多模态RAG

虽然Sora是个视频生成模型，但它背后的技术思路对RAG有启发。Sora把视频数据编码成时空patch，然后用扩散模型生成。这种“把非结构化数据转成统一表示”的思路，跟RAG里把文档转成向量是一脉相承的。

内部知识库里有大量截图、架构图、流程图，这些视觉信息在纯文本RAG里完全被忽视了。用户问“这个服务的架构图里，订单模块和支付模块是怎么交互的”，文本RAG根本答不上来。

目前我们在调研多模态RAG方案，思路是把图片也做embedding，跟文本向量放在同一个向量空间里做检索。技术上不算新，但工程挑战不小：图片embedding模型选型、图文混合检索的权重怎么调、多模态上下文的Token成本。这个方向还在PoC阶段，等有实质进展了再单独写一篇。

踩坑记录

坑一：PydanticAI版本更新太勤，API变动没商量。 刚开始用的时候还是0.x版本，中间升了一次小版本，Agent的初始化参数直接改了，CI挂了半天才定位到。现在requirements.txt里锁死版本，升级前先看Changelog。

坑二：embedding模型选型翻车。 一开始为了省钱用了某个开源中文embedding模型，结果对英文技术文档的检索效果很差。内部文档是中英混杂的，最后只能换回OpenAI的text-embedding-3-large，成本涨了不少但准确率上来了。教训是：embedding模型的选择不能只看Benchmark，得用自己的数据做评估集。

坑三：RAG的评估体系缺失。 刚上线时判断“效果好不好”全靠人工看。后来被测试同学逼着建了一个评估集，大概200条问答对，覆盖不同类型的问题。每次改检索策略或换模型，先跑一遍评估集看指标。这个习惯应该一开始就做。

一些不成熟的想法

RAG这个方向，接下来的竞争点不在“能不能跑通”，而在“工程化程度”。PydanticAI这类框架最大的价值，是把Agent开发从“写Prompt的玄学”往“写代码的工程学”上拉。类型安全、结构化输出、可测试性——这些传统软件工程里的东西，在AI应用开发里同样重要。

另外，Sora代表的生成式模型也在倒逼RAG进化。当内容生成从文本扩展到图像、视频、音频，RAG需要处理的就不只是文档了。未来的知识库，可能是一个多模态的统一检索空间。技术栈还在快速变动，但方向是确定的。

最后说句题外话。作为一个从测试转过来的人，我特别能理解那种“技术焦虑”。AI这一波来得太快，每天都有新框架、新模型、新概念。我的策略是：不追热点，只追跟自己业务相关的东西。Sora很酷，但如果业务用不上，看个热闹就行。PydanticAI和RAG能解决手头的问题，那就花时间深挖。技术探索说到底是为了解决问题，不是为了显得很潮。