工程落地：部署、配置与架构

Q9可插拔 RAG、一键配置切换，是不是热更新？

参考答案

结论先行：属于配置热更新（hot reload 的配置层级），不属于代码热更新。

热更新（hot reload）的严格定义是不重启进程让新代码或新配置生效，它分两级：

可插拔 RAG 的结构是策略模式 + 注册表 + 工厂：检索器、重排器、嵌入模型各自抽成接口，所有实现注册进注册表，配置决定实例化哪个。切换的对象正是 01 章讨论过的记忆介质——向量库、BM25 索引等检索后端。"一键配置切换"只是在已加载实现集合内重新选择，所以落在配置热更新一侧。

实现链路（以 Nacos 为例）：

• 配置中心 watch：Nacos 1.x 用长轮询——客户端请求被服务端 hold 住 29.5 秒，期间用 MD5 比对配置是否变化；2.x 起改为 gRPC 长连接，配置变更由服务端直推 ConfigChangeNotify。
• 回调触发：客户端监听器收到变更，进入应用内回调。
• 工厂重建：工厂按新配置重新组装 RAG pipeline 实例。
• 原子替换引用：新实例就绪后一次性替换旧引用；旧实例处理完在途请求后释放，保证切换过程对调用方透明。

常见错误：模块级单例在启动时缓存了旧配置对象，配置中心推送之后实例并未重建，表现为"改了不生效"。这正对应 Spring 中 @RefreshScope 要解决的刷新边界问题——只有声明在刷新范围内的 Bean 才会随配置变更销毁重建。

加分点

追问预判

Q10工厂模式的优点是什么？

参考答案

核心优点五条，逐条都要能落到场景：

• 解耦创建与使用：调用方只依赖抽象接口，不需要知道具体类名与构造细节。
• 开闭原则：新增一种产品 = 新增一个类并注册，不修改已有调用代码。
• 依赖倒置：高层模块依赖抽象而非具体实现，依赖方向从"调用方 → 具体类"反转为"双方 → 接口"。
• 创建逻辑集中收口：鉴权、重试、默认参数、连接池等横切逻辑统一写在工厂里，而不是散落在每个调用点。
• 可测试性：测试时向工厂注入 mock 实现即可替换真实依赖。

LLM 应用中的实例：provider 工厂按配置切换 OpenAI / Anthropic / 本地模型；Embedding 与 Retriever 工厂支撑 Q9 的可插拔 RAG。LangChain 的 init_chat_model(model, model_provider) 就是官方提供的工厂函数，其 configurable 模式还支持运行时按 config 选择模型——工厂模式在主流框架中是一等公民。

from abc import ABC, abstractmethod

class Retriever(ABC):                      # 抽象接口：调用方只认它
    @abstractmethod
    def retrieve(self, query: str, top_k: int = 5) -> list[str]: ...

_REGISTRY: dict[str, type[Retriever]] = {}

def register(name: str):                   # 注册表装饰器
    def wrap(cls: type[Retriever]):
        _REGISTRY[name] = cls
        return cls
    return wrap

@register("bm25")
class BM25Retriever(Retriever):
    def retrieve(self, query, top_k=5): ...

@register("vector")
class VectorRetriever(Retriever):
    def retrieve(self, query, top_k=5): ...

def create_retriever(conf: dict) -> Retriever:
    cls = _REGISTRY[conf["type"]]          # 配置决定实例化哪个实现
    return cls(**conf.get("params", {}))

注册表新增检索策略 = 加一个带 @register 的类，工厂与调用方零改动——这就是开闭原则的具体形态，也是 Q9 可插拔 RAG 的最小实现。

加分点

追问预判

Q11本地部署要考虑什么？配置管理放在哪里？

参考答案

第一问：本地 / 私有化部署的六个考虑维度。

• ① 模型推理：选型与资源是核心。显存按"参数量 × 精度字节数 + KV cache"估算，显存不足时用 AWQ / GPTQ 量化压到 4bit。推理引擎对比见下表。
• ② 数据不出域：私有化部署的核心动机——文档、向量、对话记录全部留在客户内网，这一条决定了后面所有依赖都要自带。
• ③ 依赖服务自带：向量库、数据库、Redis 全部打成离线镜像随系统交付，不能假设客户机房有外网。
• ④ 监控与日志：私有化环境无法远程登录排查，指标采集、日志落盘与告警必须随包内置。
• ⑤ 模型 license：开源模型的商用条款各不相同，交付前必须核对授权范围。
• ⑥ 离线交付流程：镜像导出、依赖打包、升级与回滚方案，都要在没有外网的前提下成立。

第二问：配置管理分层回答。

• 单机 / 小规模：.env 文件 + pydantic-settings 读入并做类型校验，启动即发现配置错误。
• 集群：配置中心（Nacos / Apollo / Consul）做统一下发与热更新（衔接 Q9 的链路）；K8s 环境则用 ConfigMap 挂载。
• 敏感信息与普通配置分离：API key、数据库密码进 K8s Secret 或 Vault，绝不进 git；普通配置走配置中心，二者生命周期与权限模型完全不同。

加分点

追问预判

Q13第一个项目后台怎么搭建的？

参考答案

这是经历题，没有标准答案，但有标准结构：用 STAR 框架组织叙述，每一段都给面试官留出可追问的"钩子"。

• S（背景与规模）：项目解决什么问题，服务多少用户、多大数据量——规模决定了后面所有选型的合理性基准。
• T（任务）：候选人在后台中负责哪一块，边界说清。
• A（行动）:技术选型 + 理由、分层架构、关键机制决策——这是面试官追问的主战场。
• R（结果）：量化指标收尾——QPS、P95 延迟、首 token 时间、成本变化。

以下是一个可信的样板架构（A 部分的参考栈），用于校准叙述的颗粒度：

叙述中有两个必须讲对的机制点，面试官的追问通常围绕它们展开：

机制点一：SSE 选型理由。LLM 输出是单向流——服务端持续推 token，客户端无需上行。SSE 比 WebSocket 实现简单（纯 HTTP，无协议升级握手），过代理与网关更友好；流式的根基在于 ASGI 的 send 可多次调用，每生成一段 token 就 send 一次，客户端按 text/event-stream 逐段渲染。需要双向交互（如语音对话）才轮到 WebSocket。

回答此题的重心，是把前几章的设计决策融进自己的项目叙述：01 章的记忆介质选型（为什么 pgvector 而非独立向量库）、02 章的 Agent 分层（路由层与编排层的边界划在哪）、03 章的 Skill 化沉淀，都成为"A（行动）"段落里现成的深度素材。

加分点

追问预判