高德大模型开发二面

1. 你做的 Agent 项目整体架构是什么？

答：一个比较完整的 Agent 架构一般包括四层：用户输入层、规划决策层、工具执行层、结果整合层。用户输入进来后，先做意图识别和上下文整理，再由大模型决定是直接回答、检索知识、还是调用工具。工具层可能包括搜索、数据库查询、知识库检索、接口调用、代码执行等。工具返回结果后，再交给模型做总结、归因和最终输出。如果是生产环境，还会多一层治理能力，比如权限校验、超时控制、重试、日志、观测、敏感内容拦截。Agent 和普通问答最大的区别，就是它不是单纯生成文本，而是“模型负责决策，外部系统负责拿真实信息，最后再由模型组织答案”。

2. Agent 为什么不等于工作流？

答：工作流更偏固定流程，步骤通常是提前设计好的，输入到了哪个节点、调用哪个工具、输出什么格式，都是相对确定的。Agent 更强调动态决策能力，模型会根据上下文自主判断下一步做什么，比如要不要调用工具、调用哪个工具、是否继续追问、是否终止任务。所以工作流更适合稳定、可预期、规则清晰的业务；Agent 更适合开放任务、多轮推理、路径不固定的场景。很多线上系统实际上是 Agent + Workflow 混合，也就是关键节点仍然用工作流兜底，而不是完全放任模型自由决策。

3. 你项目里的工具调用是怎么做的？怎么让模型更稳定地选对工具？

答：工具调用本质上是把外部能力包装成模型可理解的接口描述，然后让模型在合适的时候产出结构化调用参数。要让模型更稳定地选对工具，核心有三件事。第一是工具描述要写清楚，包括适用场景、输入参数、返回结果、禁用边界；第二是减少工具之间的语义重叠，不然模型容易选错；第三是加规则兜底，比如高风险操作必须走白名单校验。另外工具调用不能只看“调没调”，还要看“调得对不对”，所以线上通常会记录工具命中率、误调用率、漏调用率、参数错误率、超时率。如果工具很多，通常还会先做 tool routing，把候选工具范围先缩小，再交给模型判断。

tools = [
    {
        "name": "search_doc",
        "description": "查询内部知识库，适合问产品说明、配置规则、业务流程",
        "parameters": {
            "type": "object",
            "properties": {
                "query": {"type": "string"}
            },
            "required": ["query"]
        }
    }
]

4. 你怎么设计一个 RAG 系统？最容易出问题的是哪一层？

答：RAG 一般是文档接入、切片清洗、向量化、召回、重排、上下文拼接、生成回答这几步。最容易出问题的通常不是模型生成，而是前面的知识处理链路。比如文档切片切得太碎，会导致语义丢失；切得太大，会把噪声一起带进来。召回如果只靠向量检索，可能语义相近但事实不准；如果只靠关键词检索，又容易漏掉表达不同但语义一致的内容。所以线上一般会做混合召回，再接重排模型，把最相关的 chunk 放到前面。真正影响体验的往往是“检不到”和“检不准”，而不是模型不会写答案。

5. 你怎么处理 RAG 里的召回不准问题？

答：先看问题出在 query、embedding、切片，还是重排。如果用户问法和文档写法差异大，就先做 query rewrite；如果知识文档里字段化信息多，可以把标题、标签、来源、时间一起编码；如果 chunk 太乱，就重新设计切片策略。实际工程里常见做法是混合召回，也就是 BM25 + 向量召回，再接 reranker。另外还要做知识去重和版本控制，不然旧文档、新文档一起召回，模型会自己“猜哪个对”，这很容易引发幻觉。

6. LoRA 为什么适合企业里的大模型微调？

答：因为它成本低、迭代快、对底座侵入小。企业很多场景不是要重新训练一个通用模型，而是让模型快速适配某个行业、某类问答风格、某个具体任务。LoRA 只训练少量低秩参数，显存压力小，训练快，保存和切换也方便。同一个基座模型可以挂多个 LoRA 适配不同业务，这比每次都做全参微调现实得多。如果数据规模不大、资源有限、任务目标明确，LoRA 通常是比全量微调更合理的方案。^{^1^3}