AI 项目实战案例
面试中「讲一个你做过的大模型项目」往往是重头戏。本文把 Boss 岗位要求拆成可复述的作品集故事：你解决了什么业务问题，怎么做架构取舍，如何评估效果，以及面试官追问时怎么答。
面试如何讲项目？
比起堆功能，面试官更想听你做了什么决策、遇到什么难点、怎么权衡解决。建议按这个顺序讲：
- 业务场景：谁在什么流程里用，原来痛点是什么。
- 系统架构：数据从哪里来，经过哪些模块，最后如何返回给用户。
- 核心模块：RAG、Agent、Tool Calling、Memory、评估、安全、可观测分别负责什么。
- 技术选型：为什么选 LangGraph / LlamaIndex / Spring AI / MCP / 向量库。
- 评估指标：准确率、召回率、忠实度、延迟、token 成本、人工节省、合规拦截率。
- 面试讲法：用「目标 - 架构 - 难点 - 效果 - 反思」讲成一个完整故事。
- README 亮点：把项目包装成作品集，截图、架构图、评测报告、运行方式都要可见。
切忌只说「我用 LangChain 调了个 API」。要体现工程权衡、业务理解和效果意识。
项目一：金融投研 Agent
适合投研平台、券商终端、基金研究、量化研究和金融 AI 应用岗位。
业务场景
研究员每天要看公告、研报、财报、行情、新闻和内部观点，问题不是「没有信息」，而是信息分散、口径不一、时效要求高、结论需要可追溯。项目目标是做一个投研 Agent：用户输入「分析某公司本季度利润变化原因」或「生成新能源板块晨会摘要」，系统自动检索资料、调用行情工具、汇总证据并生成带引用的投研草稿。
系统架构
用户问题
-> 意图识别/任务规划
-> 金融知识库 RAG：公告/研报/财报/内部纪要
-> 工具调用：行情、财务指标、新闻、估值模型、图表生成
-> LangGraph 编排：检索 -> 分析 -> 校验 -> 撰写 -> 风控审查
-> SSE 流式返回：结论、证据、引用、风险提示
-> 日志/Trace/评估集沉淀核心模块
- 金融 RAG：按公司、行业、时间、报告类型建立元数据；混合检索向量 + BM25，再用 Rerank 提升证据命中。
- 投研 Agent：用 LangGraph 表达任务状态，拆成规划、检索、分析、写作、校验节点，避免单 prompt 一把梭。
- Tool Calling / MCP：把行情接口、财务数据库、估值计算器、图表服务封装成工具，统一参数 Schema 和权限控制。
- Memory：保存用户关注行业、常用估值口径、历史问答和自选股，作为个性化上下文，但不把敏感信息直接拼进 prompt。
- 安全合规：输出投资建议免责声明；敏感结论加人工审核；对未授权研报、内幕信息、夸大收益做拦截。
- 可观测：记录每次检索命中文档、工具调用参数、token、延迟、失败节点，便于定位「召回错」还是「分析错」。
技术选型
- 编排：LangGraph，适合有状态、多步骤、可回放的 Agent 流程。
- 知识库：LlamaIndex / LangChain + Milvus / Elasticsearch / pgvector，支持元数据过滤和混合检索。
- 工具协议：Function Calling 或 MCP，把内部投研平台能力工具化。
- 服务层：FastAPI / Spring Boot，前端用 SSE 做流式输出。
- 评估：RAGAS + 自建金融 QA 集 + 人工盲评，覆盖事实正确、引用准确、结论合规。
评估指标
- 检索：Recall@5、MRR、引用命中率、时间过滤准确率。
- 生成：事实忠实度、观点可解释性、引用覆盖率、幻觉率。
- 业务：晨会摘要生成耗时、研报初稿节省时间、研究员采纳率。
- 工程：P95 延迟、单次 token 成本、工具调用成功率、合规拦截率。
面试讲法
可以这样讲：
我做的不是普通聊天机器人，而是面向投研流程的 Agent。它先判断问题类型，再检索公告、研报、财报和内部纪要，同时通过工具调用拿实时行情和财务指标。为了让流程可控，我用 LangGraph 把任务拆成检索、分析、校验、撰写几个节点，每一步都有 Trace。上线后我们重点优化了两个问题：一是金融材料时效性强，所以检索必须带时间和证券代码过滤；二是投研场景不能乱给建议，所以回答必须带引用和风险提示，并对敏感结论做规则与人工复核。
常见追问与回答
Q：为什么用 Agent，而不是普通 RAG 问答？ A：投研问题经常需要多步推理和外部数据，比如先查公告，再算同比环比，再结合新闻解释原因。普通 RAG 更像一次检索 + 生成，Agent 可以规划步骤、调用工具、校验中间结果，更贴近真实工作流。
Q：怎么避免模型编造财务数据？ A：数值类问题不让模型凭上下文生成，而是通过工具查财务数据库或行情 API；模型只负责解释和组织语言。回答里保留数据来源、报告期和指标口径，评估时单独统计数值一致性。
Q：MCP 在这里有什么价值？ A：MCP 可以把行情、研报库、财务指标、图表等能力做成标准工具，Agent 不直接耦合各系统 API。后续换模型或新增工具时，只要维护工具描述和权限策略。
可落地的 README 亮点
- 放一张「投研 Agent 工作流」架构图和一段 SSE 流式回答截图。
- 提供 5 个可复现 Demo：个股财报解读、行业晨报、公告摘要、估值对比、风险提示。
- 展示评测表：Recall@5、事实忠实度、P95 延迟、单次成本。
- 列出合规策略：引用溯源、免责声明、敏感内容拦截、人工复核入口。
项目二：企业知识库 RAG
适合 AI 平台、企业 Copilot、知识库问答、RAG 系统研发岗位。
业务场景
企业内部文档分散在 PDF、Word、网页、飞书/Confluence、客服工单和历史邮件中，员工查制度、产品手册、售后流程时经常找不到最新版本。项目目标是搭建企业知识库 RAG：用户自然语言提问，系统返回答案、出处、相关文档和置信度，并支持权限隔离。
系统架构
文档源：PDF/Word/HTML/飞书/工单
-> 解析清洗：OCR、表格抽取、去噪、版本识别
-> Chunk：标题层级、父子分块、滑窗重叠
-> Embedding + 元数据入库
-> 查询改写 + 权限过滤 + 混合检索
-> Rerank + 上下文压缩
-> Prompt 组装 + LLM 生成
-> 引用溯源 + 反馈采集 + 评估闭环核心模块
- 文档解析：处理 PDF、扫描件、表格和目录层级，保留页码、标题、更新时间和部门权限。
- Chunk 策略：普通段落用语义切分，制度类文档按标题层级切分，长文档用父子分块兼顾召回与完整上下文。
- 检索链路：查询改写、多路召回、向量检索、BM25、元数据过滤、RRF 融合、Rerank。
- 生成链路：Prompt 约束只基于材料作答；答案必须带引用；无证据时返回「未找到依据」。
- 权限与安全：检索前按用户身份过滤文档；防 Prompt 注入；敏感文档不进入跨部门上下文。
- 可观测与评估：记录 query、召回片段、rerank 分数、最终引用、token 成本和用户反馈。
技术选型
- 框架：LlamaIndex 适合文档 ingestion 和索引编排；LangChain 适合快速串联模型、检索器和工具。
- 向量库：Milvus 适合大规模高并发；pgvector 适合中小规模、运维简单；Elasticsearch 适合混合检索和关键词能力强的场景。
- Embedding / Rerank：中文场景可选 BGE 系列；精排用 cross-encoder 或商业 rerank API。
- 服务层：FastAPI / Spring Boot；前端通过 SSE 流式展示答案。
- 评估：RAGAS + 标注 QA 集 + 用户反馈回流。
评估指标
- 检索：Recall@K、Precision@K、MRR、权限误召回数。
- 生成：faithfulness、answer relevancy、引用准确率、拒答正确率。
- 体验：首 token 延迟、P95 总延迟、用户点赞率、转人工率。
- 成本：平均输入 token、输出 token、每 1000 次问答成本、缓存命中率。
面试讲法
可以这样讲：
这个项目我重点讲 RAG 的工程化，而不是只讲向量库。我们先把企业文档解析成带权限、版本、目录层级的知识块；查询时先做意图识别和查询改写，再按用户权限做元数据过滤，最后做混合检索和 rerank。上线后我主要优化了召回质量、权限隔离和成本：比如用父子分块解决「召回片段太碎」，用语义缓存降低重复问答成本，用评测集区分检索问题和生成问题。
常见追问与回答
Q：为什么 RAG 不直接把文档塞进长上下文？ A：长上下文成本高、延迟高，而且权限和版本不好控制。RAG 可以按问题动态取证据，保留引用和元数据过滤，也更适合文档持续更新。
Q：召回不准怎么定位？ A：先看 gold document 是否进 Top-K。如果没进，是检索问题，调 query rewrite、chunk、embedding、BM25、rerank；如果进了但答案错，是生成或 prompt 问题，调上下文排序、引用约束和拒答策略。
Q：怎么做权限隔离？ A：文档入库时写入部门、角色、租户、密级等元数据；检索前把用户权限转成过滤条件，避免先召回后过滤造成越权片段进入 prompt。
可落地的 README 亮点
- 给出 ingestion 命令、示例文档、向量库初始化脚本和本地运行方式。
- 展示「同一问题在不同权限用户下返回不同引用」的截图。
- 放评测集样例和优化前后对比：混合检索、Rerank、父子分块的指标变化。
- 列出 token 成本看板：平均上下文长度、缓存命中率、P95 延迟。
项目三：Java + Spring AI 银行客服 Agent
适合资深 Java、银行项目、AI Agent 应用开发、Spring AI / Spring Boot 岗位。
业务场景
银行客服高频问题包括账户查询、信用卡账单、贷款进度、理财产品说明、网点预约和工单流转。传统 FAQ 只能匹配固定问法，人工客服成本高。项目目标是用 Java + Spring AI 做一个银行客服 Agent：能回答制度类问题，能调用后端系统办理查询和预约，并在敏感场景安全转人工。
系统架构
Web/APP/企微入口
-> Spring Boot 网关：鉴权、限流、审计
-> Spring AI ChatClient：模型路由、Prompt 模板、结构化输出
-> RAG：产品说明、操作手册、监管制度、FAQ
-> Tool Calling：账户查询、账单查询、贷款进度、网点预约、工单创建
-> Memory：会话摘要、用户偏好、上下文状态
-> SSE：流式回复 + 工具执行状态
-> 风控合规：PII 脱敏、越权校验、敏感操作二次确认核心模块
- Spring AI 接入层：统一模型调用、prompt 模板、embedding、向量检索和 function calling。
- 客服 Agent 编排：识别用户意图，决定是走 RAG、调用工具、补充追问，还是转人工。
- 工具调用：把银行内部服务封装成可调用函数，参数用 JSON Schema 约束，执行前做鉴权和二次确认。
- Memory 管理：短期会话记忆保存当前业务流程，长期记忆只保存用户授权的偏好，不保存完整敏感对话。
- SSE 流式交互：先返回「正在查询账单/正在创建工单」等状态，再流式输出最终答复，改善体感。
- 安全合规：PII 脱敏、提示注入防护、操作审计、黑白名单工具、敏感业务强制转人工。
技术选型
- 后端：Java 17+、Spring Boot、Spring AI、Spring Security、Spring Cloud Gateway。
- 数据层：MySQL / PostgreSQL 存业务数据，Redis 存会话状态和限流，Milvus / pgvector / Elasticsearch 做知识检索。
- 消息与异步：Kafka / RocketMQ 处理工单、日志和离线评估。
- 模型能力：Chat 模型 + Embedding + Rerank + Structured Output。
- 观测：Micrometer + Prometheus + Grafana，记录 token、延迟、工具调用成功率和异常。
评估指标
- 客服效果：问题解决率、转人工率、首问命中率、用户满意度。
- 工具调用：参数正确率、工具调用成功率、敏感操作误触发率。
- RAG：引用准确率、拒答正确率、制度问答忠实度。
- 工程：P95 首 token 延迟、P95 完整响应延迟、单会话成本、错误率。
- 合规：PII 泄露率、越权拦截率、审计日志完整率。
面试讲法
可以这样讲：
这个项目我会突出 Java 工程落地。我们不是简单接一个聊天 API，而是在 Spring Boot 体系里把模型、RAG、工具调用、会话状态和审计接起来。比如客户问账单，Agent 先识别为查询类意图，再通过 Tool Calling 调内部账单服务，工具执行前校验登录态和权限，结果返回后由模型生成自然语言解释；如果涉及转账、投诉、理财购买这类敏感操作，就要求二次确认或转人工。整个过程通过 SSE 给前端流式反馈，并在 Prometheus 里监控 token、延迟和工具失败率。
常见追问与回答
Q：Spring AI 和 LangChain 有什么区别？ A：Spring AI 更适合 Java/Spring 生态，能和 Spring Boot、Security、Observability、配置管理自然集成；LangChain 生态更成熟，适合 Python 快速实验。银行 Java 团队通常更看重工程治理和已有系统集成，所以 Spring AI 是合理选择。
Q：客服 Agent 怎么保证不会越权操作？ A：模型只生成调用意图，不直接执行。工具层根据登录用户、业务权限、风控规则做校验；敏感工具要求二次确认；所有工具调用都有审计日志，失败或高风险场景直接转人工。
Q：Memory 会不会带来隐私风险？ A：会，所以要分层。短期 Memory 只在会话内保存流程状态；长期 Memory 只保存用户授权的偏好和摘要，不保存银行卡号、身份证号等敏感信息；落库前做脱敏和 TTL 管理。
可落地的 README 亮点
- 提供 Spring Boot 本地启动方式、
.env.example、Docker Compose 依赖。 - 放客服对话 Demo：制度问答、账单查询、贷款进度、网点预约、转人工。
- 展示工具 Schema、SSE 返回样例、审计日志样例。
- 给出安全清单：鉴权、限流、脱敏、二次确认、工具白名单、Prompt 注入防护。
项目四：AI 搜索 + Memory 底座（进阶）
适合 AI Native 平台、AI 搜索、Memory、MCP 平台和基础设施岗位。
业务场景
当企业里有多个 Agent 时，每个应用都重复做搜索、知识库、工具接入和记忆管理，成本高且能力不一致。这个项目把 AI 搜索、RAG、Memory、MCP 工具网关沉淀成统一底座，为客服、投研、运营、数据分析等 Agent 提供可复用能力。
系统架构
上层 Agent / Copilot
-> 统一能力网关：Search API / Memory API / Tool API
-> AI 搜索：网页、文档、图片、结构化数据、企业知识库
-> Memory：短期会话、长期偏好、事实库、任务状态
-> MCP 工具网关：工具注册、Schema、鉴权、审计
-> 评估与观测：召回质量、记忆命中、工具成功率、成本看板核心模块
- AI 搜索：多源数据接入、结构化与非结构化统一索引、混合检索、Rerank、摘要生成。
- Memory 服务：区分 conversation memory、profile memory、episodic memory 和 task state，提供写入、召回、遗忘和审计接口。
- MCP 工具网关：工具注册、权限、版本、调用日志、超时和熔断，避免每个 Agent 重复接工具。
- 成本控制：缓存、模型路由、上下文压缩、批量 embedding、冷热索引分层。
- 可观测：统一 Trace，能看到一次 Agent 请求用了哪些搜索结果、记忆和工具。
技术选型
- 检索：Elasticsearch + Milvus / pgvector，兼顾关键词、向量和过滤。
- 编排：LangGraph 或自研 workflow，把搜索、记忆和工具调用作为节点能力。
- 协议：MCP / OpenAPI Tool Schema，便于跨模型、跨 Agent 复用。
- 存储：PostgreSQL 存 Memory 元数据，Redis 做热缓存，对象存储放原文和附件。
- 评估：离线 benchmark + 在线 A/B，持续观察搜索质量和 Memory 污染。
评估指标
- 搜索：NDCG@K、Recall@K、点击率、摘要忠实度。
- Memory：记忆命中率、错误记忆率、遗忘成功率、用户关闭率。
- 工具：调用成功率、平均耗时、超时率、权限拦截率。
- 平台：接入新 Agent 的平均耗时、复用工具数、单次请求成本。
面试讲法
可以这样讲：
我把它定位成 AI Native 应用的能力底座，而不是单个聊天产品。上层 Agent 不需要自己实现搜索、记忆和工具接入，而是通过统一 API 调用平台能力。难点在于 Memory 不是简单把历史对话塞回 prompt，要区分短期状态、长期偏好和事实记忆；同时要提供遗忘、审计和权限控制，否则会出现错误记忆污染和隐私风险。
常见追问与回答
Q：Memory 和 RAG 有什么区别？ A：RAG 主要检索外部知识，强调可追溯和事实依据；Memory 更关注用户、任务和历史交互，强调个性化和连续性。生产里两者会结合，但写入策略、权限和遗忘机制不同。
Q：怎么防止 Memory 污染？ A：不是所有对话都写入长期记忆。先做写入判定，再抽取结构化事实；高风险信息需要用户确认；每条记忆保存来源、时间、置信度和 TTL，召回时按置信度和场景过滤。
Q：为什么需要统一 MCP 工具网关？ A：工具一多就会出现重复接入、权限不一致、日志缺失的问题。统一网关能集中做 Schema、鉴权、限流、审计和版本管理，上层 Agent 只关心「可用工具列表」和调用结果。
可落地的 README 亮点
- 展示 Search API、Memory API、Tool API 三类接口样例。
- 提供「接入一个新 Agent」的 10 分钟 Quick Start。
- 放 Memory 写入与召回的可视化 Trace 截图。
- 给出平台指标看板：NDCG、记忆命中率、工具成功率、token 成本。
项目五：DeepResearch 研究报告 Agent
适合 Agent 工程、AI 搜索、投研/法务/咨询、LangGraph 和多 Agent 岗位。
业务场景
企业里很多调研任务不是“一问一答”，而是“把一个问题查清楚并形成报告”。例如市场进入分析、竞品研究、法规变化解读、基金行业周报、医疗文献综述。传统做法依赖人工搜索、阅读、摘录和整理，耗时长且引用容易丢失。项目目标是做一个 DeepResearch Agent：输入研究主题后，系统自动规划子问题、搜索多来源、阅读网页和文档、交叉验证，最后生成带引用和风险提示的结构化报告。
系统架构
研究主题
-> Research Planner：生成研究大纲、子问题、搜索预算
-> Search Workers：多路搜索网页、企业文档、数据库、新闻源
-> Reader：抽取正文、表格、发布日期、作者、来源可信度
-> Evidence Store：保存引用、摘录、冲突事实和中间笔记
-> Reflect：判断证据是否足够，必要时继续搜索
-> Writer：生成报告、结论、引用、局限性
-> Reviewer：事实一致性、引用覆盖率、敏感结论检查核心模块
- 规划器：把大问题拆成 5 到 10 个可搜索子问题，并设定最大搜索轮次、来源数和 token 预算。
- 多源检索：开放网页、内部知识库、结构化数据库、PDF 报告分别走不同搜索器，再统一成 Evidence 对象。
- 阅读器：保留标题、URL、发布时间、作者、摘录、可信度和引用编号，避免生成阶段丢出处。
- 反思循环：判断是否存在证据冲突、来源不足、时间过旧、关键维度缺失，决定是否继续搜索。
- 报告生成：按“摘要、背景、发现、证据、风险、下一步”输出，并要求每个关键论断绑定引用。
- 可观测与成本：记录搜索次数、阅读页面数、平均 token、单次报告成本、失败环节和人工修改点。
面试讲法
这个项目不是普通 RAG 问答，而是长程研究 Agent。普通 RAG 通常一次检索后生成简短答案，DeepResearch 要先规划研究路径，再多轮搜索和阅读，并把证据写入外部笔记，最后综合成可追溯报告。我重点做了三个控制：第一是搜索预算，避免 Agent 无止境搜索；第二是引用约束，每个关键结论必须绑定来源；第三是 Reviewer 节点，专门检查引用覆盖、时间有效性和结论风险。
常见追问与回答
Q：DeepResearch 为什么需要外部笔记或 Evidence Store？ A：长程研究会产生大量中间材料，直接塞进上下文会爆。外部笔记保存结构化证据、来源、冲突点和摘要，生成阶段按需取回，比把所有网页拼进 prompt 更稳定，也便于审计。
Q：如何判断何时停止搜索？ A：不能只靠模型“感觉够了”。要结合预算和证据覆盖：子问题是否都有至少 N 个可信来源、关键结论是否有交叉验证、冲突事实是否已解释、搜索轮次和成本是否达到上限。满足覆盖或达到预算就停止，并在报告里写明局限。
Q：怎么防止搜索结果带偏？ A：来源分级、时间过滤、多来源交叉验证、冲突事实显式呈现。高风险领域不让模型直接给最终决策，只生成初稿和证据列表，由专家复核。
README 亮点
- 放一份完整研究报告样例，带引用编号和来源列表。
- 展示 LangGraph 状态图：plan、search、read、reflect、write、review。
- 给出成本看板：搜索轮次、读取页面数、token、耗时、引用覆盖率。
- 展示一个 bad case：过时来源导致结论错误，以及如何通过时间过滤修复。
项目六：电商订单处理 Copilot
适合 Agent 工程、业务系统集成、全栈、后端和企业 Copilot 岗位。
业务场景
电商客服和运营每天处理订单改地址、退换货、发票、物流异常、库存查询、赔付和工单流转。传统系统需要人工在 OMS、WMS、TMS、客服系统之间切换，效率低且容易漏步骤。项目目标是做一个订单处理 Copilot：用户用自然语言描述问题，Agent 自动识别任务、提取参数、调用业务 API、解释结果，并在高风险操作前请求人工确认。
系统架构
客服输入 / 用户问题
-> 意图识别：查询、修改、退款、投诉、发票、物流
-> 参数抽取：订单号、用户ID、商品、金额、原因
-> 工具选择：OMS / WMS / TMS / 工单 / 支付 / 发票
-> 权限和风险校验：角色、金额、状态、二次确认
-> 工具执行：只读查询或受控写操作
-> 结果解释：自然语言答复 + 下一步建议
-> 审计日志：调用参数、执行结果、操作者、Trace核心模块
- 任务规划：把复杂目标拆成可执行步骤，例如“查订单状态 -> 判断是否可改地址 -> 请求确认 -> 调用修改地址 API”。
- 工具 Schema：每个 API 都有参数类型、枚举、必填字段、幂等键和错误码说明。
- 参数校验：模型只负责抽取候选参数，后端负责订单状态、金额、用户权限和业务规则校验。
- 异常分支：库存不足、物流已出库、订单已退款、支付状态异常时，不强行执行，而是给出可选处理方案。
- 人工确认：退款、改地址、赔付、取消订单等写操作必须展示影响并二次确认。
- 审计与回滚：所有写操作记录幂等键、操作者、工具版本和前后状态，必要时能补偿。
面试讲法
我把订单 Copilot 设计成“模型生成意图，执行器保证正确”。模型负责理解客服自然语言、选择工具、抽取参数；真正执行前，后端会做 Schema、权限、订单状态和风控校验。这样既能利用模型的语言理解能力，又不会让模型绕过业务规则。上线时我重点关注工具调用成功率、参数一次通过率、转人工率和单次处理耗时。
常见追问与回答
Q：为什么订单场景不能做完全自主 Agent？ A：因为它有大量写操作和资金风险。查询类可以自动执行，修改地址、退款、赔付等动作必须有人审或二次确认。生产 Agent 的价值不是完全无人，而是减少查询和准备工作，把高风险决策留给人。
Q：工具参数错怎么办？ A：先用 JSON Schema 和枚举约束参数，再由后端做业务校验。缺字段就追问用户，字段冲突就拒绝执行并解释原因。失败信息要结构化返回给模型，让它能决定重试、改问用户还是转人工。
Q：如何评估订单 Copilot？ A：任务成功率、工具参数准确率、一次解决率、平均处理时长、转人工率、误执行率、审计日志完整率。写操作场景误执行率必须接近 0，宁可多转人工。
README 亮点
- 提供 5 条订单流程 Demo：查物流、改地址、退款、开发票、创建投诉工单。
- 展示工具调用 Trace 和二次确认弹窗。
- 给出异常分支表：什么情况自动处理，什么情况追问，什么情况转人工。
- 放一组优化数据：平均处理时长下降、参数一次通过率提升、转人工率变化。
项目七：企业 HR 智能体平台
适合 Dify、RAG、企业应用、全栈、低代码工作流和 AI 产品工程岗位。
业务场景
HR 场景文档多、流程杂、更新频繁，例如招聘制度、假勤规则、薪酬福利、培训材料、员工手册、绩效流程和面试安排。项目目标是先用 Dify 快速搭建 HR 知识库和工作流 PoC，验证高频问答、简历筛选、面试安排和员工自助服务，再把核心链路迁移到 FastAPI/Spring AI + PostgreSQL/pgvector 的工程化平台。
系统架构
Dify PoC：Chatflow / Knowledge / Tool / Workflow
-> 验证问题集：制度问答、JD 生成、简历分析、面试安排
-> 生产迁移：后端服务、权限、评测、日志、成本看板
-> RAG：HR 文档解析、权限标签、BM25 + 向量检索
-> Workflow：候选人筛选、面试邀约、审批提醒
-> 管理台：知识库更新、Prompt 版本、bad case 回流核心模块
- Dify 快速验证：业务方能直接维护 Prompt、知识库和流程，快速确认用户是否真的使用。
- 权限模型：员工、HRBP、招聘负责人、部门主管看到的知识和工具不同，检索前必须做 ACL 过滤。
- HR RAG：制度文档按标题层级和生效时间切分，回答必须引用制度来源和版本。
- 智能工作流：JD 生成、简历筛选、面试邀约、培训计划生成等流程适合用 Workflow 编排。
- PoC 迁移：Prompt、知识库配置、工具节点、运行日志、bad case 都要沉淀成工程资产。
- 效果评估：制度问答准确率、引用准确率、HR 人工节省时长、转人工率、员工满意度。
面试讲法
这个项目我会强调“低代码验证价值，代码化承接核心链路”。Dify 适合让 HR 快速参与配置和验证，但生产上要补权限、评测、版本、监控和成本。比如制度问答 PoC 通过后，我会把知识库切分策略、权限标签和 golden set 固化到后端，把复杂审批和敏感工具迁移到可测试的服务里，Dify 继续作为业务运营配置层。
常见追问与回答
Q：Dify 画布复杂后怎么治理？ A：先限制低代码画布只承载 PoC 和轻量流程；复杂状态机、强权限、长任务和写操作迁到代码服务。对保留在 Dify 的部分，要做版本管理、评估集、发布审批和成本看板。
Q：HR 知识库如何处理版本冲突？ A：文档入库时保存生效时间、废止时间、部门、适用地区和版本号。检索时按用户身份和当前时间过滤；回答里引用具体制度版本。旧制度不直接删除，而是标记失效，便于审计。
Q：简历筛选怎么避免歧视和合规风险？ A：只根据岗位相关能力和明确要求打分，避免使用性别、年龄、婚育等敏感属性。模型输出只作为辅助建议，保留评分依据和人工复核入口，并定期抽查偏差。
README 亮点
- 展示 Dify PoC 画布和迁移后的后端架构对比。
- 放制度问答、JD 生成、简历分析、面试安排四类 Demo。
- 给出权限示例：普通员工与 HRBP 同问同答的引用差异。
- 放评测表：引用准确率、拒答正确率、转人工率、节省工时。
项目八：领域模型微调与部署闭环
适合模型微调、MaaS、推理部署、AI Infra 和企业专属模型岗位。
业务场景
企业已经有 RAG 或 Agent 应用，但模型在特定领域表达、格式遵循、工具参数生成、客服话术或小模型成本上仍然不够好。项目目标是建立一个“数据收集 -> SFT/LoRA 微调 -> 评测 -> 部署 -> 监控 -> bad case 回流”的闭环，形成领域专属模型或轻量适配器。
系统架构
线上 bad case / 人工标注 / 业务语料
-> 数据清洗：去重、脱敏、质量过滤、格式转换
-> 训练：SFT / LoRA / QLoRA / DPO
-> 评测：任务准确率、格式遵循、拒答、安全、成本
-> 合并与导出：Adapter / Merge / Quantization
-> 部署：vLLM / SGLang / Ollama / MaaS
-> 监控：TTFT、TPOT、GPU、错误率、效果抽样核心模块
- 数据工程：自由文本转指令数据，清洗重复、脏数据、隐私信息和低质量样本。
- 训练策略：小数据先 LoRA，大显存不足用 QLoRA；只调格式和风格时控制训练轮次，避免灾难性遗忘。
- 偏好优化：有成对偏好数据时用 DPO/RLHF 类方法优化回答偏好和拒答边界。
- 评测体系：通用能力、领域任务、格式遵循、安全拒答、RAG 忠实度分别评估。
- 部署服务：选择 vLLM/SGLang/Ollama/云 MaaS，关注并发、显存、量化、上下文长度和成本。
- 回流闭环：线上 bad case 标注后进入下一轮训练或 Prompt/RAG 优化，不把所有问题都甩给微调。
面试讲法
我不会把微调当成万能方案。先判断问题属于知识缺失、格式不稳、风格不符还是工具参数能力不足。知识缺失优先 RAG，格式不稳优先 Schema 和重试；只有任务稳定、数据可积累、评测能证明收益时才做 LoRA/QLoRA。微调上线后还要看 TTFT、TPOT、成本、安全拒答和线上抽样质量，否则只是训练出了一个不可运营的模型文件。
常见追问与回答
Q：LoRA 和 QLoRA 怎么选？ A：LoRA 训练更直接，显存要求更高；QLoRA 通过量化基座降低显存占用，适合单卡或资源有限场景。选择时看显存、模型大小、训练速度、精度损失和部署格式。
Q：怎么防止微调过拟合？ A：控制数据质量和重复率，保留验证集，限制 epoch，监控训练/验证损失和任务指标，加入通用能力评测。领域微调不应让模型丢失基础指令遵循和安全能力。
Q：微调和 RAG 如何组合？ A：RAG 提供动态事实和可溯源证据，微调提升表达风格、格式遵循和任务策略。生产里常见组合是：RAG 负责“知道什么”，微调负责“怎么稳定完成任务”。
README 亮点
- 放数据样例：清洗前、清洗后、训练格式。
- 展示训练配置：base model、LoRA rank、学习率、epoch、显存占用。
- 给出评测对比：基座、Prompt、RAG、微调模型的指标表。
- 展示部署指标：TTFT、TPOT、吞吐、GPU 显存、单次请求成本。
通用工程亮点（任何项目都能讲）
无论哪个项目，这些工程化细节都能体现深度（详见 LLM 应用开发实战）：
- 流式输出：SSE / Streaming HTTP 改善体感，注意流式下的错误处理、内容审核和 token 统计。
- 结构化输出：用 JSON Schema / Structured Output 保证模型输出可被程序消费。
- 成本控制：模型分级路由、语义缓存、Prompt 精简、上下文压缩、限制输出长度。
- 可观测性：链路追踪、prompt 版本、检索命中、工具调用、token、延迟和错误监控。
- 安全合规：Prompt 注入防护、内容审核、PII 脱敏、最小权限、审计日志。
- 评估闭环：离线评测集 + 在线反馈 + A/B，对检索、生成、工具调用分别度量。
高频追问
Q：项目里为什么用 RAG 而不是微调？ A：知识频繁更新、需要引用溯源、涉及私有事实型知识时优先 RAG；微调更适合稳定风格、格式和固定任务能力。生产里可以组合：RAG 提供事实，微调改善表达和任务遵循。
Q：Agent 项目最容易翻车在哪里？ A：最常见是工具权限失控、循环调用、错误中间结果继续传递、成本失控。所以要有限步、超时、工具白名单、人工确认、Trace 和评估集。
Q：怎么说明你真的做过，而不是包装概念？ A：讲清一个具体问题的优化过程，例如「召回不准时如何定位」「工具参数错时怎么约束」「SSE 流式下如何统计 token」「某次成本从多少降到多少」。细节比名词更有说服力。
Q：README 怎么写才像作品集？ A：至少包括架构图、快速启动、Demo 截图、核心流程 Trace、评估指标、成本数据、安全设计和常见问题。面试官能 3 分钟看懂，才算作品集。