没有真实做过怎么描述

大约 13 分钟

先明确底线

这篇的核心不是“教你包装成大佬”，而是教你 真实、稳妥、有边界 地表达。
目标是让你在追问下依然站得住，而不是靠夸大撑场面。

快速使用方式

先看“一、最重要原则”和“二、话术模板”。
再看“六、最容易露馅细节”，把高风险表达删掉。
最后背“十、防露馅完整版”，改写成你自己的版本。

一、最重要原则：不要把自己说成全栈全包负责人

很多人一上来就说：

我负责整个 RAG 系统设计
我从0到1搭建知识库平台
我主导模型选型、向量库选型、数据治理、评估体系、前后端联调、上线运维

这种最容易死。
因为真正做过项目的面试官会立刻往深处问：

为什么选这个向量库？
embedding 模型为什么换过？
chunk 重叠多少？
rerank 阈值怎么定？
监控埋点有哪些字段？
知识库增量更新怎么做？
文档解析失败率高的格式是什么？
线上 badcase 占比最高的是哪类？

如果你没做过，很快就穿帮。

正确策略
把自己定位成：

方案A：后端/应用开发主责

我主要负责在线问答服务、文档入库接口、Prompt 拼接、结果后处理和部分效果优化。

方案B：RAG链路参与者

我重点参与了检索链路和回答质量优化，比如 chunk 调整、query 改写、rerank 接入和拒答机制。

方案C：工程实现角色

我不是算法训练方向，更多是把模型能力接入业务系统，解决稳定性、接口封装、日志追踪和降级问题。

这三种说法都更像真实参与者。

二、最像真实参与者的话术模板

你可以直接用下面这套。

**1. 项目开场别说太满
**

**不像真实参与者的说法
**

我从0到1搭建了企业知识库问答平台，负责整体方案设计和全链路落地。

**更真实的说法
**

这个项目整体是团队一起做的，我主要负责的是在线问答服务这块，以及文档入库链路的一部分实现。
更具体一点，就是用户提问之后的检索、Prompt 组装、模型调用、结果返回，还有一部分 badcase 优化我参与得比较多。

这句话的好处是：

有边界感
不抢功
不容易被深挖到全部细节
但听起来仍然有参与度

**2. 讲职责时要“半具体”
**
不要太空，也不要过细到自己接不住。

**好用模板
**

我主要做了三块：
文档入库链路的一部分接口和任务处理
在线问答服务，包括检索、重排接入、Prompt 拼接和模型调用
一些效果优化和稳定性工作，比如拒答、超时重试、日志记录和 badcase 分析

这就很像真做过。

三、没有真实做过时，最安全的“项目角色定位”

我最推荐你把自己定位成：

**“AI应用开发 / 后端实现 + 效果联调角色”
**

为什么这个定位最安全？

因为这个角色天然可以只熟悉：

API 和服务设计
文档入库流程
检索调用流程
向量库怎么用
Prompt 怎么拼
重试、超时、日志怎么做
和算法/产品/前端怎么协作

而不需要你一定精通：

模型训练
embedding 原理深层细节
向量索引复杂参数
rerank 模型训练细节
大规模分布式检索优化

这非常适合面试。

四、面试里最像“真实做过”的表达特征

真正做过项目的人，说话通常有这几个特点：

**特征1：会说“当时我们先这样做，后面再优化”
**
比如：

一开始我们 chunk 切得比较粗，后面发现召回不稳定，才逐步改成按标题和段落结合 overlap 的方式。

这就比“我们采用了先进的层次化切分方案”真实很多。

**特征2：会承认方案不完美
**
比如：

当时第一版其实主要先追求链路跑通，评估体系没那么完整，后面 badcase 多了才补测试集和回归流程。

这很像真实项目。
因为真实项目几乎都不是第一版就完美。

**特征3：会提到协作关系
**
比如：

embedding 模型选型不是我主导的，我更多是负责把接口接进来，然后配合看线上效果。
rerank 这块我主要负责服务接入和链路联调，模型本身不是我训练的。

这非常加分，因为很像真实团队分工。

**特征4：会提到工程上的麻烦，而不是只谈“高大上能力”
**
比如：

我们当时其实花了不少时间处理格式问题、超时问题、日志追踪这类工程细节，这些比单纯把模型调通更花时间。

真实得不能再真实。

五、你最该背的“真实参与者版本”项目介绍

下面这版最推荐你背。

**真实参与者版项目介绍（推荐）
**

这个项目是一个企业内部知识库问答系统，主要场景是员工查询制度流程、产品文档、操作规范这类内容。
整体方案上是基于 RAG 做的，离线会把文档解析、切分、向量化入库，在线会做问题处理、检索、重排、Prompt 组装和模型生成。
我在里面不算是做模型训练那部分，我更偏应用开发和后端实现。
我主要负责的是在线问答服务，还有一部分文档入库链路的实现。比如文档上传后的处理状态管理、问答接口、检索调用、Prompt 拼接、模型结果后处理这些。
后面在效果优化上我也参与了一些，比如 query 改写、拒答逻辑、引用返回和 badcase 分析。
这个项目里我感受比较深的是，很多时候问题表面上看是模型答得不对，但往往根因在检索阶段，或者在上下文组织上。所以我们后面花了不少精力在 chunk、召回和 rerank 这块，而不是一味想着换更强模型。

这版的好处是：

不会显得太假
有边界
有技术感
有问题意识
容易接追问

六、面试时哪些细节最容易露馅

这是重点。

**露馅点1：数据量张口就来，还特别夸张
**
比如：

我们有几千万文档
每天几十万问答
向量数据亿级
支撑全集团

如果你没做过，这种量级很容易被追问架构细节。
建议保守说。

**安全说法
**

当时规模不算特别大，更多是中小规模企业知识场景，重点挑战还是效果和工程稳定性，而不是超大规模分布式问题。

或者：

初期知识量主要是内部制度、产品和流程文档，规模还在可控范围内，所以我们当时重点更多放在效果优化和链路建设。

**露馅点2：指标说得太精确
**
比如：

准确率从73.2%提升到89.6%
幻觉率下降41.7%
响应时间优化62%

没真实数据支撑，很容易被问：

指标准确定义是什么？
评估集有多少条？
标注规则是什么？
谁来判定准确？

**安全说法
**

优化之后，从业务反馈和 badcase 回归上看，相关性和可用性是有明显提升的。
如果说量化指标，当时更多是结合命中情况、人工抽样和线上反馈来判断，评估体系还在逐步完善。

如果非要给数字，就说模糊一点：

从我们几轮回归结果看，badcase 数量有比较明显下降，尤其是检索偏题和无依据作答这两类问题改善比较明显。

**露馅点3：工具名、框架名背太多
**
比如：

我们用了 LangChain、LlamaIndex、Milvus、FAISS、Elasticsearch、vLLM、Kafka、Airflow、XX 模型、XX 框架……

面试官一看就知道你像“技术名词收集器”。
你要记住，真实参与者不靠背名词取胜，靠的是“知道这东西在链路里干嘛”。

**正确说法
**

向量检索这块我们接的是现成向量库，重点不是我去做底层索引实现，而是把检索能力接到问答链路里，并处理权限过滤和召回结果组织。

**露馅点4：把每一块都说自己做的
**
真实团队项目没人什么都做。

**更真实说法
**

embedding 模型选型是算法同学主导，我主要做接入和联调
rerank 模型不是我训练的，我主要负责服务调用和效果联调
权限体系不是我从零设计的，我是在问答链路里把权限过滤接上

这才自然。

七、哪些回答方式最像真参与过

**1. 多用“当时”“一开始”“后面”“我们发现”
**
例如：

一开始我们是想先把链路跑通，所以第一版没有做太复杂的 query 改写。
后面发现用户提问和文档表达差异比较大，才逐步补了这块。

这种时间线特别真实。

**2. 多用“我负责实现/接入/联调/优化”
**
少用“我设计了完整平台”“我构建了体系”。

**比如：
**

我主要负责问答接口和模型调用这块的实现。
rerank 是后面接进来的，我负责把这一步插到检索后、生成前的链路里。

**3. 偶尔承认“不完全由我负责”
**
这是加分，不是减分。

**比如：
**

那块更偏算法侧，我不是主负责人，我主要关注它接进来之后对线上效果的影响。

这真的很像真实团队协作。

八、最安全的“项目深挖应答策略”

如果面试官开始深挖，你要遵守一个原则：

**原则：只深挖你能控制的层，主动给自己画边界
**

比如问：
**“embedding 模型为什么选这个？”
**
你可以答：

模型选型不是我主导的，我更多是做接入和联调。
从应用侧感受，主要看两个维度：一个是检索相关性，另一个是推理成本和稳定性。
当时我们更关注的是线上问答效果，所以会结合 badcase 看召回质量。

这个回答就很稳。
既没硬装懂训练，又显得你懂业务工程。

九、给你一套“像真实参与者”的万能句式

你可以反复用。

**万能句式1：描述职责
**

我主要负责的是 XXX 这块，偏应用开发和工程实现，模型训练本身不是我主导的。

**万能句式2：描述方案
**

当时第一版先把主链路跑通，后面再根据 badcase 逐步补优化。

**万能句式3：描述问题
**

这个问题表面上看像生成问题，但我们后来排查发现根因更多在检索侧。

**万能句式4：描述权衡
**

当时我们没有一上来就换更强模型，因为成本会上去，而且根因不一定在模型本身。

**万能句式5：描述协作
**

这部分我主要负责接入和联调，和算法/产品同学一起迭代效果。

**万能句式6：描述收获
**

这个项目让我感受到，AI 应用真正难的地方不是模型 API 调通，而是把它做成一个可控的线上服务。

十、你可以直接背的“防露馅版本”

下面这版非常适合“没真做过但想说得像参与者”。

**防露馅完整版
**

这个项目是企业内部知识库问答系统，主要是让员工能直接通过自然语言查询制度、流程和文档内容，减少重复答疑。
整体是基于 RAG 做的，离线会把文档解析、切分、向量化入库，在线是问题预处理、检索、重排、Prompt 拼接和模型生成。
我在这个项目里主要偏应用开发，不是做模型训练那部分。
我负责得比较多的是在线问答服务，还有文档入库链路的一部分实现。
比如问答接口、检索调用、Prompt 组装、模型结果后处理、失败重试、日志记录这些。
后面在效果优化上也参与了一些，像 query 改写、拒答逻辑、引用返回和 badcase 分析。
项目里让我印象比较深的是，第一版其实链路能跑通，但回答相关性不够稳定。
后来我们看了一些 badcase，发现很多问题不是模型本身能力不够，而是检索出来的内容不够准，或者上下文组织得不够好。
所以后面我们主要在 chunk、query 改写、rerank 和拒答机制上做优化，而不是一开始就直接换模型。
这个项目让我比较大的收获是，AI 应用开发本质上还是工程问题，要把模型能力和检索、权限、日志、降级这些能力一起做起来，系统才真的能落地。

十一、如果被问到不会的点，怎么圆得自然

这个很重要。

**场景1：问到底层模型细节
**
**回答：
**

这个更偏模型侧，我不是主负责人。
我从应用侧接触更多的是它接进来之后对检索效果和响应性能的影响。

**场景2：问到具体参数
**
**回答：
**

这个参数我记得不是绝对固定值，当时是根据几轮 badcase 和线上效果不断调的。
我印象里思路是控制召回噪音和上下文长度之间的平衡。

**场景3：问到精确指标
**
**回答：
**

我手里没有特别精确到最终版本的数字，更多记得的是优化后 badcase 明显下降，尤其是检索偏题和无依据回答改善比较明显。

**场景4：问你是否主导
**
**回答：
**

不完全算我一个人主导，更像是我负责其中应用服务和链路实现这一块，和团队一起推进的。

十二、最后提醒：千万别做这3件事

**1. 不要背成论文答辩
**
太完整太流畅，反而像假的。

**2. 不要每个问题都给“标准答案”
**
真实参与者会有犹豫、有边界、有“这块我主要配合”。

**3. 不要吹大规模和超强结果
**
中等规模、真实问题、渐进优化，最像真项目。

十三、最后给你一句核心心法

如果你没真实做过，不要试图表现成“从0到1全栈主导者”，
最好的策略是把自己说成“参与过关键链路实现和优化的人”。

这才最稳。