阿里云 AI应用开发一面

1. 做一下自我介绍

2. 你对网络安全方向怎么看，为什么 AI 应用在这个方向上既有价值又有风险

网络安全很适合和大模型结合，因为它天然就是高噪声、多源数据、强依赖经验判断的场景。告警研判、攻击链还原、漏洞摘要、规则解释、工单辅助这些任务都能显著提效。但安全场景比普通问答更敏感，问题不只是答得快不快，而是结论能不能被验证、引用是不是准确、有没有被 prompt injection 或恶意样本绕偏。安全方向里的 AI 应用，最终拼的不是模型会不会说，而是证据链是否闭环、输出是否可审计、权限边界是否足够严。

3. 介绍一个你做的这个项目，重点讲架构和你负责的部分

4. 为什么要用 RAG，而不是直接让模型回答安全分析问题

因为安全问题大多数都不是纯通识问题，而是强依赖私有知识、实时数据和组织内规则。直接问模型，它可能知道漏洞原理，但不知道你们内部资产分组、告警模板、历史处置策略和当前环境上下文。RAG 的意义不只是补知识，更重要的是把回答锚定到可引用的证据上，让输出更像“基于资料的分析”而不是“凭记忆生成”。尤其在安全场景里，没有证据来源的答案很难被信任，也很难进入生产流程。

5. RAG 的效果你怎么评估，不能只说看用户反馈

真正可落地的评估不能只看主观感受，要拆成几个层次看。先看召回层，是否把关键证据找回来；再看重排层，关键证据是否排进前几位；最后看生成层，答案是否准确引用、是否遗漏关键风险、是否凭空扩写。安全场景里我更看重 evidence coverage 和 citation accuracy，也就是该引用的证据有没有进答案、引用有没有指错。再往工程上走，还要补 latency、token cost、tool success rate 和 bad case 归因，不然你根本不知道问题出在召回、编排还是模型本身。

6. 幻觉问题你一般怎么处理，尤其是安全场景下的高风险幻觉

安全场景里最危险的不是“答得模糊”，而是“答得很确定但证据是错的”。所以处理幻觉不能只靠 prompt 里写一句“不要编造”。更稳的做法是让模型只在给定证据范围内回答，没有证据就显式拒答；同时把结论和证据绑定，要求每条结论都能回指到检索片段或工具结果。对于高风险输出，比如漏洞利用建议、封禁动作、处置策略，通常还会加规则校验和人工确认，不让模型直接成为最终执行者。

{
  "answer": "该告警更可能与横向移动有关",
  "evidence": [
    {"source": "alert_log_12", "span": "同一账号在5分钟内跨3台主机登录"},
    {"source": "asset_profile_3", "span": "主机位于同一业务网段"}
  ],
  "confidence": 0.81
}

7. 多智能体项目的目的是什么，什么时候真的需要多智能体

很多项目其实并不需要多智能体，单 Agent 加工具已经够了。真正需要多智能体，通常是任务具备明显的角色分工，比如一个负责规划，一个负责检索，一个负责执行，一个负责审计，彼此之间有不同的上下文和约束。安全分析里，多智能体的价值更多体现在把复杂任务拆成可控子流程，例如“告警理解—证据拉取—风险归因—处置建议—结果复核”。如果只是为了显得高级，把一个简单问答硬拆成多个 Agent，通常只会增加成本和不稳定性。

8. 你做完多智能体系统之后，最大的体会是什么

最大的体会通常不是“模型很强”，而是系统边界必须比单 Agent 更严格。多智能体一旦没有明确状态机，很容易互相放大错误，一个猜错，后面的全跟着偏。第二个体会是通信协议比角色设定更重要，如果 Agent 之间传的不是结构化中间结果，而是自然语言大段描述，链路会越来越不稳定。第三个问题是观测性，不把每一步计划、调用、输入输出留痕，线上根本没法排查。

9. 前端为什么不直接做一个普通聊天页，而是要选更适合流式交互的方案

AI 应用前端不只是显示文本，它承担的是长连接状态管理、工具执行反馈、流式输出、消息回溯和中断恢复。普通表单式页面很难承载这类交互，所以一般会选择更适合流式渲染的方案，比如 SSE 或 WebSocket 配合 React。这样做的价值在于用户能看到模型思考和工具执行进度，不用等一个长请求完全结束才有反馈。尤其在安全场景中，检索和分析过程往往比较长，前端如果不能把中间状态展示出来，体验会很差。

const evtSource = new EventSource('/api/stream');
evtSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  renderChunk(data.delta);
};