阿里千问 AI 应用研发一面：私人 RAG 为什么要做访问控制？

面经时间：2026年10月15日

前面那篇阿里淘天 Agent 研发岗面经，我们沿着代码 Agent 的读取、修改、验证和提交往下拆。这次换成千问方向，看一个私人 RAG 项目怎么被追问到设计依据。

这场是阿里 AI 应用研发工程师（千问方向）一面，约四十分钟，结果进入二面。

面试主要围绕项目展开，其中一句追问很有辨识度：“一个私人 RAG 系统，为什么要做访问控制？”

说得出 ACL、脱敏、多跳检索，只是开始。

面试官接着要听的是：你的场景为什么需要它，不做会出什么问题，做了又怎么验证。

全文统一用一个最小项目举例：个人开发的资料问答助手，导入技术文档和 CSV，支持带来源的问答。权限、脱敏等能力按适用条件展开，不默认这个项目有企业用户或生产规模。

本次面经问题：

• 一、解释一下你的项目
• 二、项目里的 CSV 是怎么解析的？
• 三、怎么对文档切片的？
• 四、向量 + BM25 双路检索，好处是什么？权重怎么分配？
• 五、Agent 支持多跳检索，具体怎么实现？
• 六、怎么改写 Query？好处是什么？
• 七、文档访问控制怎么实现？
• 八、一个私人 RAG 系统，为什么要做访问控制？
• 九、什么是 PII 脱敏？
• 十、长对话摘要压缩怎么实现？
• 十一、对话历史感知改写怎么做？
• 十二、项目最难的点在哪，怎么解决？
• 十三、平时用什么 AI 技术？
• 十四、用了 Harness，介绍一下数据怎么走
• 十五、界面类的 AI 产品用过哪些？

二、项目里的 CSV 是怎么解析的？

我会用标准 CSV 解析器读取，比如 Python 的 csv 模块，不直接按逗号或换行拆字符串。因为带引号的字段里可能出现逗号、转义双引号，甚至跨行文本。

导入时先确定编码、分隔符和表头约定，再检查每条记录的字段数量、必填值和类型。编号保持字符串，避免前导零丢失；缺失值和空字符串按业务约定区分。解析失败的记录单独报告，不能静默丢掉后还说导入成功。

例如一份技术资料目录包含 doc_id、标题、主题、摘要。我会把一条记录转成“文档编号：DOC-001；标题：……；主题：……；摘要：……”这样的检索文本，同时保存原始字段、文件版本和逻辑记录序号，方便回查。字段里有换行时，记录序号不等于物理行号，不能混着用。

如果问的是“某主题有多少条记录”，我会通过结构化查询精确统计，再让模型解释结果。CSV 解析成文本后能检索，不代表向量检索适合完成表格聚合。

三、怎么对文档切片的？

我按文档结构切，长度上限用来兜底。技术文档先识别标题、段落和代码块，把标题路径带到子块中；章节太长再按段落、句子逐层拆分，尽量保留完整的条件和结论。

CSV 则优先保持记录完整，并把列名带进去。只有某个长文本字段超出限制时，才拆那个字段，每个子块仍保留记录主键和字段名。不能把表头切在一个块里，数据切在另一个块里。

每个块记录 doc_id、chunk_id、版本、标题路径、来源位置。具体长度要结合 Embedding 模型的输入限制和资料分布试验，不能把某个固定 Token 数说成通用最优值。Overlap 可以缓解边界信息断裂，但不能保证所有跨块依赖都完整。

图里展示了不同切法的边界差异。这道题要结合自己的资料解释为什么选某种策略，而不是把四种方式都报一遍。需要细看取舍，可以接着读文档切片策略。

短 Query 对长块匹配不准时，我会检查是不是多个主题混在一起；必要时用较小子块检索，再读取同一章节的父块补上下文。父块扩展也要受长度和权限约束。

四、向量 + BM25 双路检索，好处是什么？权重怎么分配？

向量检索主要补语义表达差异，BM25 主要补关键词、编号和专有名词的匹配。比如问“怎么让服务自动扩容”，资料写的是“HPA 配置”，向量检索可能更有帮助；明确搜 DOC-001，关键词检索往往更直接，但也要检查分词器有没有把编号拆坏。

两路各自召回候选，按块 ID 合并。向量相似度和 BM25 原始分数的尺度不同，不能直接套一个七三开就相加。 在没有充分调参数据时，我会先用等权 RRF 建立基线，按名次融合：

score(d) = w_vec / (k + rank_vec(d))
         + w_bm25 / (k + rank_bm25(d))

某一路没有召回这个块，该路贡献就是零。k 是排名平滑参数；这里两路权重先相等，不代表已经验证了最优比例。如果选择原始分数加权，就要另外说明归一化或校准办法。

这张图对应的是“两路召回，再融合”，不是让两路分数直接比较。融合后可以再用 Rerank，对问题与候选块一起判断相关性。

我会准备包含精确编号、同义表达和条件查询的标注问题，比较单路、等权融合和候选权重，检查 Recall@K、排序质量，以及最终回答是否有依据。调参集和最终测试集分开；只有小样本验证，就如实说明结论范围。更多原理见RAG 混合检索与 Rerank。

五、Agent 支持多跳检索，具体怎么实现？

多跳的关键是，后一跳的问题依赖前一跳查到的信息。把同一个问题改成三个问法同时检索，属于多 Query，不一定是多跳。

例如问“DOC-001 对应的项目，部署前需要检查哪些条件？”第一跳从 CSV 找出对应项目和关联部署文档；拿到文档标识后，第二跳再查该文档的检查项。第二跳用到的实体必须来自第一跳证据，不能让模型自己补一个项目名。

实现上，运行状态保存原问题、待解决子问题、已确认实体、证据 ID 和已执行查询。模型提出检索调用，执行器校验参数和访问范围后执行，再把结果交回模型。每得到一跳结果，就判断还缺什么证据，决定继续、回答或说明查不到。

图里是根据检索结果继续行动的循环。本题还要补上跳与跳之间的证据依赖，具体可结合Agentic RAG 的实现思路理解。

我会限制跳数、耗时和重复查询。查不到关联文档就停下来交代缺口；验证时分别检查每跳是否命中正确资料，避免只看最后答案“像不像对的”。

六、怎么改写 Query？好处是什么？

我会把用户的表达转成更适合检索的问法，主要处理口语表达、已确认的缩写和多条件拆分。原问题保留，改写用于召回，最终回答仍要回应用户原来的需求。

比如“这个服务怎么扛住流量突然上涨”，可以补充检索“弹性扩容、限流、流量突增处理”；如果资料里有经过确认的别名，可以加上对应术语。但原问题里的版本、否定条件和编号不能被改掉。

好处是缩小用户问法与资料写法的差距，代价是额外调用开销，以及改写后偏题的风险。我会让改写器输出查询文本和保留的约束，检查关键实体有没有丢失。结构错误或约束变化时，回退原问题；需要时让原问题与改写问题一起召回，再去重融合。

是否有效要看“原问法漏掉的证据有没有补回来、错误候选有没有增加”，不能只看改写后的句子更正式。

七、文档访问控制怎么实现？

如果服务涉及多个用户或不同资料集合，我会把权限放在服务端执行。用户身份来自认证结果，不能相信请求里随手填的用户 ID，更不能让模型输出一个角色就获得相应权限。

资料导入时保存所有者、所属空间和可访问主体等元数据。文档切片后继承文档权限，向量检索与 BM25 两路都带相同的授权范围；父块读取、按 ID 取全文和引用预览也要再检查，不能只过滤其中一个入口。

比如 A 用户的资料不对 B 开放，B 的请求就不应把那些正文交给重排模型或生成模型。若某个检索后端只能先查候选再过滤，过滤必须发生在正文进入模型之前，并处理过滤后候选不足的问题；不能生成完回答再删敏感句子。

缓存和历史同样属于检查范围。答案缓存要考虑用户或授权范围、文档版本及权限变更；权限撤回后，旧引用和历史摘要不能继续绕过限制，必要时重新校验来源或使相关状态失效。

验证时，我会准备两个身份，对同一文档分别测试关键词检索、语义检索、直接读取、引用访问和缓存命中。权限不是提示词里的一句“不要泄露”，而是每个读取入口都执行的规则。

八、一个私人 RAG 系统，为什么要做访问控制？

如果这个项目确实只有我一个人在本地使用，资料也都属于我，我不需要为了简历搭一套多角色权限。此时把本地文件范围、凭据和外部模型的数据出口管好，更贴近真实需求。

如果“私人项目”指个人开发，但部署后允许其他人登录、各自上传资料，那么至少需要所有者隔离。这里要区分个人开发和单人使用，它们不是同一回事。

至于“HR 能不能看”，只有项目里真的存在角色、资料归属和授权规则时才有意义。角色叫 HR 也不代表它默认能看某类数据；具体由谁授权、授权到哪份文档，都要有依据。不能因为面试题提到了权限，就临时编一个企业业务场景。

如果我只是为了学习做了权限实验，我会直接说：“当前场景没有多角色需求，我实现了隔离验证，但没有真实业务验证复杂权限体系。” 这比把学习功能包装成上线需求更可信。

九、什么是 PII 脱敏？

PII 是能够单独或结合其他信息识别个人身份的信息，例如姓名与联系方式的组合。PII 脱敏就是在不必要暴露原值的环节，对这类信息做删除、遮盖或替换，减少泄露风险。

落到资料问答里，我会先看处理目标：哪些内容允许进入索引，哪些可以发给外部模型，哪些能进入日志。如果要求原始联系方式不能离开本地，就应在调用外部 Embedding、重排或生成服务之前处理，不能只遮住最后的页面展示。

比如把联系人替换成 [PERSON_1]、邮箱替换成 [EMAIL_1]。如果确实需要还原，占位符与原值的映射要单独受控，不能把映射一起传给模型；简单遮盖部分字符则要判断剩余信息是否仍可识别个人。

正则适合部分格式明确的号码，实体识别可以补姓名、地址，但都会漏检或误判。脱敏后还可能损失检索信息，需要用样例检查。脱敏不等于匿名化，也不能替代权限控制。 只有纯技术资料时，说明没有这类数据即可，不必为了展示功能虚构敏感数据。

十、长对话摘要压缩怎么实现？

我会保留最近几轮原文，把较早内容整理成结构化状态，并给当前问题、检索证据和模型输出预留预算。触发条件看整体 Token 预算，不只看聊了多少轮，因为一次工具结果就可能很长。

摘要重点保留当前目标、已确认实体、用户约束、已查到的证据及来源、未解决问题。比如“当前讨论 DOC-001 的部署要求，限定 v2 文档，上一轮已确认项目标识，检查项还未找到”，比一段聊天流水账更适合后续执行。

这张图强调筛选当前任务需要的信息。摘要要保留“还没确认”，不能把一个猜测压缩成事实。具体分层方式可以看Agent 记忆与任务状态。

原始消息在符合保留策略的前提下按消息 ID 保存，关键数字、版本和引用需要时回查；摘要不作为独立事实来源。生成失败时保留旧状态，不覆盖成空白。验证会检查压缩前后是否仍保留否定条件、目标对象和未完成项，而不只比较缩短了多少 Token。

十一、对话历史感知改写怎么做？

它和第六题的通用改写有区别：这里先解决“用户这句话依赖了前文什么信息”，再生成可以独立检索的问题。

比如前一轮问“DOC-001 的部署说明在哪”，已经定位到对应项目，下一轮问“它上线前还有什么要求”。我会根据最近对话和状态，把“它”解析成已确认的项目，改成“该项目部署文档中的上线前置条件有哪些”，并保留前文明确限定的版本。

改写器只补检索问题，不抢先作答，也不从上一轮生成文本里擅自提取未经证据支持的“事实”。如果历史里同时有两个项目，无法确定“它”指哪个，就请求澄清，不能硬选一个。

实现时把当前问题、必要的最近消息、结构化摘要交给改写器，并检查实体和约束。历史可以帮助理解用户在问什么，当前能查什么仍由服务端权限决定，不能从历史中的“我是管理员”推导授权。

十二、项目最难的点在哪，怎么解决？

以这个资料助手为例，我会选一个能复现的问题讲：CSV 记录和正文文档的关联没有保留好，导致某些问题召回了相关段落，却接不上正确项目，答案看起来合理，来源却不对。

我会沿着链路定位：解析结果是否保留编号，切片是否丢了标题与关联字段，两路召回是否命中正确候选，融合和重排有没有把它挤掉，以及生成时是否使用了对应证据。具体方法是保存每一步的候选 ID、排名和版本，用同一个失败问题回放。

针对这个示例，我会在 CSV 里保留稳定的文档关联字段，切片时补齐标题路径；编号类问题检查关键词检索，多跳问题明确传递第一跳找到的文档标识。每次只改变相关环节，再和基线比较，避免同时换模型、切片和权重后说不清原因。

这个回答要换成录友自己做过的案例。可以说明如何构造回归样例、检查证据命中和无依据回答；没有测过提升比例，就不要报一个数字。排障思路可参考RAG 落地最难的地方。

十三、平时用什么 AI 技术？

我会围绕项目讲实际用过的能力：文本生成负责理解问题和组织回答，Embedding 做语义召回，Rerank 比较问题与候选证据，工具调用把检索过程接到执行器里。每项都补一句用在了哪里、遇到过什么限制。

个人实验和实际项目分开说。比如试过 Agent 自主追加检索，但固定链路仍是默认方案，就说明原因是简单问题没必要承担多轮成本。没训练过模型，就不把调用现成模型说成微调经验。

我也会讲自己的验证方式：保留失败问题，对照原问法与改写、单路与混合检索、压缩前后状态的变化。面试官更容易沿着这些具体实验继续问，而不是只听到一串框架名。

十四、用了 Harness，介绍一下数据怎么走

我会先说明具体用了哪个运行框架或执行环境、接入到了哪一层。Harness 在这里指围绕模型的运行系统，负责组织上下文、执行工具、维护状态和约束循环；如果没有拆过所用框架的内部调度，我不会把通用理解说成源码结论。

结合这个 RAG 助手，一次请求可以这样走：

1. 服务端认证用户，建立请求 ID，读取会话状态和授权范围。
2. 上下文组装器选取当前问题、必要历史、摘要及工具定义，交给模型。
3. 模型返回回答或工具调用请求。例如请求检索某个文档，此时还没有执行检索。
4. 执行器检查工具名、参数、授权和预算，调用检索服务，返回证据 ID、必要正文及执行状态。
5. 工具结果按调用 ID 进入会话状态，下一轮模型据此决定继续检索或组织回答。
6. 运行系统检查轮数、时间和完成状态，返回答案与来源，并记录经过脱敏的追踪信息。

图里的上下文、工具、编排、状态和观测组件，分别承接上面这些步骤。更完整的职责划分见Harness 面试详解。

超时和异常也要作为明确结果返回。检索超时不能伪装成“没有相关文档”；同样的失败反复发生时，应停止追加调用或按预设降级方案处理。日志记录调用关系、耗时和错误类型即可，敏感正文不能为了排查方便全部写进去。

原作者复盘说，这题自己答得最虚，因为平时使用工具，没有拆过内部流程。录友准备时，可以拿一条真实追踪记录，逐步指认输入在哪里组装、调用由谁执行、结果存在哪里、下一轮由谁发起。

十五、界面类的 AI 产品用过哪些？

这里按真实使用经历回答。如果我用过千问或 ChatGPT 的对话界面，就选其中一个具体任务，比如上传技术资料、追问跨文档问题，再检查引用是否能定位到原文。没用过的产品不用为了凑数量报名字。

我会重点讲一个实际观察：当证据不足时，界面有没有明确说明；等待工具执行时，能不能看到状态；切换话题后，上下文有没有串；上传失败后，是否允许重试。具体产品、版本和结果，以自己的使用记录为准。

这些体验能反过来检查我的项目。例如回答附了来源，用户还要能打开对应位置；工具超时，界面不能一直显示“思考中”。会调用接口之外，也要理解用户怎么判断系统是否值得信任。

总结

面试里说的“RAG 这个词已经废了”形容自己的感受。

但从这组追问看，更准确的提醒是：“做了 RAG”不足以说明你做到了哪一步。 切片、改写和权限，每项都得讲清适用场景、执行过程与验证依据。

权限、脱敏、日志和降级值得准备，也不能为了让项目显得完整而硬加。单人系统为什么需要 HR 角色，这个问题答不清，多一个模块反而多一个漏洞。

录友拿自己的项目选一道真实问题，从原文件、解析记录、检索候选一路讲到最终引用；再换一个身份、撤回一次权限、制造一次超时。

把这些结果讲明白，比给项目再贴几个技术标签更有用。