我最初接触AI实时问答这个方向时，脑子里想的其实特别简单——不就是把大模型接上去，用户问一句它答一句嘛。真正动手之后才发现，这件事远比想象中复杂。单轮问答像在纸上做题，实时交互却更像在电话里跟人对话，节奏、停顿、上下文，样样都得照顾到。
这一章我想把自己在这个阶段踩过的坑和想清楚的事情整理出来。从场景怎么界定，到指标怎么定，再到架构怎么搭、选型怎么划边界，算是给后面几章的工程实现打一个认知底子。
1.1 场景界定与核心需求：从单轮问答到实时交互
我一开始把实时问答想得太窄了，觉得就是客服机器人那种一问一答。后来跟几个业务团队聊下来才明白，场景跨度大得很。有人需要的是知识库问答，用户问一句，系统检索文档再组织答案；有人要的是实时对话助手，像在线陪练、会议问答那种，用户说话系统得跟上节奏。这两类需求看着相似，背后的系统设计逻辑完全不一样。
单轮问答的核心是"问得准、答得对"。用户提交一个问题，系统在几秒内返回一段完整答案，中间过程用户看不见也不需要看见。实时交互就不同了，用户对"等待"的容忍度低得多。我观察过真实用户的行为，首字延迟超过两三秒，很多人就开始怀疑系统是不是卡住了，超过五秒基本就关页面走人。这个感受层面的东西，比准确率更早决定用户去留。
我把核心需求拆成了三层来看。表层是响应速度，用户点下发送到看到第一个字之间的时间必须压到最低；中层是答案质量，答得慢但答得对和答得快但答得离谱，用户都不会满意；底层是稳定性，一次对话里突然断掉或者答非所问，比一开始就慢更伤体验。三层需求叠在一起，才构成了实时问答真正要解决的东西。
1.2 关键指标与体验目标：准确性、首响延迟、吞吐与稳定性
指标这件事我吃过亏，一开始只盯着准确率看，结果系统上线后用户投诉最多的反而是"等太久"。后来我把指标体系重新梳理了一遍，分成体验指标和工程指标两组，两组都得看。
准确性是地基，这个没什么好商量的。我习惯把准确性拆成两部分：答案对不对，以及依据站不站得住。前者靠评测集和人工抽检来把关，后者靠检索命中的文档质量来判断。有些系统答对了但过程是猜的，这种在知识密集型场景里很危险，用户一追问就露馅。首响延迟是体验的门面，我一般把目标定在1.5秒以内出首个token，流式输出能让用户感知到的等待大幅缩短。吞吐和稳定性是工程侧的底线，QPS、并发连接数、错误率这些数字决定了系统能不能扛住真实流量。
这几个指标之间是有张力的。模型越大越准，首响越慢；并发越高，单请求资源越紧。我在实践中会把它们放在一张表里权衡，给每个指标设一个"不可退让"的底线和一个"尽量优化"的目标区间。体验目标不是拍脑袋定的，是拿真实用户行为和竞品表现对照着校准出来的。比如用户对首字延迟的容忍度，不同场景下差异能到两三倍，客服场景能忍三秒，游戏陪练场景超过一秒就被骂。
1.3 技术架构蓝图：前端交互、问答引擎、模型服务与数据层
画架构图这件事，我习惯先不画框，先想数据怎么流。用户在前端敲下一个问题，这个问题要经过哪些手，才能变成屏幕上逐字出现的答案。想清楚了流向，再往上套组件，架构图才不会变成摆设。
我理解中的实时问答架构分四层。前端交互层负责输入、流式渲染、会话状态的呈现，这一层看着简单，实际上手要处理流式断流、重连、打字机效果的节奏感，细节特别多。问答引擎层是整个系统的大脑，管意图识别、上下文管理、检索调度、答案组装，这一层决定了系统"聪明"与否。模型服务层承担推理，可能是本地部署的开源模型，也可能是调用的API服务，还要处理模型路由、超时、降级。数据层则是知识文档、向量索引、会话记录、配置信息的落脚点，它不直接面对用户，但决定了答案的底子厚不厚。
四层之间的边界我踩过坑。早期我把检索逻辑塞进了模型服务层，结果换一个模型就要重写一遍检索，耦合得很难受。后来我把检索增强明确划到问答引擎层，模型服务层只负责"给定上下文生成答案"，职责一下就清楚了。还有一点想提醒，架构图里最容易被忽略的是层与层之间的通信协议。流式场景下用HTTP还是WebSocket，超时怎么设，错误怎么透传，这些看起来是细节，实际上线后往往是最先出问题的地方。
1.4 系统搭建前的选型与边界：模型、检索增强与部署模式
选型这件事，我最大的体会是：没有最好的方案，只有最合适的边界。动手之前我会先问自己三个问题——用户规模多大，数据能不能出内网，延迟要求有多苛刻。这三个答案基本框定了选型的方向。
模型选择上，我一般会在"效果、延迟、成本"三角里找平衡点。开源模型部署灵活、数据不出域，但推理延迟和效果需要自己调；商业API上手快、效果稳定，但成本随调用量线性增长，数据合规上也有顾虑。我的做法是先拿一个小规模真实问题集做对比测试，别只看榜单分数，要看在你的场景里谁答得更让人满意。检索增强这块，核心判断是知识是否需要实时更新、文档结构是否复杂。如果答案大多来自几份固定文档，向量检索加简单重排就够了；如果知识每天都在变，索引更新策略和一致性就得提前设计。
部署模式的选择也很关键。全托管、混合部署、私有化，各有各的适用边界。我见过团队一上来就追求全私有化，结果运维成本压垮了项目节奏。我的建议是先按最小可行架构跑起来，把实时链路走通，再根据真实瓶颈决定往哪个方向加码。选型不是一次性动作，是随着业务认知加深不断校正的过程。边界划清楚了，后面搭建才不会反复推翻重来。
架构图画完只是纸上的事，真正动手搭的时候才知道哪里会卡壳。我带着团队从零开始把这个系统立起来，前后大概用了两个月，中间返工了三回。这一章我想按搭建的顺序，把知识接入、实时链路、并发工程和安全运维这四块分别说说，都是实际操作里踩出来的经验。
2.1 知识接入与检索增强：文档处理、向量索引与答案依据
知识接入这块，我最初想得很天真，觉得把文档丢进去、切一切、灌进向量库就完事了。真跑起来发现，文档处理才是最容易出问题的一环。我们接入的第一批资料是PDF格式的产品手册，里面大量表格、图片说明和多栏排版，直接按固定长度切片，切出来的文本支离破碎，检索出来的内容连我自己都看不懂。后来改成了按标题层级切分，再对表格单独做结构化提取，才勉强能用。
切片策略这件事我调了很久。切得太碎了，检索回来的片段缺少上下文，模型拿到手里不知道在说什么；切得太粗了，一个片段里混着好几个主题，检索精度直线下降。我最后的做法是两级切片，先按章节粗粒度切，再在章节内部按段落细粒度切，检索时先粗召回再细排序。另外每个切片我都会保留来源文档的元信息，标题、编号、更新时间这些，用户问的时候能把依据亮出来，追问的时候也方便做上下文关联。
向量索引的选择我对比过几种方案。小规模场景用FAISS就够，轻量、上手快；数据量上到百万级之后，Milvus这类专门的向量数据库更稳，但运维复杂度也跟着涨。我实际用的是混合检索，向量召回加关键词召回一起上，再做一个简单的重排。纯向量检索在遇到专有名词、型号代码这类内容时经常翻车，加一层关键词兜底能补上这个短板。答案依据这件事我在早期没太重视，上线后被用户追问“你从哪看到的”答不上来，后来在返回结果里固定附带引用来源，用户信任度明显不一样。
2.2 实时问答链路实现：意图识别、上下文管理、流式生成与返回
实时链路的搭建是整个系统最核心的部分，也是调试最磨人的部分。用户输入一个问题，进到系统里先过意图识别，判断这是知识问答、闲聊、还是操作指令。我一开始用规则做意图分类，简单场景够用，但用户换个说法就识别不了。后来换成了轻量模型做分类，效果好不少，延迟增加也不多，几十毫秒的事。
上下文管理是我花心思最多的地方。多轮对话里用户会说“那它的价格呢”这种指代性很强的话，系统得知道“它”指的是上一轮提到的产品。我的做法是在每轮请求里维护一个滑动窗口的对话历史，同时把关键实体抽出来做结构化存储。窗口长度设得太长会拖慢推理，设得太短又丢信息，我试下来大概保留最近五到八轮比较合理，具体的数字还得看场景。流式生成这块，我们用的是SSE推流，模型每产出一个token就往前端推一个，用户看到的是一点点往外蹦字的效果，实际等待感比等一大段文字出来要好得多。
流式返回里有个细节我吃过亏。模型生成到一半突然停了，或者后端网络抖了一下连接断了，前端如果处理不好会显示半截句子卡在那。我的处理方式是给每个流加一个明确的结束标记，前端收到标记才认为这轮回答完成，中途断开就触发重连或者降级到非流式接口重新请求一次。这种兜底逻辑平时看不出价值，流量一上来就是救命的。
2.3 会话与并发工程：多轮状态、限流排队、缓存与降级
会话状态管理在单机测试时完全不是问题，一上并发就原形毕露。我们一开始把会话存在内存里，两台机器一部署，用户第二轮请求打到另一台机器上就找不到上下文了。后来老老实实把会话状态挪到了Redis，带T时间，多实例共享。挪完之后又遇到新问题，Redis写得太频繁，高并发下延迟抖得厉害，最后改成了异步写入加本地缓存双层结构，才算稳住。
限流和排队是上线前必须做的功课。我按用户维度和全局维度各设了一套限流规则，用户维度防刷，全局维度保底。排队策略上我倾向于短队列加快速失败，队列太长用户等在那里还不如直接告诉他稍后再试。缓存这块，我做了一层语义缓存，相似问题直接返回已有答案，命中率在知识问答场景能到两成多，首响直接降到百毫秒级。缓存失效策略要和知识库更新联动，文档一改，相关缓存立刻作废，不然用户拿到的就是旧答案。
降级方案我在设计阶段就写进了代码里。模型服务超时或者报错，自动切到备用模型；检索服务挂掉，走纯模型生成兜底；流式通道不可用，退化成一次性返回。每一层降级都配了开关和告警，能手动控制也能自动触发。我印象很深的一次是主模型服务商那边出了故障，因为提前做了降级，用户侧几乎没感知到异常，只是回答风格稍微变了点。
2.4 安全合规与可运维性：权限、内容过滤、日志与配置管理
安全这块我一开始想得比较简单，觉得内网系统不用太较真。后来安全团队找过来做评审，列了一堆问题，我才意识到权限控制得从第一行代码就开始设计。知识库里的文档是有密级的，不同部门的用户能问到的内容范围应该不一样。我的做法是在检索层加了一道权限过滤，用户发起请求时带上身份标签，检索结果里只保留该用户有权访问的文档片段，模型拿到的上下文本身就是过滤后的。
内容过滤分输入和输出两头。输入侧挡掉明显的攻击性prompt和敏感词，输出侧再过一遍合规检测，防止模型生成不当内容。这块我用的是一套轻量规则加一个小分类模型组合，规则负责明确违禁词，模型负责语义层面的判断。过滤这事有个度的问题，卡太严正常问题也被误伤，卡太松又漏。我的经验是先把误伤率压到很低，漏放的部分靠日志回溯和人工抽检来补。
可运维性是我后来补的课。早期系统出了问题是靠用户反馈才知道的，特别被动。后来我把关键链路的日志全部结构化落盘，每次请求的耗时、命中的文档、模型调用情况、过滤结果都记录下来，出问题能快速定位。配置管理也统一收口了，模型版本、检索参数、限流阈值这些都放在配置中心，改完即时生效不用重启服务。这些基础设施平时不显眼，系统规模一上来就是生命线。
系统跑通那会儿我挺得意的，觉得该有的功能都有了，用户问什么都能答上来。结果第一次内部演示就被打脸——等答案出来，现场安静了快十秒钟，有人低头开始看手机。那一刻我明白，能答和好用之间隔着一条很深的沟。这一章就说说我们怎么把这条沟一点点填平的。
3.1 延迟瓶颈定位：首响、推理、检索与网络链路拆解
要优化延迟，得先知道时间到底花在哪了。我一开始拍脑袋觉得肯定是模型推理慢，准备直接换更小的模型。动手之前做了个简单的耗时埋点，把一次请求拆成意图识别、检索、上下文拼装、模型首token生成、完整生成、网络传输这几段，每段打上时间戳。数据出来我有点意外，模型推理确实占大头，但检索那一段也不小，尤其知识库刚更新完、向量索引还在重建的时候，检索偶尔要两三秒。
分段数据之外，我还盯着几个分位值看。平均延迟一点八秒听起来还行，可P95到了六秒多，P99直接飙到十几秒。用户可不会管你平均值多好看，他赶上一次十秒的等待，对这系统的印象就定型了。我后来养成了一个习惯，每天早上先扫一眼延迟分位曲线，看长尾有没有变厚。长尾变厚通常意味着某个环节在特定条件下退化了，比如某个文档集合的索引失效，或者某台机器的网络出口拥塞。
网络链路这块我差点漏掉。内网测试一切正常，一到外网访问，首响平白多了好几百毫秒。查下来是TLS握手和DNS解析在作怪，还有一部分用户走的是移动网络，丢包重传把延迟拉得更长。这块的优化不复杂，把连接复用打开、静态资源推到边缘节点，效果立竿见影。我的体会是延迟定位这件事没有捷径，老老实实埋点、老老实实看分布，凭直觉猜往往猜错方向。
3.2 响应延迟优化策略：模型加速、并行检索、流式输出与缓存复用
定位清楚之后，优化手段就有的放矢了。模型推理这一块，我试过几种路子：换小参数量的模型、做量化压缩、开启动态批处理。小模型速度确实快，但回答质量掉得明显，复杂问题经常答非所问，最后我采用的是大小模型分流的方案，简单问题走小模型，复杂问题走大模型，中间用意图识别的置信度和问题长度做路由。量化压缩我用了INT8，精度损失在可接受范围内，推理速度提升了大概三成。动态批处理在低并发时意义不大，流量上来之后能把GPU利用率拉满，吞吐提升很明显。
检索这块我做的是并行化改造。原来的链路是串行的，先做意图识别，再检索，再拼上下文。我把意图识别和检索改成并发发起，检索内部的多路召回也改成并行，整体链路缩短了将近一半。流式输出的价值我在上一章提过，这里补充一个数据：接入流式之后，用户感知到的等待时间从完整生成的三秒降到了首token的八百毫秒左右，主观满意度提升非常明显。缓存复用则是最划算的买卖，语义缓存命中时首响直接压到百毫秒以内，连模型都不用调。
这些手段不是堆上去就完事，得考虑互相之间的影响。比如缓存和流式输出叠在一起，缓存命中时是直接整段返回还是模拟流式效果，用户体感差别不小。我最后选了模拟流式，把缓存内容按短句切片往回推，节奏跟真流式差不多，用户察觉不到区别。另外缓存更新策略要跟知识库变更联动，文档一改就主动失效相关缓存，不能等T过期。优化这件事我越来越觉得是个系统工程，单点提速容易，难的是让各个环节协同起来不掉链子。
3.3 监控告警与效果评估：延迟分位、答案质量与用户反馈闭环
延迟指标我分了三层来看：首响延迟、完整生成延迟、端到端延迟。首响最关键，用户等超过一秒就开始焦虑，所以这条线我盯得最紧，设了五百毫秒和一千毫秒两档告警。完整生成延迟影响的是用户读完答案的总时长，跟回答长度相关，我按不同问题类型分别设了基线。分位值比均值重要得多，P95和P99的告警阈值我调了好几轮才找到一个既不过度报警又不漏掉真问题的平衡点。
光看延迟不够，答案质量得同步盯着。我搭了一套自动评估流程，用一批标注好的问题集定期跑回归测试，看准确率有没有下降。线上则靠用户反馈来补，每条回答下面放了赞和踩的按钮，踩的时候可以选原因，答非所问、信息过时、回答不完整这些。这些反馈数据我每周汇总一次，跟延迟数据交叉着看，有时候延迟降下来了但质量也跟着掉了，说明优化方向走偏了，得往回找补。
用户反馈闭环这件事我特别想强调。早期我只看技术指标，觉得数字好看就是好系统。后来发现有些用户反复问相似的问题，不是因为答案不好找，而是因为我们给的答案他没看懂。我找了几位真实用户聊了聊，发现他们更希望答案短一点、直接给结论、依据放后面。这个发现跟数据指标完全没关系，靠的是蹲在用户旁边看他们怎么用。监控告警解决的是系统不挂的问题，效果评估和用户反馈解决的是系统好不好用的问题，两件事都得做。
3.4 规模化落地与迭代：容量规划、A/B测试与成本性能平衡
系统从几十个用户扩到几千个用户，遇到的坑跟小规模时完全不一样。容量规划我一开始做得很粗，按峰值QPS乘一个安全系数就完了。真上量之后发现瓶颈在好几个地方轮流出现，先是模型服务的并发连接数不够，加了之后又卡在向量库的查询并发上，向量库扩完检索带宽又成了新瓶颈。我后来改成按链路逐段压测，每段单独找出容量上限，再取最短的那块板子做整体规划。压测数据跟真实流量还是两回事，我留了大概三成的余量来吸收突发。
A/B测试这事我做晚了，前面几个月都是凭感觉调参。后来搭了一套简单的实验框架，把用户随机分成对照组和实验组，同一批改动在上线前先在小流量里跑两周。印象最深的一次是调检索的召回数量，调高了准确率上去了但延迟也上去了，A/B数据摆出来之后大家很快就达成了折中方案，省了很多会议室里的争论。实验框架不用做太复杂，能把流量切分、指标对比、显著性判断这几个基本功能跑通就够用了。
成本和性能的平衡是个长期话题。大模型好用但贵，全量走大模型一个月账单看着肉疼。我用分层路由把简单问题分流到小模型之后，成本降了将近四成，用户端的延迟也顺带降了。但有些问题小模型确实接不住，我宁可多花点钱走大模型也别答错，答错的代价比多花的那点token贵得多。规模化之后还有一个体会是，迭代节奏要跟系统稳定性做平衡，新功能上线前先在灰度环境跑够时间，着急忙慌地上线往往会把前面攒的口碑一把败光。这套系统到现在还在持续演进，没有哪天觉得可以停下来不看了。
