刘欢の博客

一、Embedding 与向量检索#

一句话：把文字/图片转成定长数字向量，语义相近则向量距离近；检索时把 query 转向量找最近邻。

• 常用模型：all-MiniLM-L6-v2（384维，轻量快，我项目在用）、bge-large、text-embedding-3（OpenAI）、医疗领域用 BioBERT 微调。
• 相似度度量：余弦相似度（最常用，只看方向不看长度）、欧氏距离、点积。
• 向量维度越高越好吗？ 不是。维度高表达力强但存储/计算贵、且小数据易过拟合；384/768 维是性价比常见选择。
• 挂钩项目：医疗 RAG 用 BioBERT 微调压缩同义术语距离；RuleTest 记忆系统和代码索引都用向量召回。

二、向量数据库选型#

一句话：专门存向量并做高效近邻检索（ANN）的数据库。

• 核心技术 ANN（近似最近邻）：精确最近邻太慢，用 HNSW（图索引，最常用）、IVF（倒排）等牺牲一点精度换大幅提速。
• 数据量大了怎么办？ 分片、用 HNSW 索引、量化压缩（PQ）、冷热分层。
• 挂钩项目：RuleTest 用 ChromaDB + tree-sitter 做代码语义索引；选它因为是中小规模、嵌入式好部署。

三、RAG（检索增强生成）#

一句话：回答前先从知识库检索相关片段，连同问题一起给 LLM，让它基于事实回答，治幻觉 + 补时效。

标准链路：文档 → 分块(chunk) → 向量化 → 存库 →【查询时】query 向量化 → 检索 top-k → 拼进 prompt → LLM 生成。

• 分块策略：太大噪声多、太小语义断裂；常用 200~1000 字符 + 重叠（我项目 Page 用 2000字符/200重叠防切断语义）。
• 进阶：混合检索（向量+BM25）、重排（rerank，宽召回后精排）、Deep-Research（让 LLM 判断查得够不够，我项目 GAMResearcher 实现）。
• 检索到了但答错 vs 压根没召回，怎么区分？ 把召回片段单独看标准答案在不在 top-k：不在=检索问题（调 embedding/分块/混合权重），在=生成问题（调 prompt/上下文顺序）。
• 挂钩项目：医疗 RAG 治幻觉+时效；RuleTest 记忆系统是 Agent 版带反思的 RAG。

四、混合检索与融合（RRF）#

一句话：向量（懂语义）+ BM25（精确匹配）互补，分数融合取 top-k。

• 加权融合（我项目）：归一化后 向量分×0.6 + BM25分×0.4。坑：BM25 分无上界会淹没向量分，必须先归一化。
• RRF（倒数排名融合）：score = Σ 1/(k+rank)，只看排名免疫量纲，k 常取 60。
• 什么时候 BM25 权重该调高？ 专有名词、代码符号、ID、错误码多的场景。

五、Function Calling / 工具调用#

一句话：让 LLM 把自然语言意图翻译成结构化函数调用参数，由代码真正执行再把结果喂回——Agent 能「动手」的关键。

• 流程：定义工具 schema（名/参数/描述）→ LLM 返回要调的工具+参数 → 代码执行 → 结果回喂 → LLM 继续。
• 工具描述为什么重要？ 描述就是给模型的提示词，写不清模型就乱调或不调。
• 工具多了模型选不准怎么办？ 分组/分层路由、先粗筛再给子集、用更强模型、描述里写清适用边界。
• 挂钩项目：RuleTest 统一工具注册层（文件/Shell/Web/Glob/Grep + skill 领域工具）。问数里「执行SQL/查指标字典/画图」、客服里「查订单/提工单/查物流」都是工具。

六、ReAct 与 Agent 编排#

一句话：Reasoning+Acting 交替——想→调工具→看结果→再想，循环到完成。

• 局限：不可控，可能绕圈、跑偏、死循环、token 不可预测。
• 护栏：最大步数、目标评估器（判断是否达成/原地打转）、Phase 切分成有验收标准的小阶段。
• 我项目的双引擎：开放任务用 ReAct（控制流在 LLM）；可验收结构化任务用确定性 Pipeline（控制流在 Python，LLM 退化为单步函数调用）。核心判断：能确定的流程绝不交给 ReAct。
• 单 Agent vs 多 Agent？ 多 Agent 分工明确、可并行、上下文隔离，但协调成本高；简单任务别上多 Agent。

七、Prompt 工程#

一句话：通过精心设计输入让 LLM 稳定输出想要的结果。

• 稳定结构化输出：给配方而非目标、少样本示例 > 长描述、强制 JSON Schema、解析失败带错误回炉。
• 常用技巧：CoT（思维链，让它先想再答）、角色设定、明确约束（「资料没有就说不知道」）、分隔符隔离指令与数据。
• prompt 注入怎么防？ 指令与用户数据用分隔符隔离、关键约束放系统提示、对工具调用做权限校验、输出做后置校验。
• 挂钩项目：RuleTest 让 LLM 稳定输出可编译的 Java+Mockito 测试代码（约束强度比 JSON 高），用「配方步骤+少样本+badcase 迭代」。

八、流式输出协议（SSE vs WebSocket）#

一句话：让回答逐字吐出而非等全部生成完，改善体验。

• 挂钩项目：RuleTest 用 SSE（前端流式）+ Socket.IO（后台广播）双通道；SSE 30秒无消息发 heartbeat 防代理掐连接；消息聚合持久化，刷新可恢复。
• 长连接断了流式内容丢了怎么办？ 服务端聚合持久化 + 前端缓存 + 重连续传，我项目就这么做的。

九、上下文窗口与长文本#

一句话：LLM 单次能处理的 token 上限。

• token：模型处理的最小单位，中文约 1 字≈1~2 token，英文约 1 词≈1.3 token。
• lost in the middle：关键信息放上下文中间易被忽略，重要内容放首尾。
• 超长怎么办：摘要压缩（保留核心诉求/槽位，丢寒暄）、RAG 按需召回、滑动窗口、记忆系统外挂。
• 挂钩项目：RuleTest 记忆系统三层结构 + Page 分页就是治上下文爆炸；Working Memory 超长做摘要压缩而非粗暴截断。

十、模型推理参数#

一句话：控制生成行为的旋钮。

• temperature：随机性。0=确定（适合 SQL/代码/抽取），高=发散（适合创意）。问数/客服该调低。
• top_p（核采样）：从累积概率 top_p 的词里采样，和 temperature 二选一调。
• max_tokens：输出长度上限，防失控。
• 问数场景参数怎么设？ temperature 调到 0 或很低，要可复现、要稳定合法 SQL，不能让它发挥。

十一、评估体系（开放问答怎么量化）#

一句话：没有唯一标准答案的生成任务，怎么客观衡量好坏。

• 问数：执行准确率（生成 SQL 跑出来对不对）、可执行率（语法/权限过没过）、口径一致率。
• 客服：解决率（一次解决无需转人工）、幻觉率、满意度、转人工率。
• 方法：标注 badcase 集 + 自动回归、LLM-as-judge（用强模型当裁判打分）、人工抽检。
• 挂钩项目：RuleTest 用 JaCoCo 实测覆盖率做客观验收（不信模型自述）；同理问数客服要「定基线→拆漏斗→找断点→灰度迭代」。

十二、成本与延迟优化（高频调用场景必问）#

一句话：问数客服都是高频调用，成本和响应速度是生产关键。

• 缓存：相同/相似 query 缓存结果（语义缓存）、prompt 前缀缓存（KV cache）。
• 模型路由：简单问题走小模型/规则，复杂才走大模型。
• 减少调用：能一次 Function Calling 拿全的别多轮、能本地算的别问模型。
• 并发与超时：异步并发、合理超时重试（区分可重试的超时 vs 不可重试的服务不可达）。
• 挂钩项目：RuleTest 切便宜模型实测更慢更差又切回——模型选型必须用真实业务任务基准测试，价格便宜≠综合成本低；适配层补了 OpenAI 兼容分支的 timeout 注入。

速记口诀#

• 检索两条腿：向量懂语义、BM25 懂精确，融合记得先归一化。
• RAG 治幻觉：检索段 vs 生成段，断点分开评估。
• Agent 控制流：能确定的别交给 LLM 自由发挥。
• Prompt 稳输出：给配方 + 少样本 + badcase 迭代。
• 生产三件套：缓存、模型路由、实测验收。