面试题库

14 天 RAG：从检索到可信回答

D6 生成这一侧：上下文怎么排、引用怎么标、什么时候必须拒答，以及流式回答

• 流式输出的场景下，你怎么保证吐出去的内容不会因为引用校验失败而需要撤回？In a streaming setup, how do you make sure nothing you have already sent needs to be retracted because its citation failed verification?

  国内高频海外高频深入#streaming#citation-verification#api-design

  分析过程 · 先想清楚再作答

  1. 这题在考一个真实的架构矛盾：流式要尽早出字，引用校验要等话说完才能核对。看回答里有没有出现「取舍」两个字，以及有没有把代价说清楚。
  2. 先说清矛盾在哪：一旦一个 token 发到了浏览器就撤不回来，你在末尾才发现第三句引用是编的，那句话已经在用户屏幕上了，只能补一句「刚才那句请忽略」，体验比不流式还糟。
  3. 给方案：按句缓冲。攒够一个完整句子就立刻校验一次，通过了才把这句连同已核实的引用发出去，没通过就整句丢掉。代价是首字延迟从一个 token 变成一句话，通常两三百毫秒，用户几乎察觉不到，而错误引用一旦上屏赔的是信任。
  4. 补两个实现细节，它们能证明你写过：流式模式没法用 JSON 输出（要等右花括号闭合才能解析），所以改成纯文本加行内标记，但校验必须和非流式共用同一套；标记要从正文里剥掉，正文保持干净，编号单独走校验再作为结构化数据发出去。
  5. 再补一条顺序上的讲究：生成前就能判的两条拒答线（分数过低、材料冲突）要在流开始之前发出去，用户不会先看到半句回答再被收回；生成后才能判的那条，在按句缓冲之下表现为一句都没发出来，收尾补一个拒答事件即可。
  6. 可预期的追问：那用户体验上的流式感是不是就没了？没有，句级流式在中文长回答里仍然是明显的渐进呈现；真要更细，可以在句子发出前先流一个「正在核对」的占位态，但不要流未校验的正文。

  How to reason about it · think before answering

  1. This tests a real architectural conflict: streaming wants the first token out early, citation verification cannot run until a statement is complete. Listen for whether the candidate names the trade-off and prices it.
  2. Name the conflict: once a token reaches the browser you cannot take it back. Discovering at the end that the third sentence cited a fabricated block leaves you posting 'please ignore that last sentence', which is worse than not streaming at all.
  3. Give the solution: buffer by sentence. As soon as a complete sentence lands, verify it, and only then emit it together with its verified citations; drop the whole sentence otherwise. The cost is that time-to-first-token becomes time-to-first-sentence, typically a few hundred milliseconds, which users barely notice, whereas a bad citation on screen costs trust.
  4. Add two implementation details that prove you have built it. Streaming cannot use JSON output because JSON is only parseable once closed, so switch to plain text with inline markers, while keeping exactly the same verifier as the non-streaming path. Strip the markers out of the prose and send the numbers as structured data after verification.
  5. Add the ordering point: the two rules decidable before generation, low score and source conflict, should be emitted before the stream starts, so the user never sees half an answer being withdrawn. The rule that needs generation shows up as 'no sentence was ever emitted', so close the stream with a refusal event.
  6. Expected follow-up: does this kill the streaming feel? No. Sentence-level streaming is still visibly progressive on long answers. If you need finer granularity, stream a 'checking sources' placeholder, but never stream unverified prose.

  答题要点

  • 矛盾在于发出去的内容撤不回来，而引用只有一句说完才能核对。
  • 解法是按句缓冲：攒够一句校验一次，通过才发，没通过整句丢掉。
  • 代价是首字延迟从一个 token 变成一句话，这个代价必须付也付得起。
  • 流式用不了 JSON，改纯文本加行内标记，但校验逻辑与非流式共用同一套；标记从正文剥出，编号作为结构化数据单独发。
  • 生成前能判的拒答要在流开始之前发出去，生成后才能判的那条以「一句都没发」的形式收尾补事件。

  Key points

  • The conflict: emitted text cannot be recalled, while a citation can only be checked once its sentence is complete.
  • The fix is sentence-level buffering: verify each completed sentence, emit only if it passes, drop the whole sentence if it does not.
  • The cost is time-to-first-sentence instead of time-to-first-token, which is affordable and worth paying.
  • Streaming cannot use JSON, so use inline markers in plain text while sharing one verifier with the non-streaming path; strip markers from the prose and send numbers as structured data.
  • Emit pre-generation refusals before the stream opens; the post-generation one manifests as an empty stream and is closed with a refusal event.