过去这一年，我主导了公司核心业务的 AI-Native（AI 原生）化重构。从最初觉得“不就是调个 API、挂个向量库”的轻敌，到上线后面对高昂的Token 账单和飘忽不定的召回率彻夜难眠，我交了不少“学费”。

今天不谈PPT上的宏大叙事，只聊聊在架构落地时，那些教科书上没写的、只有踩过坑才知道的硬核细节。

一、存储选型之痛：向量数据库不是万能药

刚开始，我们盲目追求“专业”，给系统配了顶级的分布式向量数据库。结果上线第一周，业务方就反馈：搜索结果风马牛不相及。

【硬核踩坑】 我们发现，向量检索（ANN）虽然能处理语义，但在处理“货号”、“品牌名”这种准确关键词时，表现极其拉胯。列如用户搜“iPhone 15”，语义检索可能会给你推一堆“华为适配器”的文档。

【务实手册】

• 不要孤注一掷： 目前的标配架构必须是Hybrid Search（混合搜索）。
• 选型对比：
• 如果你的数据量在百万级以下，PGVector 配合传统 SQL 检索是性价比之王，一致性极好。
• 只有到了亿级向量且需要极高性能，再思考Milvus 或 Zilliz，但要做好运维复杂度翻倍的心理准备。

存储选型之痛：向量数据库不是万能药

二、RAG 的“最后 1 公里”：精排（Rerank）才是灵魂

许多团队RAG效果不好，以为是 Embedding 模型的问题，疯狂换模型，结果收效甚微。

【硬核踩坑】 初版架构中，我们直接取向量检索的 Top-5 喂给 LLM。结果发现，向量空间里的“距离近”，不代表业务逻辑上的“相关”。

【务实手册】

• 引入Reranker模型： 在检索（Retrieval）和生成（Generation）之间，必须加一层精排（BGE-Reranker 等）。
• 代价：引入 Rerank 会增加首字延迟（TTFT）。我们的折中方案是：对简单问题跳过精排，对长尾复杂问题强制精排。这才是架构师该做的权衡（Trade-off）。

RAG 的“最后 1 公里”：精排（Rerank）才是灵魂

三、编排之乱：LangChain是 Demo的天堂，生产的坟墓

我承认LangChain极大地降低了上手门槛，但在生产环境，它太沉重、太黑盒了。

【硬核踩坑】 当我们需要精细控制Prompt的版本、观察 Agent 的中间决策状态时，发现 LangChain 复杂的链式封装让调试变成了噩梦。一次莫名其妙的超时，可能嵌套了十几层库函数。

【务实手册】

• 状态机思维：生产环境提议使用LangGraph或干脆自研轻量级编排层。
• 显式控制：将AI的决策链路拆解为“规划 -> 动作 -> 观察 -> 反思”的显式循环。架构师需要的是对逻辑的绝对掌控，而不是魔法。

编排之乱：LangChain是 Demo的天堂，生产的坟墓

四、成本治理：Token 也是一种“内存泄露”

如果不做成本治理，AI 架构就是个无底洞。

【硬核踩坑】 上线初期，我们发现大量类似的Prompt在重复消耗 Token，用户每次提问都要消耗几毛钱，日活一上来，账单触目惊心。

【务实手册】

• 语义缓存（Semantic Cache）：引入GPTCache等组件。如果新提问与历史问题语义类似度高于 0.95，直接返回缓存结果。
• Prompt瘦身：资深架构师要学会“剪枝”，没必要把几万字的文档全塞给 context，利用长文本模型不代表可以无节制浪费。

成本治理：Token 也是一种“内存泄露”

五、写在最后：架构师的护城河到底在哪？

在AI时代，写代码的门槛在降低，但治理复杂系统的门槛在提高。

AI只是一个极其强劲的“概率工具”，它的上限由算法决定，但它的下限——也就是系统的稳定性、可靠性和成本，完全由架构师决定。

不要担心被AI取代。只要你还在思考如何在高并发下降低延迟，如何用不确定的组件搭出确定的系统，你就是这个时代最不可或缺的人。