字节、美团、B站 AI Coding 笔试五大题型拆解

轮次: 笔试
时间: 2026-09
来源: 牛客网

《面试题目》

实现一个简单的 RAG 检索增强生成系统，支持文档上传、向量化检索和智能问答
设计一个多 Agent 协作系统，能自动完成「调研 → 写报告 → 审核 → 发布」的完整流程
如何评估一个企业级 AI 问答系统的效果？请设计评估指标和测试集
给定一个用户意图识别任务，当前 Prompt 准确率为 85%，请优化到 95% 以上
设计一个支持 10 万并发用户的 AI 客服系统架构

《参考解析》

题型一：RAG 系统实现（出现频率最高）。这类题考的不是背 LangChain API，而是能不能把链路讲清楚并写成一个可扩展的类。完整链路是：文档解析 → 切分 → 向量化 → 入库 → 检索 → 重排 → 拼上下文 → 生成。切分上要能说出取舍：固定长度切分简单但会把语义切断，按标题/段落/代码块这类结构切分效果更好，通常再用 chunk_size=300~800、overlap=10%~20% 兜住边界；中文场景 embedding 一般选 bge-m3 或同类多语模型，向量做 L2 归一化后内积就等于余弦相似度。检索层写 similarity_search(question, k=3~8) 只是起点，能加分的是：加元数据过滤（按文档、时间、权限过滤）、混合 BM25 召回、cross-encoder 重排、以及拼 prompt 时明确要求「只依据上下文作答，无依据时回答不知道」来压幻觉。下面是一个自己写的最小实现：

class RagPipeline:
    def __init__(self, embedder, store, llm, chunk_size=500, overlap=80):
        self.embedder, self.store, self.llm = embedder, store, llm
        self.chunk_size, self.overlap = chunk_size, overlap

    def add_documents(self, docs):
        for d in docs:
            for i, chunk in enumerate(split_by_structure(d.text, self.chunk_size, self.overlap)):
                self.store.add(embedding=self.embedder.encode(chunk),
                               text=chunk, metadata={**d.meta, "seq": i})

    def query(self, question, k=5):
        hits = self.store.search(self.embedder.encode(question), k=k)
        context = "\n\n".join(f"[{i + 1}] {h.text}" for i, h in enumerate(hits))
        prompt = ("只根据下列资料回答，资料中没有的不要编，并标注引用编号。\n"
                  f"资料：\n{context}\n\n问题：{question}")
        return self.llm.generate(prompt), hits

面试官追问通常会落在「换一批文档要不要重跑全量」「怎么评估检索质量」「chunk 大小怎么定」上，准备时把增量入库（按文档 id 覆盖）和离线评估（见题型三）一起答出来。

题型二：Agent 工作流设计。四个角色的拆法只是表层，真正被考察的是状态机怎么定义、失败怎么收敛。可用的答法是：用 LangGraph 或 AutoGen 把流程建成有向图，节点是 Agent，边是「通过/打回」的条件跳转，共享一个显式的状态对象（研究结论、草稿、审核意见、发布记录），每个节点的输入输出都定义成 Pydantic/JSON Schema，禁止用自由文本在节点间传递。必须主动说出的工程约束有三条：一是最大迭代次数与超时，Reviewer 连续打回 N 次就升级给人工，防止两个 Agent 互相刷屏；二是幂等与可重放，发布这类有副作用的节点用唯一任务号去重，失败后从 checkpoint 恢复而不是从头跑；三是成本与可观测，每次调用记录 token、耗时、工具调用序列，否则线上出问题无法归因。审核环节还可以用「执行模型和裁判模型分开」降低同源偏差，但裁判模型不一定要换大模型，换 prompt 视角往往就够。

题型三：大模型评估指标设计。只答「准确率」是这道题的标准失分点。要分层作答：检索层看 Recall@k、MRR、nDCG，判断「该召回的资料有没有进来」；生成层看答案正确性（EM / F1 或人工 rubric 打分）、忠实度（答案是否被上下文支撑，即幻觉率）、拒答准确率（该说不知道时有没有说）；系统层看首 token 延迟、P95 延迟、单次 token 成本、并发吞吐；体验层看满意度、追问率与人工返工率。测试集要能说清来源与构成：从真实日志分层抽样做常见场景，人工构造边缘场景（空输入、超长输入、多轮指代、专业术语），再加对抗样本（错别字、越权提问、诱导编造、prompt 注入）。最后补一句落地机制——标注规范、双人标注算一致性、用人工标注校准 LLM-as-judge 的评分，这样才不是纸面指标。

题型四：Prompt 从 85% 优化到 95%。正确顺序是先诊断再改，而不是直接加一句「请仔细思考」。第一步做错误分析：把错例按混淆类目归类，看是类目定义模糊、样本不均衡，还是输出格式不稳定导致解析失败——很多「准确率低」其实是解析失败。第二步再上手段：把类别定义、判定优先级、多标签与「其他」类的处理写清楚；用 JSON Schema 或枚举强约束输出；few-shot 示例要覆盖易混类目，正负例都给，示例从训练集选、绝不从测试集抄；让模型先给判断依据再给标签（CoT），但只取最终标签字段；温度调低到 0~0.2；对少数难类目加规则关键词兜底或二次校验。第三步是验证：固定测试集跑前后对比，看混淆矩阵里到底哪一类涨了，避免总体涨了但关键类目掉点。要能顺口说出「如果 95% 还上不去，就该考虑微调或换模型，而不是继续堆 prompt」。

题型五：10 万并发的 AI 系统架构。先把「10 万并发」翻译成可估算的口径：并发不等于 QPS，按日活、峰值系数、平均会话轮次折算峰值 QPS，再按模型单实例吞吐（例如用 vLLM 连续批处理，7B 模型单卡每秒能出几百到上千 token）反推需要多少张卡，这一步算出来比画框图更能证明你不是在背八股。分层是：接入层（API 网关做鉴权、限流、灰度）、业务层（会话管理、意图识别与路由、编排）、模型层（LLM 网关统一收敛调用，规则引擎处理可规则化的意图）、数据层（Redis 会话与缓存、向量库做知识检索、MySQL 存业务数据）。真正的高并发手段是异步化与削峰：SSE 流式返回把感知延迟降到首 token，请求进有界队列按优先级调度，语义缓存命中相似问题直接返回，超载时按租户配额限流并降级到规则引擎或 FAQ，实在不行转异步工单。最后别漏监控告警：首 token 延迟、错误率、队列深度、token 消耗，以及模型不可用时的自动 fallback 开关。

备考建议。这五类题覆盖了绝大部分 AI Coding 笔试，准备方式不是背题而是各写一份可复用的骨架：一个 RAG 类、一个带角色和条件边的 Agent 状态机、一份指标与测试集设计模板、一份 JSON 输出的 prompt 模板、一张分层架构图。笔试时先跟面试官对齐接口与输入输出，再写核心逻辑，把边界条件（空输入、超长、无检索结果、模型超时）留出钩子，比闷头写全量代码更容易拿分。

《面试题目》

《参考解析》

相关面经