转型 AI 后的第一个生产系统：选型比写代码更关键

转型 AI 后的第一个生产系统：选型比写代码更关键

一、三个月做的系统，上线两周就重构了

转型 AI 工程化后的第一件事往往是激情澎湃地写代码。
选 LangChain，因为它 GitHub Star 最多。
选 Pinecone，因为向量数据库的广告最多。
选 GPT-4，因为它是"最强模型"。

三个月后系统上线。
LangChain 的抽象层让你没法调试。
Pinecone 的账单是第一月预算的三倍。
GPT-4 的响应延迟让用户抱怨"卡"。
重构花了两周，换成了更薄的 LlamaIndex + Qdrant + GPT-4o-mini。

第一套系统的坑不在代码，而在选型。
选型错误比代码写错代价大得多。
代码可以重构，基础设施迁移成本翻倍。

二、第一个生产系统的选型决策框架

AI 系统的三个核心组件：编排框架、向量数据库、大模型。
每个组件的选择依赖你的具体场景。

flowchart TB A[需求分析] --> B{QPS 和延迟要求} B -->|高并发、低延迟| C[轻量框架 + 自托管] B -->|低频、灵活| D[全托管服务] A --> E{数据量级} E -->|< 10 万文档| F[pgvector / SQLite-vec] E -->|10 万 - 100 万| G[Qdrant / Milvus] E -->|> 100 万| H[Elasticsearch + 向量插件] A --> I{成本预算} I -->|月预算 < $500| J[开源模型 + API] I -->|月预算 $500-$2000| K[GPT-4o-mini / Claude Haiku] I -->|月预算 > $2000| L[多模型混合路由]

三、各组件的选型对比

编排框架：LangChain vs LlamaIndex vs 手写

如果团队有强工程能力，手写编排代码只多花一周。
但未来三个月的维护成本降低 50% 以上。

向量数据库

高频场景（> 100 QPS）选 Milvus 或 Qdrant。
低频场景直接用 pgvector，运维成本为零。
千万级文档以上，考虑 Elasticsearch 的向量能力。

大模型选择

内部应用（客服、知识库）用 GPT-4o-mini 或 Claude Haiku。
准确率 90% 和 95% 的差异用户不一定感知。
但账单差异可能是 5-10 倍。
对外产品（付费功能）可用更强模型。

一个务实的混合路由策略。

def route_model(query: str, task_type: str) -> str: """根据任务类型和复杂度选择模型""" # 简单任务：GPT-4o-mini（快、便宜） simple_tasks = ["classification", "extraction", "formatting"] if task_type in simple_tasks: return "gpt-4o-mini" # 查询字数 < 10 通常简单 if len(query) < 10: return "gpt-4o-mini" # 复杂推理：GPT-4o complex_tasks = ["reasoning", "code_generation", "analysis"] if task_type in complex_tasks: return "gpt-4o" return "gpt-4o-mini"

四、第一个系统常见错误

错误一：过度依赖框架。
框架帮你写的代码越多，将来改动的难度越大。
在 LangChain 里改一个 callback 需要理解 5 层继承。
对着 API 文档手写反而更快。

错误二：过早优化架构。
第一个系统的目的是验证它能工作。
别上来就设计多 Agent 协作、动态路由。
一个 Prompt + 一个工具调用的模式就够了。

错误三：忽视评估体系。
没有评估，你无法知道改了 Prompt 是变好还是变坏。
花一天时间建 50 条测试用例和评估脚本。
这笔投资在未来每次改动中都会收回。

五、总结

转型 AI 后的第一个生产系统，选型比实现更关键。
编排框架优先选择轻量方案或手写。
向量数据库从 pgvector 起步，按需升级。
大模型使用混合路由策略，平衡质量和成本。
前三个月聚焦验证可行性和建立评估体系。