AI 项目实战案例
面试中「讲一个你做过的大模型项目」往往是重头戏。本文给出几个高频参考项目的架构、技术栈、核心难点与「面试怎么讲」，帮你把项目讲清、讲出深度。
面试如何讲项目？
比起堆功能，面试官更想听你做了什么决策、遇到什么难点、怎么权衡解决。建议结构：
- 背景与目标：解决什么问题、给谁用、核心指标是什么。
- 整体架构：一句话讲清数据流，能画出架构图最好。
- 关键技术决策：为什么选 A 不选 B（如为什么用 RAG 而非微调、为什么选某向量库）。
- 核心难点与解法：这是加分区——讲清你踩的坑和优化（如召回不准怎么调、成本怎么降）。
- 效果与反思：量化结果（准确率/延迟/成本），以及还能怎么改进。
切忌只说「我用 LangChain 调了个 API」。要体现工程权衡和效果意识。
项目一：企业知识库问答系统（RAG）
最主流、最容易讲出深度的项目。
场景：让员工用自然语言查询公司内部文档（制度、产品手册、技术文档），带引用溯源。
架构：
文档(PDF/Word/网页)
│ 解析 → 切分 → Embedding
▼
[向量库] ◀── 混合检索(向量+BM25) ◀── 用户提问 → 查询改写
│ │
└──▶ Top-K 召回 → Rerank 精排 → 拼Prompt(带引用) → LLM → 带出处的回答技术栈：FastAPI / Spring AI · 向量库（Milvus / pgvector）· Embedding（BGE）· Rerank（cross-encoder）· LangChain / LlamaIndex · RAGAS 评估。
核心难点与解法：
- 召回不准 → 查询改写 / 混合检索 / 父子分块 / Rerank（详见 RAG 进阶）。
- 切分破坏语义 → 按标题层级 + 重叠切分，父子分块兼顾精度与完整性。
- 答非所问 / 幻觉 → Prompt 约束「只依据材料作答、不确定就说没有」+ 引用溯源。
- 效果难量化 → 用 RAGAS 评估忠实度、答案/上下文相关性，建立评测集持续迭代。
- 文档更新 → 增量 upsert，按文档 ID 管理向量。
面试可深挖：Embedding 与向量库选型、HNSW 原理、混合检索为何用 RRF 融合、如何做权限隔离与多租户。
项目二：AI 代码助手
场景：基于代码库的问答、解释、Bug 定位、单测/文档生成，可做成 IDE 插件。
架构：对代码库做索引（按函数/类切分 + Embedding），用户提问时检索相关代码片段喂给 LLM；可进一步做成 Agent，自主读文件、跑测试、改代码。
技术栈：代码解析（Tree-sitter / AST）· 代码 Embedding · 向量库 · LLM（代码模型）· Function Calling / Agent。
核心难点与解法：
- 代码切分 → 按语法结构（函数/类）切，而非固定长度，保持语义完整。
- 跨文件理解 → 建立调用关系/依赖图辅助检索（GraphRAG 思路）。
- 生成代码可靠性 → 生成后自动跑测试验证、失败反思重试（Reflexion）。
- 大仓库成本 → 增量索引、缓存、按相关性裁剪上下文。
面试可深挖：代码 RAG 与普通文本 RAG 的差异、Agent 如何安全执行代码（沙箱）、如何控制大上下文成本。
项目三：智能数据分析（Text-to-SQL）
场景：业务人员用自然语言查数据，系统自动转 SQL、执行并可视化。
架构：
用户问题 → 召回相关表结构/字段说明/示例SQL → LLM 生成SQL
→ 校验/纠错(执行报错则反馈重试) → 执行 → 结果 + 图表 + 自然语言解读技术栈：LLM · Schema 检索（把表结构作为知识库）· SQL 校验执行 · LangGraph（带纠错循环）。
核心难点与解法：
- 表多、Schema 长 → 先检索最相关的表/字段再喂给模型，而非全量塞入。
- SQL 出错 → 执行报错 → 把错误信息回喂模型自我修正（Agent 纠错循环）。
- 歧义/口径不一 → 提供字段说明、业务术语映射、示例 SQL（few-shot）。
- 安全 → 只读账号、SQL 注入与越权防护、限制可访问的表。
面试可深挖：为什么用「检索 Schema」而非把全库结构塞进 prompt、纠错循环如何设计、如何评估 SQL 正确率。
项目四：多 Agent 自动化（进阶）
场景：自动化完成跨步骤的复杂任务，如「市场调研报告」「内容创作流水线」。
架构：用 Supervisor 或 Pipeline 编排多个分工 Agent（如 检索员 → 分析师 → 撰写 → 审校），详见 多 Agent 与进阶范式。
核心难点与解法：误差累积（加校验/人工确认）、成本与延迟（小模型做简单子任务）、死循环（限步数/超时）、协调一致性（共享状态 + 明确接口）。
面试可深挖：为什么拆多 Agent 而非单 Agent、用 LangGraph 编排的好处、如何保证可靠性。
通用工程亮点（任何项目都能讲）
无论哪个项目，这些工程化细节都能体现深度（详见 LLM 应用开发实战）：
- 流式输出 改善体感、结构化输出 便于程序消费。
- 成本控制：模型分级路由、语义缓存、Prompt 精简、限制输出长度。
- 可观测性：链路追踪（LangSmith）、token/延迟/错误监控。
- 高并发：异步、限流排队、vLLM 高吞吐部署、多副本。
- 安全：Prompt 注入防护、内容审核、最小权限（详见 大模型安全）。
- 评估闭环：建评测集、量化指标、持续迭代——体现「效果意识」。
高频追问
Q：项目里为什么用 RAG 而不是微调？ 知识频繁更新、需要溯源、是私有事实型知识 → RAG（更新只需改知识库、可给出处、不易幻觉）；微调更适合改风格/格式/固定能力。两者可结合：微调改表达、RAG 供知识。
Q：你的 RAG 召回不准是怎么定位和优化的？ 先分清是检索问题还是生成问题：用评测集看检索命中率和生成忠实度。检索差 → 查询改写/混合检索/换 Embedding/Rerank；生成差 → 优化 Prompt、调整上下文位置、补充检索。
Q：怎么评估你的项目效果？ 别只说「感觉不错」。RAG 用 RAGAS（忠实度/相关性）、Text2SQL 用执行正确率、代码助手用测试通过率；同时关注延迟、成本、用户满意度，建立评测集做 A/B 和持续迭代。
Q：上线后怎么控制成本？ 模型分级路由（简单走小模型）、缓存（含语义缓存）、Prompt 与上下文精简、前缀缓存、限制输出长度、离线任务用 Batch API。