大模型RAG项目怎么写进简历？把知识库Demo改成可面试作品

“基于大模型和向量数据库实现知识库问答。”这句话可以是真实的，但它几乎没有说明你解决过什么问题。

如果项目只有上传PDF、输入问题、返回回答，面试官很难判断你的独立工作。更值得改造的不是界面，而是评价、证据链和错误定位。

下面以“公开技术文档助手”为练习场景。所有结果都应来自你自己测试，不能套用教程里的指标。

第一步：固定资料范围和版本

写清资料来源、许可或可用范围、采集日期和版本，保留文档与片段编号。更新资料后需要明确哪些索引重建，旧引用是否仍可追溯。

如果做多用户资料库，身份和租户范围由服务端提供，在检索阶段控制访问。不能先把所有片段交给模型，再要求它“只回答当前用户的内容”。

第二步：先有评价集，再调参数

评价集至少覆盖直接事实、跨段整合、术语变化、无答案和版本冲突。每个问题记录可接受答案、支撑资料和判定规则。规模从自己能认真核验的小集合开始，不要追求漂亮数量。

用于调参的开发集与最终检验集应区分，避免反复看同一批题后，把记住样本当成泛化能力。若测试存在人工判断，也要记录判定口径。

第三步：把检索和生成拆开看

先检查相关证据有没有进入候选结果，再检查最终答案是否忠于证据。

不能把“检索到相似文本”直接写成“回答正确”。两者的测量对象不一样。

第四步：只做有依据的改进

保留一个简单基线，再分别尝试切分调整、关键词与向量混合检索、重排或查询改写。一次尽量只改变一个主要因素，记录改善、退化、耗时和开销。

召回指标也要定义。例如Recall@k可以按标注的相关片段覆盖比例计算，但片段标签是否完整会影响结论；如果采用“前k条是否命中任一支撑证据”，应单独写清命中率口径，别混用名称。

RAG可以模块化构建，组件存在本身不代表效果已经验证。（参考：Spring AI：Retrieval Augmented Generation；核对日期：2026-10-15。）

第五步：按证据写简历

下面是描述模板，不是可直接冒领的经历：

构建公开技术文档RAG助手，负责文档解析、版本标识、检索与引用接口；整理评价集，分开分析证据召回和答案忠实性；对比基础检索与改进方案，记录质量、耗时及失败样本，支持资料外问题拒答。

如果没有完成某项，就删掉。若有真实指标，补上样本、模型配置、测试环境与判定口径，允许面试官复核。没有真实用户，项目应写个人实践，不写生产落地。

最后准备三次演示

一条正常问题，展示证据如何进入答案；一条失败问题，展示如何定位；一条资料更新，展示版本和引用如何处理。成功、失败和变化，三者一起比单段成功录屏更有说服力。

你可以在评论区写一个项目里答错的问题，先判断它属于解析、检索、生成还是引用。关注这个系列，可以从这份RAG作品继续扩展受控工具调用，而不是急着把它改名成多Agent平台。