京东 Agent开发 暑期一面

1. 自我介绍

2. 介绍一下 AI 智能体的 workflow，以及 RAG 知识库是怎么设计的

智能体 workflow 一般不是一次模型调用，而是多阶段任务流。我会把它拆成意图识别、任务规划、工具选择、检索增强、结果生成、校验和记忆更新几个阶段。比如运营人员问一个商品问题，系统先判断是选品分析、广告诊断、库存预警还是内容优化，再决定调用商品库、广告系统、向量知识库或规则引擎。

RAG 知识库设计上会分离结构化数据和非结构化文档。结构化数据比如商品指标、广告 ROI、库存周转用 MySQL、ClickHouse 或 ES 查询；非结构化内容比如运营 SOP、平台规则、历史案例、达人脚本会做切分、embedding、向量索引和元数据过滤。检索时不能只靠相似度，还要结合租户、类目、时间、权限、文档类型做过滤，否则召回结果会混乱。

用户问题
  -> 意图识别
  -> 任务规划
  -> 查询结构化指标 / 检索 RAG 文档 / 调用工具
  -> rerank
  -> prompt 组装
  -> 模型生成
  -> 证据校验
  -> 结果落库

3. 意图识别用的是哪个大模型，如何判断和测试意图识别结果的准确率

意图识别可以用通用大模型，也可以用小模型或规则加模型混合。项目里我更倾向于先用规则做高确定性识别，比如出现商品 ID、订单号、广告计划 ID 这类字段时先进入对应业务路由；模糊问题再交给大模型做分类。模型可以选 Qwen、DeepSeek、GPT 或 Claude 这类指令跟随能力强的模型，但不能只依赖模型自由发挥。

准确率测试要有标注集。每条样本包含用户原始问题、期望意图、必要槽位和是否需要调用工具。评估时不只看意图标签是否正确，还要看槽位抽取是否完整、是否误触发工具、是否该拒答却没有拒答。线上还要把低置信度、人工改判和用户追问样本回流到评测集。

def eval_intent(pred, gold):
    return {
        "intent_ok": pred["intent"] == gold["intent"],
        "slots_ok": all(pred["slots"].get(k) == v for k, v in gold["slots"].items()),
        "tool_route_ok": pred["need_tool"] == gold["need_tool"]
    }

case = {
    "query": "帮我看下 SKU123 最近广告 ROI 为什么掉了",
    "intent": "ad_diagnosis",
    "slots": {"sku": "SKU123"}
}

4. Redis 做语义向量相似度检索，内部用的是什么算法

Redis 做向量检索通常依赖 RediSearch 的向量索引能力，常见算法是 FLAT 和 HNSW。FLAT 是暴力精确检索，会计算查询向量和所有候选向量的距离，召回准确但数据量大时性能差。HNSW 是分层可导航小世界图，通过图结构近似搜索近邻，查询速度快，适合大规模向量召回，但它是 ANN 近似检索，需要调参数平衡召回率和延迟。

相似度距离一般可以选 cosine、L2 或 inner product。文本语义检索里常用 cosine，但前提是 embedding 模型输出和距离函数匹配。工程上还要关注维度、索引构建耗时、内存占用、topK、元数据过滤和向量版本。向量检索不是只存一个 embedding，通常还要存文档 ID、租户、类目、权限、更新时间等字段。

FT.CREATE rag_idx ON HASH PREFIX 1 doc:
SCHEMA
  tenant TAG
  category TAG
  content TEXT
  embedding VECTOR HNSW 6
    TYPE FLOAT32
    DIM 768
    DISTANCE_METRIC COSINE

# 查询时一般是：元数据过滤 + KNN 向量检索
query = "*=>[KNN 5 @embedding $vec AS score]"

5. 在使用 RAG 的过程中有没有出现大模型幻觉，如何设计兜底方案

出现过。常见情况是检索结果不相关、检索结果缺失、文档过期、prompt 里证据太多导致模型混淆，或者模型把相似案例当成当前事实。RAG 只能降低幻觉，不能消灭幻觉，因为最终生成仍然是概率模型。

兜底方案要从检索和生成两侧做。检索侧设置相似度阈值、元数据过滤、rerank 和文档时效校验；生成侧要求模型必须基于证据回答，没有证据就明确说无法判断。对于高风险问题，要返回引用来源、证据片段和置信度，并允许转人工。更重要的是把“未检索到证据”和“证据支持结论”区分开，不能让模型拿空上下文硬编。

{
  "answer": "当前无法判断广告 ROI 下降的唯一原因",
  "confidence": 0.42,
  "evidence": [
    "最近 7 天广告点击成本上涨 18%",
    "竞品均价下降 12%"
  ],
  "fallback": "建议补充转化漏斗和库存数据后重新诊断"
}

6. JMeter 压测的具体参数是怎么设置的

JMeter 压测不会只设置线程数。一般会先明确目标：是测接口吞吐、P99 延迟、长连接稳定性，还是测模型调用链路的限流能力。常用参数包括线程数、Ramp-Up 时间、循环次数、持续时间、请求超时、连接超时、吞吐量控制器、断言和结果采样。

比如测 Agent 诊断接口，我会把线程数从 50、100、200 逐步加压，Ramp-Up 设置成 60 到 180 秒，避免瞬时打爆。SSE 或长耗时接口要特别关注连接保持时间、服务端活跃连接数和网关超时。压测结果看平均值没有意义，重点看 P95、P99、错误率、线程池队列、数据库连接池、Redis 延迟和模型 API 限流。

Thread Group:
  Number of Threads: 200
  Ramp-Up Period: 120s
  Duration: 20min

HTTP Request:
  Connect Timeout: 3000ms
  Response Timeout: 60000ms

Assertions:
  响应码 = 200
  JSON 字段 status != FAILED

Metrics:
  QPS / P95 / P99 / Error Rate / Active Threads

7. Redis 是单线程的，为什么它还能支持高并发

Redis 的核心命令执行主要是单线程，但它基于内存操作，数据结构实现高效，再加上 IO 多路复用，可以用一个线程处理大量连接事件。单线程避免了复杂锁竞争，命令执行路径短，所以在纯内存读写场景下吞吐很高。

不过“Redis 单线程”不是绝对说法。新版本 Redis 在网络 IO、持久化、异步释放、集群同步等方面会使用多线程或后台线程。真正影响 Redis 高并发能力的不是线程数，而是命令是否会阻塞事件循环。比如大 key、慢 Lua、全量扫描、复杂集合运算和持久化抖动都会让 Redis 延迟飙升。

8. 在实际业务场景中，你怎么判断什么时候需要加缓存，为什么不能只用 MySQL

加缓存通常是因为访问频率高、读多写少、计算代价高、数据允许短暂不一致，或者下游承载不了高并发。比如商品基础信息、类目规则、运营 SOP、用户短期会话、Agent 任务状态和热点榜单，都适合缓存。MySQL 是权威事实源，但它不适合承接所有高频读和临时状态。

不能只用 MySQL 的原因是 MySQL 擅长事务和持久化，不擅长高频低延迟的热点读、分布式限流、临时会话状态和短期幂等标记。如果所有请求都查 MySQL，热点 SKU 或热门活动期间很容易把连接池打满。缓存设计要同时考虑过期时间、穿透、击穿、雪崩、一致性和降级。

public ProductInfo getProduct(String sku) {
    String key = "product:" + sku;
    ProductInfo cached = redis.get(key, ProductInfo.class);
    if (cached != null)