大模型应用项目怎么讲，才能避免“只是套壳”

大模型应用项目这两年出现在很多简历里。问题是，面试官对这类项目越来越警惕：如果你只是接了一个模型接口、写了几个提示词、做了一个聊天页面，很容易被认为是“套壳”。

真实面试里的追问会很细：数据怎么构造？检索增强生成（RAG，也就是先检索资料再让模型回答）为什么召回不准？怎么评估回答质量？上下文太长怎么办？智能体（Agent，也就是能调用工具完成任务的模型应用）调工具失败怎么处理？模型幻觉怎么兜底？成本和延迟怎么控制？这些问题不是为了难为人，而是为了判断你有没有把大模型当成一个工程系统来做。

先别急着介绍模型名

很多候选人一开口就是 GPT、Qwen、Llama、LangChain、向量数据库。模型名可以说，但不能作为项目价值的核心。

更好的开场是先讲业务问题：原来用户在什么流程里遇到效率问题，为什么传统规则或搜索不够，为什么需要生成式能力。比如知识库问答项目，可以说目标是降低人工查文档成本，难点不是“接入大模型”，而是用户问题表达不规范、文档碎片化、召回噪声多、回答需要可追溯。

这会让面试官感觉你理解的是业务闭环，而不是技术堆叠。

检索增强生成项目必须讲召回和评测

检索增强生成面试最常见的低分回答是：文档切块、向量化、召回、交给大模型回答。这个流程太粗，面试官一定会追问细节。

高分回答要讲四个点：

• 文档怎么处理：标题、段落、表格、代码块是否分开处理，chunk 大小怎么定，是否保留层级信息。
• 召回怎么做：向量召回、关键词召回、混合召回、重新排序（rerank）各自解决什么问题。
• 噪声怎么控制：召回内容不相关时怎么办，多个片段冲突时怎么办，是否要求模型引用依据。
• 怎么评估：不能只说“感觉回答更准”，要有命中率、人工标注、答案可用率、拒答准确率、用户反馈或失败样本分析。

智能体项目要讲失败路径

智能体（Agent）很容易被问到工具调用。面试官通常不只问你用了什么框架，而是问：什么时候该调用工具？工具参数错了怎么办？调用失败怎么重试？模型循环调用怎么办？外部系统返回异常怎么办？

一个像样的智能体项目回答，需要包含任务拆解、工具权限、参数校验、调用日志、失败重试、终止条件和人工兜底。否则听起来就像一个演示项目。

例如可以说：我们不会让模型随意调用所有工具，而是按业务场景配置可用工具；调用前对参数格式做校验；调用结果会写入链路日志；连续失败后返回可解释的失败原因，不让模型继续编造结果。

幻觉控制要具体

“减少幻觉”是大模型面试高频追问。低分回答通常是“优化提示词”。提示词有用，但不是完整方案。

更稳的回答可以分三层：输入侧限制，让模型只基于检索材料回答；生成侧约束，要求引用证据、结构化输出、无法确认时拒答；输出侧校验，对关键字段、事实、链接、数值做规则或二次模型检查。

如果业务对准确率要求高，还要说明哪些问题不能直接自动回答，必须转人工或返回“资料不足”。这不是保守，而是工程上必要的边界。

成本和延迟不能忽略

很多候选人在大模型项目里只讲效果，不讲成本。真实业务里，模型调用费用、响应时间、并发限制都很关键。

可以从几个方向讲优化：缓存高频问题、短问题走小模型或规则、长文档先检索再压缩、异步生成非实时内容、对不同用户或场景使用不同模型、限制上下文长度、监控模型文本单位（token）消耗。

面试官听到这些，会更相信你考虑过上线，而不是只做了课堂项目。

一个更可信的项目表达

这个项目不是单纯做聊天，而是解决客服或内部知识查询效率问题。难点在于用户问题表达不稳定，文档结构不统一，模型容易在资料不足时编造答案。我负责的是检索链路和回答质量控制：先对文档做结构化切分，保留标题层级；召回阶段用向量和关键词混合召回，再做重新排序；生成阶段要求模型只基于材料回答，并输出依据；如果召回分数低或材料冲突，就拒答或转人工。

评估上，我们抽样构建问题集，看召回命中、答案可用率、拒答准确率和人工反馈。上线后监控延迟、模型调用成本、失败率和用户追问率。

这类表达能体现你做的是系统，不是包装一个模型接口。

面试前检查

• 这个项目不用大模型能不能做，为什么最后选择大模型？
• 数据怎么来，怎么清洗，怎么评估？
• 检索增强生成召回不准时怎么定位？
• 智能体工具调用失败怎么处理？
• 幻觉、成本、延迟分别怎么控制？
• 有没有失败样本分析，而不是只展示成功 demo？

大模型应用的竞争点不在于你知道多少模型名，而在于你能不能把模型的不确定性管理成一个可上线、可监控、可复盘的系统。

避免套壳的证据链

大模型应用要证明不是套壳，不能只说接入了某个模型。你需要拿出证据链：业务问题、资料处理、工具边界、评估方法、成本和失败兜底。

这篇文章可以更强调一句：大模型项目的难点不是让它回答一次，而是让它在大量真实问题里稳定、可控、可复盘。