营销号-7个AI工程必备Python库

营销号-7个AI工程必备Python库

无所谓了，你大胆营销，我就大胆去学！Python实现代码地址：https://gitee.com/enzoism/python_7_ai_requirements

前言

本文介绍了7个Python库，它们取代了作者所有AI工程中的样板代码。每个库都遵循相同的模式：一个需要手动解决的问题，一个用几行代码解决它的库，以及README中没有提到的不足。

01-LiteLLM：一个适用于每个LLM提供商的接口

问题：你想测试 GPT-4 vs Claude vs Llama。所以你编写了三个独立的客户端配置、三个响应解析器和三个错误处理器。

LiteLLM 为所有LLM提供商提供统一接口。只需更改模型名称字符串即可在不同提供商之间切换。

作者在上季度进行了成本比较：在 GPT-4、Claude Sonnet 和 Llama 3 70B 上运行相同的工作负载。差异是每月847美元。没有 LiteLLM，测试那需要一个星期的重构。

惊喜：3个独立的SDK集成和一个成本跟踪电子表格。

不足：当提供商更改其API时，你需要等待LiteLLM更新。对于关键任务的生产环境，一些团队仍然更喜欢直接使用SDK。

02-Instructor：实际工作的结构化输出

问题：你要求LLM提供JSON。你得到的是用markdown反引号包裹的JSON。或者带有额外字段的JSON。或者一个看起来像JSON但带有尾随逗号的字符串。

Instructor 通过Pydantic模型确保结构化输出，无需手动解析或处理边界情况。

在 Instructor 之前，作者有一个包含12个边界情况的 parse_llm_json() 函数。它仍然在生产数据上每周失败一次。上面的嵌套提取（复杂对象的验证列表）是 Instructor 真正领先的地方。尝试使用 regex 和 json.loads() 做到这一点。

惊喜：带有手动验证的150行JSON解析函数。

不足：增加延迟。当模型的第一次尝试不通过验证时，Instructor 有时需要重试循环。对于高吞吐量管道，需要测量开销。

03-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中的表格提取也不一致，因此需要验证任何财务或大量表格的内容。

04-FastMCP：在几分钟内构建MCP服务器

问题：模型上下文协议 (MCP) 正成为给LLM提供访问外部工具和数据的标准。但从头开始构建合规的MCP服务器意味着数百行的传输处理、模式定义和协议样板代码。作者写过关于MCP的安全模型需要审查的文章，但即使抛开安全问题不谈，实现负担也是真实的。

FastMCP 使用装饰器模式让你在几行代码中构建完整的MCP服务器。原型化一个内部搜索索引的工具服务器大约需要20分钟。作者开始编写的原始MCP版本有200行，仍然没有处理传输。

惊喜：200多行协议样板代码。

不足：FastMCP 仍然很年轻（22K星标且在增长）。如果你的堆栈不支持MCP，这没有帮助。你仍然需要仔细考虑你暴露的内容。

05-PydanticAI：没有框架税的类型安全代理

问题：你想要与LLM进行结构化、类型安全的交互。但完整的代理框架带来了依赖膨胀、不透明的抽象，以及当你需要在框架内部三层深处调试某些东西时的下沉感。

PydanticAI 位于原始API调用和重型框架之间的最佳位置。类型化输入、类型化输出、工具定义、依赖注入。由Pydantic团队构建（其验证库为OpenAI SDK、LangChain以及基本上所有其他软件提供支持）。

作者开始将其用于任何对于单个Instructor调用来说太复杂但不需要完整LangGraph工作流的结构化任务。

惊喜：无类型提示链和手动响应验证。

不足：

06-tiktoken：在发送之前了解你的成本

问题：你通过连接上下文来构建提示词，而你不知道是否即将超出上下文窗口，或者当0.02美元的调用可以工作时发送一个2美元的API调用。

tiktoken 是OpenAI的分词器。在构建包含动态上下文的LLM调用之前，作者添加了令牌检查。

作者在递归上下文构建函数创建了45,000令牌的提示词后开始使用tiktoken。API调用成本1.35美元。对于单个请求。每小时查询200次。

惊喜：盲目API调用和惊喜发票。

不足：tiktoken是OpenAI特定的。对于Anthropic，你需要他们的令牌计数API。LiteLLM的 token_counter() 包装了多个分词器，但准确性有所不同。硬编码费率（如上所述）是一个最终会对你说谎的捷径。

07-Pydantic Evals：停止对提示词进行"氛围测试"

问题：你更改了系统提示词。它变好了吗？你手动运行三个示例，它们看起来没问题，你发布了它。两天后，用户抱怨你没有测试的回归问题。

Pydantic Evals 是作者发现的最简单的评估框架。定义案例，运行它们，获取通过/失败报告。足够简单，你实际上会使用它（这是整个重点）。

作者几个月来一直抗拒评估框架。"我的提示词工作正常，我手动测试它们。"然后作者更改了一个系统提示词以改进一个边界情况，它默默地破坏了作者没有检查的其他三个情况。

惊喜："看起来不错"的测试和部署后惊喜。

不足：它是新的，API仍在发展中。对于大规模的生产评估管道，Braintrust或Langfuse提供更深入的集成。但对于"此更改后我的提示词是否仍然有效？"来说，它完全正确。

结束语

一年前，作者会告诉你最好的栈是你自己构建的栈。完全控制。没有依赖。

作者错了。作者在维护API包装器上花费的时间比构建实际产品还多。这7个库共享一个理念：做一件事，做好它，不要碍事。它们都不需要购买框架。它们都删除你不应该编写的代码。

最好的AI工程堆栈不是最复杂的。它是能够交付的。这就是整个教训。