简历上写了AI项目,怎么才能拉开差距?

3308 words
17 minutes
简历上写了AI项目,怎么才能拉开差距?

简历上写了AI项目,怎么才能拉开差距?#

作者:马丁不会代码(10年大厂后端,Apache ShardingSphere Committer,Hippo4j 作者,现 All in AI 落地一线)

来源:牛客网 | 更新日期:2026/6/4


一、确定业务场景:你的项目到底在给谁用?#

很多同学简历上写”基于 RAG/Agent 实现智能体系统”,面试官第一个问题一定是:什么场景?谁在用?解决什么问题?

如果你回答”只是一个通用问答”,这条项目基本就废了。

1. 为什么业务场景这么重要?#

RAG/Agent 的每个环节——分块策略、检索方式、Prompt 设计、意图识别、循环问答、上下文记忆——都跟业务场景强相关。同样是智能客服,电商客服和企业 IT 客服的知识库结构、用户问法、回答要求完全不一样。

2. 场景怎么定?不要凭空编,去抄真实的#

电商客服为例:

  • 调研真实商城:去小米商城、无印良品、网易严选等平台,摸清客服系统
  • 梳理意图体系:3个一级意图(产品咨询、用户反馈、闲聊兜底)、22个二级意图
  • 构建文档体系:115篇知识库文档,刻意埋参数表、对比表、故障树等结构化内容
  • 设计评估集:150条评估 Query,标注难度(简单/中等/困难)

3. 值得参考的方向#

场景文档类型典型问题技术难点
电商客服商品详情、售后政策、操作手册多商品对比、故障诊断结构化表格检索、跨文档多跳推理
企业 IT 帮助台内部系统操作手册、故障处理 SOPVPN怎么连、系统报错多系统意图路由、权限隔离
法律咨询法规条文、司法解释合同纠纷、诉讼时效条款精确匹配、多法规交叉引用
金融理财产品说明书、风险提示基金风险等级、手续费数值精度、合规约束

关键是能回答三个问题:

  • 用户是谁?→ 电商买家、企业员工、法务人员
  • 他们会问什么?→ 能列出10-20个典型问题
  • 回答错了会怎样?→ 决定了你对幻觉抑制的要求有多高

二、Agentic RAG:从查资料到帮用户解决问题#

这是面试中最能拉开差距的部分。

1. 什么是 Agentic RAG?#

一句话概括:让 RAG 系统具备规划、决策和行动能力,不只是查资料,而是像一个有经验的客服一样帮用户解决问题。

用户问题Naive RAGAgentic RAG
扫地机 T20 吸力多大?检索详情页返回参数 ✅同左(简单问题不需要 Agent)
T20 和 T20 Pro 选哪个?检索两个 chunk,可能拼不全 ⚠️并行检索,结构化对比后推荐 ✅
120平有猫有小孩,预算5000配方案检索到不相关的 chunk ❌拆解约束,多轮检索+调价格接口 ✅

2. Agentic RAG 的核心能力#

2.1 推理与行动交替(ReAct)#

LLM 在一个思考→行动→观察的循环中逐步推进,每一步做什么不是预先写死的,而是根据上一步的结果动态决定。

2.2 任务规划与分解(Plan-and-Execute)#

先退一步想清楚整体方案,再分步执行。Agent 知道一次检索解决不了问题,需要分多步、有策略地收集信息。

2.3 工具编排与 MCP 协议#

常见工具:price_queryinventory_checkorder_lookupcoupon_querycompare_productswarranty_claim

  • MCP 协议(Model Context Protocol) 注册和调用
  • 新增工具只需实现执行器接口并注册,不用改主链路代码

2.4 技能封装(Skill)#

把常见的多步操作打包成一个可复用的能力单元:

Skill内部逻辑
商品对比并行检索两个商品详情 + 调价格接口 + 按对比模板输出
选购推荐分析用户约束 → 知识库筛选 → 查价格 → 组合推荐
故障诊断检索故障树 → 引导式多轮追问 → 定位原因 → 给方案或转人工

打个比方:Tool 是螺丝刀、扳手,Skill 是”换轮胎”这个完整操作。

2.5 自我反思与纠偏(Self-Reflection)#

  • 检索质量检查:检索结果相关度低?换 query 重新检索
  • 答案完整性检查:用户问了三个子问题只覆盖了两个?补充检索
  • 工具结果校验:价格接口返回异常值?降级为用户到商品页查看
  • 幻觉自查:答案中包含检索上下文没有的参数数据?触发兜底

这种自我纠偏能力,是 Agentic RAG 和固定流水线的根本区别。

3. 完整场景串讲——扫地机选购#

用户:120平,两只猫,客厅铺地毯,T20 和 X20 Pro 哪个合适?哪个更划算?

Agent 执行过程:

[思考] 复杂选购决策,三个维度:场景适配、产品对比、价格对比 [行动] 并行检索知识库 + 调价格接口 [观察] X20 Pro 更匹配养宠场景(8000Pa吸力、防缠绕、自动集尘) [思考] T20 5000Pa低于建议值,X20 Pro 更合适 [行动] 生成结构化推荐

固定流水线像流水线工人;Agent 像一个有经验的销售顾问


三、面试怎么讲 Agentic RAG?#

1. 先讲核心区别#

Naive RAG:固定流水线——Query 进来,检索,生成,结束 Agentic RAG:LLM 在决策位——自己判断检索还是调工具、一步到位还是分步推进、质量够不够要不要重试

2. 用设计模式撑起深度#

模式说明场景举例
ReAct思考→行动→观察,循环推进故障诊断
Plan-and-Execute先规划再执行全屋清洁方案推荐
Tool Use动态选择和调用工具查实时价格、查库存
Self-Reflection检查中间结果,不够就重试检索结果不相关时换 query
Multi-Step多次检索/调用才能回答配件兼容查询

3. 落到工程实现上#

  • 意图识别:规则层快速过滤 + LLM 分类兜底
  • ReAct 死循环控制:最大推理步数 5 步,超过强制生成最优答案
  • 工具调用协议:MCP 协议,参数 Schema 注册
  • KB 和 Tool 结果合并:Prompt 里分区标注来源
  • 工具调用失败降级:不阻断主流程,降级为纯 KB 回答

四、评测体系:你怎么知道系统效果好不好?#

1. 分层评测思路#

评测层核心指标参考目标
意图识别与路由决策Top-1 准确率>= 90%
检索质量Hit@5、context_recallHit@5 >= 90%, recall >= 0.80
工具调用质量工具决策准确率、参数提取准确率
生成质量faithfulness、answer_relevancyfaithfulness >= 0.90
Agent 行为质量多步完成率、自我纠偏成功率
业务红线与性能误拒率、错答率、P95 延迟

2. 评估集怎么建?#

  • 覆盖所有意图类型和路径组合
  • 难度分级:简单、中等、困难
  • 标注完整:期望文档 ID、标准答案、意图标签、工具调用真值
  • 口语化:模拟真实用户输入,含错别字、省略
  • 规模:50-100 条起步 → 150-200 条完善(30% 以上涉及工具调用)

3. 面试怎么讲评测?#

讲清楚三件事:

  1. 你评了什么:150 条评估集,覆盖 22 个意图,三档难度分布
  2. 结果怎么样:意图准确率 95%,Hit@5 92%,faithfulness 0.93
  3. 做了什么优化:发现问题 → 定位原因 → 改进 → 提升数据

五、生产级工程能力#

1. AI 基础设施层#

  • 模型路由与多级 Fallback:阿里百炼 → SiliconFlow → 本地 Ollama
  • 三态熔断器:CLOSED → OPEN → HALF_OPEN → CLOSED
  • 流式首包探测:首包到了才算成功,超时切下一个模型
  • Embedding / Rerank 也需要路由和 Fallback

2. 数据管道层#

  • 文档入库流水线:抓取 → 解析 → 分块 → 向量化 → 入库
  • 按文档类型选择分块策略:商品详情页按段落、售后按条款、FAQ 按问答对
  • 定时同步与增量更新:旧 chunk 删除 + 新 chunk 入库原子操作

3. Agent 运行时层#

  • 多路检索引擎:意图定向检索 + 向量全局检索并行
  • 会话记忆管理:混合策略——最近几轮完整保留,超出触发 LLM 摘要压缩
  • Prompt 模板管理:模板引擎管理,支持版本管理
  • Agent 循环控制:最大步数、单步超时、Token 预算、重复行为检测

4. 并发与限流层#

  • 分布式排队限流:Semaphore + ZSET + Lua + Pub/Sub
  • Token 成本控制:区分场景用不同级别模型,简单问题快速短路

5. 可观测性层#

  • 全链路追踪:TTL 跨线程透传
  • Agent 决策日志:ReAct 每一步都落日志
  • 关键指标:请求量/成功率/P95延迟、意图分布、工具调用成功率、平均 ReAct 步数、Token 消耗分布

六、面试怎么讲这个项目?#

一分钟项目介绍模板#

我做了一个企业级 Agentic RAG 智能问答系统,业务场景是 XXX(电商客服/企业帮助台/…)。和普通 RAG 不同的是,系统采用 ReAct 模式,LLM 自主决定每一步该检索知识库还是调用业务接口,支持多步推理和自我纠偏。核心技术包括意图识别与动态路由、多路检索引擎、MCP 工具编排、模型路由与三态熔断、分布式排队限流。

在评测方面,基于真实业务场景构建了 150 条评估集,覆盖 22 个意图类型,分层评测意图准确率、检索命中率、工具调用准确率和生成忠实度。检索 Hit@5 达到 XX%,工具决策准确率 XX%,生成 faithfulness 达到 XX。

技术栈是 Java 17 + Spring Boot 3 + PostgreSQL / Milvus + React 18,后端约 4 万行代码。

高频追问应对#

问题回答要点
检索效果不好怎么优化?先定位问题在哪一层:Hit@5 低→分块/Embedding;context_recall 低→分块策略/Rerank;answer_correctness 低→Prompt
怎么解决幻觉?多层防线:Prompt限定来源+兜底指令、检索设相似度阈值、Agent生成后自查、RAGAS持续监控
和 LangChain/Dify 搭的有什么区别?生产环境需要精确控制——熔断、限流、检索通道、上下文透传,框架不提供或方案不适合
Agentic RAG 和普通 RAG 核心区别?控制权在谁手里——流水线 vs LLM 自己做决策
ReAct 怎么防止死循环?最大步数上限 + 单步超时控制 + 重复行为检测
会话记忆怎么处理?混合策略:近几轮完整保留,超出触发摘要压缩;ReAct 中间推理不存进记忆

七、最容易踩的坑#

  1. 只讲技术栈,不讲业务决策 —— 技术选型要和业务场景绑在一起讲
  2. 说不出具体数字 —— 评估集多少条、Hit@5 多少、优化前后对比
  3. 把框架当成自己的能力 —— 说清楚框架帮你做了什么、你自己做了什么
  4. 不了解自己项目的代码 —— 面试前挑 2-3 个最熟的模块 Debug 一遍
  5. 讲 Agent 只停留在概念 —— 要能拿出一个复杂问题,一步步还原推理过程
  6. 忽略成本和延迟 —— 准备好简单/复杂问题平均步数、Token 消耗范围、P95 延迟
  7. 评测只覆盖了 happy path —— 评估集至少 30% 应该是 Agent 特有的复杂场景

八、面试前的检查清单 ✅#

业务场景#

  • 服务什么业务场景?目标用户是谁?
  • 梳理了多少种用户意图?举 3 个典型的
  • 知识库有多少篇文档?文档体系怎么设计的?

Agentic RAG#

  • ReAct 模式是什么?和固定流水线的区别?
  • 举一个复杂问题,用 思考→行动→观察 讲清推理过程
  • 检索结果质量不够时怎么自我纠偏?
  • 工具调用失败了怎么降级?

评测体系#

  • 评估集多少条?意图分布和难度分布怎样?
  • 评了哪几层?每层用什么指标?
  • 基于评测结果做过什么优化?给出具体数字

工程能力#

  • 模型 API 挂了怎么办?三态熔断器状态转换条件?
  • 大模型并发限制怎么处理?
  • Prompt 模板怎么管理?版本控制和效果回退?
  • Agent 的 Token 消耗大概什么量级?怎么控制成本?

对比优势#

  • 和用 LangChain/Dify 搭的有什么区别?
  • 最有挑战的技术难点是什么?怎么解决的?

写在最后#

面试官想听的从来不是技术名词的堆砌,而是你解决问题的思考过程

把上面的问题,对着自己的项目一个个过一遍。能讲清楚的,写进简历;讲不清楚的,要么补,要么删——简历上每一行字,都得是你能扛住追问的。

祝大家都能拿到心仪的 offer。🎉


马丁|10 年大厂后端,Apache ShardingSphere Committer,Hippo4j 作者(GitHub 6k+ Star),现 All in AI 落地一线。

Share Article

If this article helped you, please share it with others!

简历上写了AI项目,怎么才能拉开差距?
https://estars-blog.pages.dev/posts/经验贴-简历上写了ai项目怎么才能拉开差距/
Author
Estars
Published at
2026-06-26
License
CC BY-NC-SA 4.0
Profile Image of the Author
Estars
这条路要走完,才能看到世界的终点,是海纳百川,还是星火燎原。
公告
欢迎来到我的博客!这是一则示例公告。
Music
Cover

Music

No playing

0:00 0:00
No lyrics available
Categories
Tags
Site Statistics
Posts
85
Categories
7
Tags
15
Total Words
218,958
Running Days
0 days
Last Activity
0 days ago

Table of Contents