大模型应用项目越来越常出现在简历里，但面试官也越来越警惕“只是套了一个接口”。如果你只说用了某个模型、接了向量库、做了一个聊天窗口，很容易被追问到卡住：数据怎么来？检索不准怎么办？工具调用失败怎么办？怎么评估效果？
要把大模型项目讲得可信，关键是从“模型能力”讲到“系统工程”。模型只是其中一层，真正决定项目质量的，是数据、上下文、工具、评估、成本和稳定性。
先讲清项目为什么需要大模型
不是所有项目都需要大模型。面试里可以先说明：这个场景是否存在自然语言理解、复杂生成、资料归纳、多轮交互或开放问题。如果只是固定规则判断，用普通后端逻辑可能更稳定、更便宜。
比如知识库问答选择大模型，是因为用户问题表达多样，答案需要结合多段资料组织；简历诊断选择大模型，是因为需要把经历改写成更清晰的表达。但即使如此，也要说明哪些部分不用模型做，哪些部分仍由规则、权限和业务系统控制。
RAG 项目要讲资料处理
RAG 不是“文档向量化”一句话。资料进入系统前，要处理标题、段落、表格、代码块和层级关系；切分太小会丢上下文，切分太大召回噪声多；检索后还要考虑重排、去重、权限过滤和证据引用。
如果召回不准，不能直接怪模型。可能是切分策略不合适，向量模型不适配领域词，关键词召回缺失，或者问题本身需要先改写。能把这些定位路径讲出来，面试官会更容易相信你做过真实 RAG。
Agent 项目要讲工具和失败路径
Agent 的亮点不在“模型会调用函数”，而在工具执行是否可控。工具参数要校验，权限要由业务系统判断，高风险动作要确认，失败要能重试、降级或回滚。否则 Agent 只是一个演示流程。
工具调用失败时，要能区分模型选错工具、参数不完整、工具超时、业务状态不允许、权限不足等不同原因。不同原因对应不同处理：有的需要追问用户，有的需要重试，有的必须拒绝执行。
评估不能只说看起来更准
大模型项目必须有评估。RAG 可以看证据召回、答案可用率、拒答边界和坏例回归；Agent 可以看任务完成率、工具调用成功率、人工接管率和高风险拦截；内容生成可以看人工评分、修改率和用户采纳率。
如果项目规模不大，也可以维护一批典型问题和坏例集。每次改提示词、模型、切分策略或工具逻辑，都跑一遍回归，确认没有把旧问题重新引入。
还要讲成本和稳定性
模型调用有延迟和成本，输出也可能不稳定。上线系统要考虑超时、重试上限、缓存、降级、限额和日志。用户等待太久，或者一次任务调用十几次模型，即使答案质量不错，也很难长期运营。
一个更成熟的项目表达是：我负责的不只是接模型接口，而是把资料处理、上下文组织、工具权限、失败兜底、效果评估和成本监控串起来。这样回答，大模型项目才会像一个生产系统，而不是一次 API 演示。