AI与LLM思维链

1. 幻觉:大模型为什么会一本正经胡说

现象问大模型一个问题,它编造了不存在的事实,还很有自信

本质:LLM 本质是概率续写 —— 根据上文预测下一个最可能的词。它不"知道"事实,只是在算"什么词接上去概率最高"。概率高 ≠ 事实对。

🌊 顺藤摸瓜

① 为什么会幻觉

LLM = 概率续写 → 没见过的事实它编(概率高的词组合)→ 训练数据没覆盖 / 过时 / 训练数据本身有错

概率续写训练数据局限知识截止

② 怎么减少

RAG:把真实资料塞进上下文 → 模型基于资料回答(不是凭记忆)→ Prompt 工程:让它说"我不知道"(降低 temperature)→ Function Calling:事实性问题调工具查

RAG 检索增强温度调低Function CallingFew-shot 示例

③ 为什么 RAG 有效

模型擅长理解/推理/总结,不擅长记忆事实 → RAG 把事实外包给知识库,模型只做"读资料答问题" → 各取所长

模型擅长推理不擅长记忆事实外包知识库各取所长

2. 流式渲染:为什么 Markdown 会崩

现象大模型流式输出,代码块没闭合时渲染崩了

本质:Markdown 是块级结构,代码块的 ``` 必须成对。流式输出时闭合标记还没来,解析器处于"悬空"状态,渲染就崩。

🌊 顺藤摸瓜

① 代码块未闭合

模型吐 ``` 后慢慢吐代码,闭合标记还没来 → 解析器悬空 → 解法:渲染前检测 ``` 数量,奇数个补一个闭合

代码块未闭合buffer 补全奇偶检测

② 性能

每吐一个字重解析整个 Markdown → 卡 → rAF 节流(一帧渲染一次)→ 别 setInterval 打字机

rAF 节流避免每字重解析

③ 安全

模型输出可能含恶意脚本 → DOMPurify 清洗后才 v-html → 防 XSS

DOMPurifyv-html 风险XSS 防护

④ 中断

用户点"停止" → AbortController 中断 fetch 流 → 已接收的保留 → 后端配合停止推理(省 token)

AbortController中断生成省 token

3. 为什么 LLM 用 SSE 不用 WebSocket

现象大模型流式输出,用 SSE 还是 WebSocket?

本质:LLM 对话是单向流(服务端→客户端),不需要 WebSocket 的双向能力。但 EventSource(原生 SSE)不支持自定义 header(带不了 token),所以用 fetch + ReadableStream。

🌊 顺藤摸瓜

① 为什么 SSE

单向流 → SSE 够了 → WebSocket 过重(独立协议,要维护连接)→ ChatGPT/Claude 都用 SSE

单向流SSE 轻量WebSocket 过重

② 为什么不用 EventSource

EventSource 不支持自定义 header(带不了 Authorization)→ 用 fetch + ReadableStream 手写 → 既能带 header,又能 AbortController 中断

EventSource 无 headerfetch ReadableStreamAbortController

③ TCP 分包

SSE 消息可能被 TCP 分包切断 → buffer 拼接到 \n\n 才完整 → 中文可能被字节边界切断,用 TextDecoder stream 模式

buffer 拼接TextDecoder stream中文断字

4. 上下文太长:Token 溢出

现象对话太久,模型开始"忘记"前面的内容或报错

本质:LLM 有上下文窗口限制(如 8K/32K/128K token)。超出就丢前面的或报错。上下文越长也越贵越慢。

🌊 顺藤摸瓜

① 滑动窗口

只保留最近 N 轮对话发给模型 → 简单但可能丢重要信息

滑动窗口保留最近 N 轮

② 摘要压缩

把老对话让小模型总结成摘要 → 摘要 + 最近几轮发模型

摘要压缩小模型总结

③ RAG 回收

对话历史存向量库 → 新问题检索相关历史 → 只发相关的 → 长期记忆

历史存向量库检索相关历史

④ Token 计数

前端用 tiktoken 估算 token 数 → 接近上限提示"开新对话" → 精确值要后端返

tiktoken 估算前端提示

5. RAG 怎么检索到对的资料

现象RAG 检索出来的资料不准,答非所问

本质:RAG 靠向量相似度检索 —— 文本转成向量,算距离找最近的。检索质量取决于向量模型好不好、文档切分合不合理。

🌊 顺藤摸瓜

① 文档切分

文档太长要切块(chunk)→ 切太大检索不准,切太小语义不全 → 按段落 + 重叠(chunk overlap)切分

chunk 切分重叠 overlap语义完整

② 向量化

文本 → Embedding 模型 → 向量 → 存向量库(Milvus/Pinecone)→ 常用:bge-m3 / text-embedding-ada

EmbeddingMilvus/Pineconebge-m3

③ 检索不准

检索质量差 → ① 换更好的 Embedding 模型;② 混合检索(向量 + 关键词 BM25);③ 重排序(Rerank):粗召回后精排;④ Query 改写

混合检索BM25 关键词Rerank 重排Query 改写

④ 引用溯源

回答标注来源 [1] → 让用户知道答案哪来的 → 可点击溯源 → 防幻觉的最后一道防线

引用标注来源溯源可信度

总结

现象	本质	第一反应
幻觉	概率续写,不是事实查询	RAG 塞事实 + 温度调低
流式渲染崩	Markdown 块级结构未闭合	buffer 补全 + rAF 节流 + DOMPurify
SSE 选型	单向流,EventSource 无 header	fetch + ReadableStream
上下文溢出	窗口有限,越长越贵越慢	滑动窗口/摘要/RAG 回收
RAG 不准	向量检索质量	切分合理+混合检索+Rerank

本质:LLM 擅长理解/推理/生成,不擅长记忆事实。所有 AI 应用的设计本质都是"把事实外包(RAG/工具),让模型做它擅长的事"。

AI 与 LLM 思维链

1. 幻觉:大模型为什么会一本正经胡说

2. 流式渲染:为什么 Markdown 会崩

3. 为什么 LLM 用 SSE 不用 WebSocket

4. 上下文太长:Token 溢出

5. RAG 怎么检索到对的资料

总结