平安科技二面面经：项目全过程、RAG 全链路与 AI 方法论

《面试题目》

1. 做个自我介绍。
2. 自我介绍太短了，展开介绍一下你的项目吧。
3. 有没有什么亮点的业绩或者成果？
4. 详细说一段完整的、从产品经理沟通，到需求分析，再到开发测试上线的全过程。
5. 说一下 RAG 的全链路，以及你这个项目上线后有多少流量？
6. 你是哪的人，为什么想来这边？
7. 说说你的 AI 方法论：什么场景适用，什么场景不适用？

（帖内提到还有一些围绕项目与实习的追问没有记全；全程不考技术基础与八股，最后是反问环节。）

《参考解析》

自我介绍与项目介绍为什么会被「嫌短」。 二面面试官通常已经看过简历，他要的不是复述履历，而是判断你值不值得再花半小时。一分钟版自我介绍的结构可以是：我是谁（学校、届别、方向）+ 我做过什么（两段实习各一句，点出业务域与我的角色）+ 我最拿得出手的一件事（一句结论式的成果）+ 我和这个岗位的连接点（为什么是你们、为什么是这个方向）。被说「太短」之后展开讲项目，要按「业务背景—我的职责—技术方案—遇到的取舍—结果数据」讲，而不是从技术栈开始念。关键差别在于：把「我用了什么」换成「我解决了什么问题、当时有哪几个选项、我为什么选这个、后来验证是对的」。面试官记不住十个技术名词，但记得住一个「他在两个方案里选了更难但更稳的那个」的判断。

亮点业绩该怎么量化。 「有没有亮点成果」这道题实际上在问：你能不能证明自己做的东西真的产生了价值。可用的量化维度有：效率（原本人工处理几小时，现在几分钟；每天节省多少人力工时）、规模（日请求量、覆盖多少设备或工单、多少用户在用）、质量（准确率、召回率、人工复核通过率、误报下降幅度）、稳定性（可用性、P99 延迟、故障次数）、成本（单位请求成本下降、token 消耗下降、资源占用下降）。如果没有线上数据，就退一格讲可验证的中间结果：评测集上的指标对比、灰度期间的抽样人工评估、上线前后的处理时长对比。切忌编数字——面试官往往会追问这个数字怎么统计出来的、统计口径是什么、分母是什么，答不上来比没有数字更扣分。反过来，能讲清口径（比如「抽取 200 条线上真实工单做人工标注对比」）本身就是加分项。

端到端交付全过程这道题怎么答。 面试官想听的是你有没有完整走过一轮交付，而不是只会写代码。按阶段讲：需求阶段怎么跟产品对齐（把模糊描述转成可验收的标准，明确边界与不做的事、对齐埋点与成功指标）；方案阶段产出什么（接口与数据结构、影响面、灰度与回滚方案、风险点）；开发阶段怎么控制质量（小步提交、自测、code review、必要的开关与降级）；测试阶段怎么覆盖（功能用例、边界与异常用例、真实数据回放、性能压测）；上线阶段（灰度发布、监控看板、告警阈值、回滚预案）；上线后（看数据、复盘、把问题沉淀成文档或自动化检查）。其中最能体现水平的细节是两个：一是有没有把「验收标准」在动手前写下来，二是出问题时能不能快速用监控和数据定位而不是靠猜。如果过程中有和产品意见不一致、或者发现需求本身有坑而推回去改方案的经历，很值得讲——这类冲突处理的例子比顺利交付更有说服力。

RAG 全链路与「上线后多少流量」。 RAG 的链路可以拆成离线与在线两段。离线：数据接入（文档、工单、网页、数据库）→ 清洗（去噪、去重、格式归一）→ 切分（按结构语义切、保留标题路径与来源元数据）→ 向量化（选 embedding 模型，注意语言与领域适配）→ 索引（向量库 + 关键词索引，保留 filter 字段）。在线：查询改写与意图判定 → 混合召回（向量 + BM25）→ 融合与 rerank 精排 → 上下文组装（控制长度、去重、带引用）→ 生成（约束格式与拒答）→ 引用与溯源 → 反馈回流。工程上还要补三件事：评测（召回率与最终答案质量分开评，建固定评测集做回归）、监控（不命中率、空回答率、延迟、token 成本）、兜底（检索不到就明确说不知道，而不是让模型硬编）。面试官追问流量，考的是你有没有真正把东西推上线并被使用：日活或日请求量、峰值 QPS、平均与 P99 延迟、缓存命中率、单次请求成本。哪怕量很小，只要说清「有多少真实用户、解决了他什么高频问题」，也远胜过含糊的「已经上线」。

AI 方法论：什么场景适用、什么场景不适用。 这是这场面试里最有分量的一道题。适用的场景通常同时满足几条：任务本身是概率性的、可容忍一定错误率（客服分流、摘要、检索、草稿生成、代码补全）；有足够的样本或知识可以喂（历史工单、文档、标注数据）；有反馈闭环可以持续纠偏（用户点选、人工复核、A/B）；收益随规模放大（人工处理量越大，自动化越值钱）。不适用或要先降级的场景：结果需要强可解释、可审计、可复现的场合（合规判定、资金相关的自动决策）；错误代价极高且不可回滚（直接自动改代码、自动对外发布）；缺少数据与反馈的长尾任务（新业务无历史样本）；确定性规则已经能百分百解决、引入模型只会增加延迟与成本的问题（用正则就能解析的字段）。落地上更实用的原则是「把判断交给模型，把确定性留给代码」：模型的产出要能被结构化校验、要有置信度或不确定性表达、要在低置信时转人工，同时给整条链路设好成本与延迟预算。能讲清「我评估过一个场景最后决定不上 AI」的例子，往往比讲成功案例更能体现判断力。至于「为什么想来这边」这类问题，真诚且具体即可：结合岗位所在业务、城市与生活安排、以及你想做的方向，别背标准答案。