知识点标签

系统设计面试题解析第 2 页

系统设计相关面试题解析,按真实面经题目沉淀核心机制、易错点和面试官追问。

99 道题 7 个岗位 17 个公司

系统设计相关面试题第 2 页

RAG 为什么要引入父子索引,如何兼顾小粒度召回和大粒度上下文回填?

这题考的是 RAG 检索粒度设计:小 chunk 更容易被向量或关键词召回命中,但单独放进上下文时可能缺少标题、章节、定义、前提和表格上下文;父子索引用子块做高精度召回,用父文档或父章节做证据回填,从而兼顾召回命中率、答案可读性和上下文预算。

生产级 RAG 的数据解析与入库流水线如何设计,如何处理 PDF、DOCX、表格、图片和多格式文档?

生产级 RAG 的数据解析与入库流水线应从文件接入、格式识别、内容解析、结构保留、规范化切分、embedding、索引落库、权限和质量监控全链路设计。PDF、DOCX、表格、图片、Markdown、TXT 和富文本的解析策略不同:PDF 要区分数字文本和扫描件,DOCX 要保留标题层级和表格,表格要理解 sheet、表头和单元格关系,图片要 OCR 或生成视觉描述,多格式文档要保留统一的 document、section、chunk 和 asset 元数据。入库侧要支持幂等、版本、增量更新、失败重试、死信队列、ACL 过滤、向量库和关键词索引协同,以及可回溯的解析证据。

ReAct 的思考-行动-观察循环如何驱动 Agent 工具调用,和普通 CoT 有什么区别?

这题考的是候选人是否理解 ReAct 把模型推理和外部行动交织起来:模型不是一次性输出答案,而是在思考、选择工具、观察结果、继续推理的闭环中逐步完成任务;它和普通 CoT 的关键区别是能通过工具调用改变外部状态并用真实观察修正推理。

RAG 中既然向量检索已经计算相似度,为什么还需要 Cross-Encoder 重排?

这道题考察 RAG 检索链路中双塔向量召回和 Cross-Encoder 重排的职责边界。好的回答要说明向量检索适合在大规模语料上做低成本粗召回,但它把 query 和文档分别编码,主要比较全局语义相似度,难以精细判断短语匹配、否定关系、字段约束、时效和答案可用性。Cross-Encoder 把 query 与候选片段一起输入模型,可以做 token 级交互和上下文相关判断,因此通常用于小候选集精排。回答还应覆盖成本、延迟、候选规模、失败模式、评估指标和何时不需要重排。

向量数据库检索到语义相关但时间过久的历史信息时,RAG 系统应如何判断能否使用?

这道题考察 RAG 系统面对“语义相关但时间过久”的向量检索结果时,如何把相关性判断升级为证据可用性判断。回答要说明不能只看 embedding 分数,而要结合问题的时效敏感度、文档时间戳、版本、生效范围、来源权威性、与新证据的冲突情况和业务风险来决定使用、降权、补检、拒答或提示不确定。好的方案还要覆盖元数据过滤、时间衰减、动态检索、冲突检测、评估指标和上线监控。

RAG 什么时候只用静态知识库,什么时候需要接入动态网页检索?

这道题考察 RAG 检索源选择和系统边界设计。回答要说明静态知识库适合权威、可治理、更新频率低或组织受控知识,优势是稳定、可审计、低延迟、低风险;动态网页检索适合新闻、政策、价格、版本、故障状态、市场信息等变化快且静态库无法覆盖的问题,优势是新鲜度和覆盖面。高质量回答应给出 query 路由、混合检索、来源可信度、成本延迟、安全合规、冲突处理、引用和评估方案,而不是简单说“静态不够就联网”。

VikingDB 这类向量数据库如何设计核心链路,向量写入、ANN 索引、元数据过滤和查询召回如何协同?

这道题考察对向量数据库核心链路的系统设计能力,而不是背某个产品未公开实现。回答要从写入、向量化、分片、持久化、ANN 索引构建、增量更新、元数据过滤、查询召回、重排和运维指标串起来,说明向量、原始文档、元数据和索引如何保持一致。关键是讲清近似召回与过滤条件的协同:先过滤、后过滤、混合过滤各有什么代价;写入与索引的实时性、删除更新、分布式扩展、一致性和评估指标如何设计。

如果项目要基于 Claude Code 这类现成 Agent 做领域适配,如何设计数据边界、工具接入、RAG、评测和监控?

这道题考察如何把现成 Coding Agent 或通用 Agent 平台做成某个业务域可用的工程系统。回答不能停留在“加提示词”或“接几个工具”,而要围绕数据边界、权限隔离、工具契约、领域知识 RAG、任务流程、评测集、灰度发布、监控和人工接管设计。重点是让通用 Agent 只在授权数据和明确工具能力内行动,用可回放、可评测、可审计的方式逐步扩大自主能力。

在现有 LangGraph Agent 上新增功能时,如何设计节点、边、state schema、工具注册和回归测试?

这题考的是把 Agent 功能扩展做成可维护的状态机工程,而不是在一个大 prompt 或一个大节点里继续堆逻辑。高质量回答应说明如何先界定新功能的触发条件和输出契约,再决定是否新增节点、边、state 字段和工具,并用可回放测试证明新增路径没有破坏原有 Agent 行为。

当 Agent 有 100 个 Tool 时,如何做工具分组、动态子集检索、schema 治理、监控和 meta-tool/Skill 收口?

这题考的是大规模工具接入后的 Agent 治理能力。100 个 Tool 不能简单全部塞进模型上下文,否则会带来选择混乱、token 成本、schema 冲突、误调用和监控不可解释。好的回答应从工具分类、检索式候选集、契约治理、调用观测和能力收口几层展开。

同题还出现在 1 个公司岗位

文本搜图场景如何设计图片搜索系统,让用户搜“小狗”时能召回包含小狗的图片?

文本搜图系统要让用户输入“小狗”时召回包含小狗的图片,核心不是只按文件名搜索,而是建立图片内容理解、文本语义表示、索引召回和排序评估的完整链路。图片侧需要离线或实时提取对象标签、检测框、caption、OCR、视觉向量和多模态向量;查询侧需要把文本解析成语义向量和关键词;召回侧结合倒排索引、向量检索和元数据过滤;排序侧再按语义匹配、对象置信度、图片质量和用户意图重排。

Agent 中 Function Call、MCP 和 Skill 的工具描述上下文占用有什么差异,如何降低 token 成本?

这道题考察对 Agent 工具接入方式和上下文成本的工程理解。好答案要区分 Function Call 是模型请求内的工具 schema,MCP 是客户端和外部工具服务器之间的协议,Skill 是把说明、脚本和资源按能力打包并按需加载的机制。回答不能简单说 MCP 一定比 Skill 大,而要说明上下文占用取决于客户端暴露了多少工具描述、schema 是否冗长、是否做动态路由和懒加载。高质量答案还应给出降低 token 成本的方法,包括工具分层、候选工具筛选、描述压缩、结果引用、prompt caching 和按任务加载。

开发 MCP 服务时,如何设计 resources/tools/prompts、输入输出 schema、权限和可观测性?

这道题考察的是 MCP 服务的能力建模和治理能力,而不是会不会写一个 HTTP endpoint。好答案要从 resources、tools、prompts 三类能力暴露开始,定义清晰的输入输出 schema、权限和错误语义,再补上发现机制、版本兼容、超时重试、可观测性、回放和审计,保证 Agent 能安全、稳定、可追踪地使用 MCP 服务。

MCP 接入多个测评工具时,如果不同工具对同一问题返回格式不统一,应该如何设计统一输出协议或适配层?

这题考 MCP 多工具输出治理。多个 MCP 工具返回格式不统一时,应在工具和 Agent Runtime 之间加适配层,统一 envelope、内容块、结构化数据、错误协议、元数据、版本和审计,而不是让模型解析各类私有格式。

Agent 开发框架通常由哪些核心组件组成,Planner、Memory、Tools、Executor 和 Evaluator 分别负责什么?

这题考察候选人是否能把 Agent 从“调用大模型的应用”拆成可工程化的运行系统。好的回答应说明 Planner 负责把目标拆成步骤,Memory 负责保留和检索上下文,Tools 负责连接外部能力,Executor 负责按计划执行并处理状态,Evaluator 负责判断结果质量和是否需要重试、修正或终止。重点不是背组件名,而是讲清楚组件之间的数据流、控制流、失败兜底和可观测性。

Agent Skill 如何用渐进式披露按需加载能力说明、执行步骤和工具细节?

这题考察 Agent Skill 的核心机制,以及如何通过渐进式披露降低上下文负担。Skill 不是简单工具函数,而是一组可被 Agent 发现、选择和执行的能力包,通常包含能力说明、适用条件、输入输出、执行步骤、工具依赖和失败处理。渐进式披露的关键是先暴露轻量索引和选择信号,只有命中时再加载详细说明、示例和执行细节。

多工具 Agent 如何设计工具选择与调用调度链路,并在超时、参数错误或工具失败时做 fallback?

这题考察多工具 Agent 的工程调度能力。好的回答不能停在“让模型选择工具”,而要说明工具注册、候选召回、参数生成、权限校验、执行编排、状态记录、错误分类和 fallback 策略。面试官重点看你是否能把不稳定的 LLM 工具调用变成可观测、可恢复、可降级的业务链路。

AI 服务中的多模型降级与熔断机制如何设计,怎样定义异常、状态流转和自动恢复条件?

这题考察 AI 服务后端的稳定性设计。多模型降级和熔断不是简单把模型 A 挂了切到模型 B,而要定义异常、统计窗口、状态机、路由策略、自动恢复和质量兜底。好的回答要覆盖可用性、质量、成本、延迟、限流、观测和安全边界。

Agent 工具服务为什么要独立部署并注册到 Nacos,而不是直接用 MCP 暴露工具?

这题考 Agent 工具服务的工程化部署边界:Nacos 解决服务发现和治理,MCP 解决模型侧工具协议,二者不是同一层能力,不能简单互相替代。回答时要强调在已有微服务治理体系下,Nacos 更适合管理真实工具服务的实例、健康、配置和流量,MCP 更适合统一工具契约、schema 和 Agent 侧调用方式。

大模型反欺诈项目从开发、测试到部署应如何设计流程,Agent 框架选型需要关注哪些工程约束?

这题考大模型反欺诈项目的端到端工程化能力,不是只问“用了哪个 Agent 框架”。高质量回答要从业务边界、数据合规、Agent 工具链、离线评测、测试门禁、灰度部署、监控回流和框架选型约束讲清楚,体现反欺诈场景对准确性、可解释性、安全和稳定性的要求。

MCP 在 Agent 工具接入中解决什么问题,适合哪些场景,又有哪些落地边界?

这题考 MCP 在 Agent 工具接入中的协议价值和工程边界。高质量回答要说明它解决的是 Agent 与外部工具、资源、提示模板之间的标准化连接问题,并能覆盖工具发现、resources/tools/prompts、schema、跨进程接入、权限、审计、超时、版本和服务治理。

对接多家国内大模型官方 API 时,如何设计统一调用网关来屏蔽接口差异?

这题考察的是多大模型供应商接入时的工程抽象能力,不是简单写几个 if else 适配接口。好的统一调用网关要把业务层看到的协议收敛成稳定的内部模型契约,同时把供应商差异隔离在 adapter 层:消息格式、模型名、参数范围、流式协议、错误码、限流、鉴权、计费、上下文长度、工具调用、JSON 输出能力都不能泄漏给上层。架构上通常分为统一 API、路由与策略、provider adapter、可靠性治理、观测与审计、配置和灰度几个部分。回答要强调边界:网关不是只做转发,而是承担能力抽象、故障隔离、降级切换、成本治理和可观测性;但也不能把所有模型能力抹平成最低公约数,否则会损失模型特性。因此设计上要有基础统一契约和可扩展 capability 描述,既屏蔽常见差异,又允许业务显式选择高级能力。

用 LangChain 编排 AI 工作流时,如何和原生调用、自研引擎做选型,并分析各自优缺点和瓶颈?

这题考察的是 AI 工作流编排的技术选型,而不是问 LangChain 好不好。高质量回答要先拆清楚业务复杂度:只是单轮模型调用、少量 prompt 链、RAG 检索增强、工具调用、长流程状态机、多 Agent 协作,还是需要可视化编排、回放、权限、灰度和审计。原生调用的优势是简单、可控、性能和依赖风险低,适合链路短、业务稳定、团队希望自己掌握协议的场景;LangChain 的优势是生态组件多、原型快、抽象现成,适合探索期和标准 RAG/Tool/Agent 流程,但瓶颈是抽象层厚、版本变化、调试复杂、性能和可观测性需要补强;自研引擎适合业务流程复杂、稳定性和治理要求高、需要平台化复用的场景,但成本高、周期长,容易重复造轮子。最终选型不是三选一的宗教问题,而是按阶段演进:原型期可以用框架提速,核心生产链路要收敛成自己的稳定接口和可观测执行模型。

AI/自动化 Agent 平台如何结合 Jenkins 调度执行、Linux 日志采集解析和配置规则治理,实现状态回传、参数校验,并从拉日志演进到自动排障?

这题考 AI/自动化 Agent 平台的工程落地能力,重点是 Jenkins 调度、Linux 多机日志采集、配置规则治理、状态回传、参数校验,以及从拉日志工具演进到自动诊断和受控排障的路线。

主流 Agent 框架如何选型,如何按 RAG 检索、有状态工作流、多 Agent 协作、工具/记忆/检索能力和自主性与可控性边界做取舍?

这题考 Agent 框架选型边界,而不是背框架名。好的回答应按业务需要拆分:RAG 检索优先看数据索引和检索评估,有状态工作流优先看可控状态机,多 Agent 协作优先看角色协议和收敛性,工具、记忆、检索抽象要看边界清晰度,最终在 Agent 自主性和工程可控性之间取舍。