7个AI工程必备Python库
本文介绍了7个Python库，它们取代了作者所有AI工程中的样板代码。每个库都遵循相同的模式：一个需要手动解决的问题，一个用几行代码解决它的库，以及README中没有提到的诚实限制。
1、LiteLLM：一个适用于每个LLM提供商的接口
问题：你想测试 GPT-4 vs Claude vs Llama。所以你编写了三个独立的客户端配置、三个响应解析器和三个错误处理器。
LiteLLM 为所有LLM提供商提供统一接口。只需更改模型名称字符串即可在不同提供商之间切换。
作者在上季度进行了成本比较：在 GPT-4、Claude Sonnet 和 Llama 3 70B 上运行相同的工作负载。差异是每月847美元。没有 LiteLLM，测试那需要一个星期的重构。
替换：3个独立的SDK集成和一个成本跟踪电子表格。
诚实限制：当提供商更改其API时，你需要等待LiteLLM更新。对于关键任务的生产环境，一些团队仍然更喜欢直接使用SDK。
2、Instructor：实际工作的结构化输出
问题：你要求LLM提供JSON。你得到的是用markdown反引号包裹的JSON。或者带有额外字段的JSON。或者一个看起来像JSON但带有尾随逗号的字符串。
Instructor 通过Pydantic模型确保结构化输出，无需手动解析或处理边界情况。
在 Instructor 之前，作者有一个包含12个边界情况的parse_llm_json()函数。它仍然在生产数据上每周失败一次。上面的嵌套提取（复杂对象的验证列表）是 Instructor 真正领先的地方。尝试使用 regex 和 json.loads() 做到这一点。
替换：带有手动验证的150行JSON解析函数。
诚实限制：增加延迟。当模型的第一次尝试不通过验证时，Instructor 有时需要重试循环。对于高吞吐量管道，需要测量开销。
3、MarkItDown：将任何文档转换为LLM就绪文本
问题：你的RAG管道需要摄取PDF、Word文档、PowerPoint和Excel文件。所以你安装了用于PDF的pdfminer、用于Word的python-docx、用于幻灯片的python-pptx和用于电子表格的pandas。四个库。四个解析管道。四组边界情况。
MarkItDown 是微软构建的（86K GitHub星标），可以将任何文档转换为干净的Markdown。它保留了标题、表格和列表作为Markdown。
当作者为内部知识库构建文档问答系统时，摄取管道占代码库的40%。MarkItDown 会将其减少到几行。
替换：使用4个独立解析库的自定义提取管道。
诚实限制：PDF提取仅限文本层。没有OCR的扫描图像不返回任何内容。PDF中的表格提取也不一致，因此需要验证任何财务或大量表格的内容。
4、FastMCP：在几分钟内构建MCP服务器
问题：模型上下文协议 (MCP) 正成为给LLM提供访问外部工具和数据的标准。但从头开始构建合规的MCP服务器意味着数百行的传输处理、模式定义和协议样板代码。作者写过关于MCP的安全模型需要审查的文章，但即使抛开安全问题不谈，实现负担也是真实的。
FastMCP 使用装饰器模式让你在几行代码中构建完整的MCP服务器。原型化一个内部搜索索引的工具服务器大约需要20分钟。作者开始编写的原始MCP版本有200行，仍然没有处理传输。
替换：200多行协议样板代码。
诚实限制：FastMCP 仍然很年轻（22K星标且在增长）。如果你的堆栈不支持MCP，这没有帮助。你仍然需要仔细考虑你暴露的内容。
5、PydanticAI：没有框架税的类型安全代理
问题：你想要与LLM进行结构化、类型安全的交互。但完整的代理框架带来了依赖膨胀、不透明的抽象，以及当你需要在框架内部三层深处调试某些东西时的下沉感。
PydanticAI 位于原始API调用和重型框架之间的最佳位置。类型化输入、类型化输出、工具定义、依赖注入。由Pydantic团队构建（其验证库为OpenAI SDK、LangChain以及基本上所有其他软件提供支持）。
作者开始将其用于任何对于单个Instructor调用来说太复杂但不需要完整LangGraph工作流的结构化任务。
替换：无类型提示链和手动响应验证。
诚实限制：PydanticAI中的"代理"更像是"结构化LLM交互"而不是"自主多步推理"。对于具有持久状态的复杂多代理工作流，LangGraph或CrewAI仍然占据该领域。
6、tiktoken：在发送之前了解你的成本
问题：你通过连接上下文来构建提示词，而你不知道是否即将超出上下文窗口，或者当0.02美元的调用可以工作时发送一个2美元的API调用。
tiktoken 是OpenAI的分词器。在构建包含动态上下文的LLM调用之前，作者添加了令牌检查。
作者在递归上下文构建函数创建了45,000令牌的提示词后开始使用tiktoken。API调用成本1.35美元。对于单个请求。每小时查询200次。
替换：盲目API调用和惊喜发票。
诚实限制：tiktoken是OpenAI特定的。对于Anthropic，你需要他们的令牌计数API。LiteLLM的token_counter()包装了多个分词器，但准确性有所不同。硬编码费率（如上所述）是一个最终会对你说谎的捷径。
7、Pydantic Evals：停止对提示词进行"氛围测试"
问题：你更改了系统提示词。它变好了吗？你手动运行三个示例，它们看起来没问题，你发布了它。两天后，用户抱怨你没有测试的回归问题。
Pydantic Evals 是作者发现的最简单的评估框架。定义案例，运行它们，获取通过/失败报告。足够简单，你实际上会使用它（这是整个重点）。
作者几个月来一直抗拒评估框架。"我的提示词工作正常，我手动测试它们。"然后作者更改了一个系统提示词以改进一个边界情况，它默默地破坏了作者没有检查的其他三个情况。
替换："看起来不错"的测试和部署后惊喜。
诚实限制：它是新的，API仍在发展中。对于大规模的生产评估管道，Braintrust或Langfuse提供更深入的集成。但对于"此更改后我的提示词是否仍然有效？"来说，它完全正确。
8、结束语
一年前，作者会告诉你最好的栈是你自己构建的栈。完全控制。没有依赖。
作者错了。作者在维护API包装器上花费的时间比构建实际产品还多。这7个库共享一个理念：做一件事，做好它，不要碍事。它们都不需要购买框架。它们都删除你不应该编写的代码。
最好的AI工程堆栈不是最复杂的。它是能够交付的。这就是整个教训。
原文链接：7个AI工程必备Python库 - 汇智网