框架与生态地图
面试中被问到"你们用什么技术栈"时，你需要能聊清楚为什么选这个而不是那个。
一、模型供应商
国际主流
| 供应商 | 代表模型 | 优势 | 适用场景 |
|---|---|---|---|
| OpenAI | GPT-4o / o3 | 生态最强，工具调用成熟 | 通用首选，代码生成 |
| Anthropic | Claude 3.5 / 4.x | 长上下文，指令遵循好，安全性强 | 长文档处理，企业合规 |
| Gemini 2.0 | 原生多模态，1M Context | 视频/图像理解，Google 生态 | |
| Meta | Llama 3 / 4 | 开源免费，可私有化部署 | 成本敏感，数据合规 |
| Mistral | Mistral Large | 欧洲，合规友好 | GDPR 场景 |
国内主流
| 供应商 | 代表模型 | 优势 | 适用场景 |
|---|---|---|---|
| 深度求索 | DeepSeek-V3 / R1 | 性价比极高，推理能力强 | 成本敏感场景首选 |
| 阿里 | Qwen2.5 / 3 | 中文理解强，多模态成熟 | 中文业务，阿里云生态 |
| 百度 | ERNIE 4.5 | 知识图谱强，百度生态 | 搜索/知识类产品 |
| 字节 | Doubao | 字节生态，多模态 | 抖音/飞书生态产品 |
| 腾讯 | Hunyuan | 腾讯生态，长文本 | 微信生态，企业微信 |
| 智谱 | GLM-4 | 国产先驱，工具调用 | 企业知识库 |
第三方推理平台（API 转发）
不想直接对接多家模型时，通过聚合平台统一调用：
| 平台 | 特点 |
|---|---|
| SiliconFlow（硅基流动） | 国内，价格低，兼容 OpenAI 格式 |
| Together AI | 国际，开源模型集中 |
| Groq | 极低延迟（自研 LPU 芯片） |
| OpenRouter | 模型最全，统一 API |
二、Agent 开发框架
代码框架（需要工程师）
| 框架 | 定位 | 优势 | 劣势 | PM 认知要点 |
|---|---|---|---|---|
| LangChain | 通用 Agent 框架 | 生态最大，社区活跃 | 抽象层重，调试难 | 业界标准，但复杂度高 |
| LlamaIndex | RAG 专精 | 数据连接器丰富 | 非 Agent 场景较弱 | 知识库场景首选 |
| AutoGen（微软） | 多 Agent 对话 | 灵活，适合复杂 Multi-Agent | 上手曲线陡 | 微软生态 |
| CrewAI | 角色化多 Agent | 角色/任务定义清晰 | 相对年轻 | 流程自动化场景 |
| LangGraph | 有状态 Agent 流程 | 可视化流程控制 | 需要 LangChain 基础 | 复杂工作流 |
低代码平台（PM 可直接上手）
| 平台 | 定位 | 优势 | 适用场景 |
|---|---|---|---|
| Dify | 开源 LLM 应用平台 | 可自部署，功能最全 | 企业内部，数据合规 |
| Coze（扣子） | 字节系 Bot 平台 | 生态插件多，上手快 | 快速验证，消费端 |
| FastGPT | 知识库问答平台 | RAG 专精，中文友好 | 企业知识库 |
| Flowise | 开源可视化流程 | 免费，LangChain 可视化 | 技术团队快速原型 |
| n8n | 自动化工作流 | 非 AI 工具集成强 | 企业流程自动化 |
PM 建议：用 Dify 或 Coze 搭一个最小 Demo 验证想法，成本极低，无需工程师。
三、向量数据库（RAG 必用）
| 数据库 | 类型 | 优势 | 适用场景 |
|---|---|---|---|
| Pinecone | 托管云服务 | 零运维，开箱即用 | 快速上线，中小规模 |
| Weaviate | 开源/托管 | 多模态支持好 | 图文混合检索 |
| Milvus | 开源 | 高性能，大规模 | 亿级向量，企业级 |
| Chroma | 开源轻量 | 本地运行简单 | 开发测试，小规模 |
| pgvector | PostgreSQL 插件 | 复用现有 PG | 已有 PG 基础设施 |
四、AI 应用基础设施
Prompt 管理
| 工具 | 作用 |
|---|---|
| LangSmith | LangChain 官方，Prompt 版本管理 + 追踪 |
| PromptLayer | 通用，Prompt 版本化 + 分析 |
| Helicone | 轻量 API 代理，日志 + 成本分析 |
评估与测试
| 工具 | 作用 |
|---|---|
| RAGAS | RAG 系统专项评估框架 |
| DeepEval | 通用 LLM 评估，支持多指标 |
| Braintrust | 云端评估平台，CI/CD 集成 |
监控与可观测性
| 工具 | 作用 |
|---|---|
| LangFuse | 开源，完整 LLM 应用追踪 |
| Arize Phoenix | 可视化 LLM 调试 |
| Weights & Biases | ML 实验追踪，支持 LLM |
五、选型决策树
面试被问"你们为什么选这个框架"时，这里是你的思路来源。
模型选型
你的场景在国内部署？
├── 是 → 数据合规要求高（金融/政府/医疗）？
│ ├── 是 → 私有化部署：Qwen / GLM-4 / DeepSeek（开源可本地跑）
│ └── 否 → 性价比优先：DeepSeek API > 通义千问 API > 豆包 API
└── 否 → 需要最强推理能力？
├── 是 → Claude Opus / GPT-4o / o3（成本高）
└── 否 → 通用任务：Claude Sonnet / GPT-4o-mini（性价比佳）补充判断维度：
- 长文档（>100K tokens）→ Claude（200K）或 Gemini（1M）
- 代码生成专项 → Claude Sonnet / GPT-4o / DeepSeek-V3
- 中文理解优先 → Qwen 系列 / DeepSeek
Agent 框架选型
团队有工程师资源吗？
├── 否 → 用低代码平台：
│ ├── 快速验证/消费端 → Coze（扣子）
│ ├── 企业数据合规/私有化 → Dify
│ └── 企业知识库专项 → FastGPT
└── 是 → 场景是什么？
├── RAG / 知识库问答 → LlamaIndex（数据连接器最丰富）
├── 单 Agent + 工具调用 → LangChain（生态最大，文档最全）
├── 复杂多步工作流（有状态） → LangGraph（可视化流程控制）
└── 多 Agent 协作 → AutoGen（微软，对话式）或 CrewAI（角色化任务）常见误区：
- 不要因为 LangChain 最出名就默认用它——它的抽象层很重，简单场景反而增加调试难度
- CrewAI 适合"角色分工明确"的场景（如：研究员→写作员→审校员），不适合高度动态的任务
向量数据库选型
数据规模多大？
├── 开发/测试阶段 → Chroma（本地，零配置）
├── 中小规模上线（<千万向量） → Pinecone（托管，省运维）
├── 已有 PostgreSQL → pgvector（复用基础设施，无需新引入）
├── 亿级向量/高并发 → Milvus（高性能，需运维能力）
└── 需要多模态（图文混合检索） → WeaviateRAG vs Fine-tuning 决策
这是面试高频考点，务必能清晰说明选择理由：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 知识库频繁更新（每周/每天） | RAG | Fine-tuning 重训成本太高 |
| 知识库相对稳定，需要极低延迟 | Fine-tuning + 少量 RAG | 减少实时检索 |
| 需要固定输出格式/风格 | Fine-tuning | Prompt 控制不够稳定 |
| 领域知识超出模型训练数据 | RAG | 模型不知道的内容只能靠检索补充 |
| 通用能力不足（模型太弱） | Fine-tuning | 补强基础能力 |
面试标准答案框架：
"默认选 RAG，理由是灵活、可更新、透明。只有在三种情况下叠加 Fine-tuning：①需要固定输出格式 ②领域语言风格独特 ③通用模型基础能力不足。两者不是非此即彼，生产环境里 RAG + 轻量 Fine-tuning 组合很常见。"
六、面试中怎么聊技术栈
Q：你们产品用了什么 AI 框架？
好的回答结构：
"我们用 [框架]，选择它的原因是 [具体需求]。当时对比了 [备选方案]，放弃的原因是 [约束条件]。目前最大的挑战是 [痛点]，我们在考虑 [改进方向]。"
Q：RAG 还是 Fine-tuning？
"RAG 是我们的默认选择，原因是知识库更新频率高（每周更新），Fine-tuning 的维护成本太高。只有在需要固定输出格式/风格的场景，才考虑在 RAG 基础上叠加轻量 Fine-tuning。"