75 篇博文 含有标签「LLM」

做 RAG 的后端工程师大多有过这样的经历：一套 PDF 解析（PyMuPDF + pdfplumber）、分块、embedding、rerank 的管线在技术文档上效果不错，一换到财报、合同、产品手册就开始掉分。检索出来的段落看着相关，但答案在表格的某个交叉格里、在某张流程图的标注里、或者依赖两栏排版的位置关系——这些信息在"解析成纯文本"的那一步就已经丢了。

VisRAG 这篇工作把这个损失量化过：不做文本解析、直接把文档页当图片用 VLM 嵌入，端到端比传统文本 RAG 管线高 20%~40%。这个数字不必照搬（它建立在自建的检索/生成数据上），但方向是明确的：多模态文档的检索单元应该是"页"，而不是"段落"。

本文不讨论 VLM 生成侧，只讲检索层怎么落地：三条技术路线的取舍、多向量的存储与算力账本、把成本压下来的四种手段，以及我自己在 ColQwen 上趟过的坑。前置阅读可以看 RAG 进阶检索 和 向量索引 HNSW/IVF-PQ 两篇。

向量检索上线后最常见的两类问题，一类是「延迟一高就加机器」，另一类是「召回不够就把 efSearch 往上调两倍」——两种都治不了根，因为向量索引不存在「更好的参数」，只存在召回、延迟、内存三角里你愿意让出哪条边。基础链路见 RAG 全链路解析，召回与重排的工程取舍见 RAG 进阶实战，这篇下沉一层，讲索引本身：HNSW 的图怎么长、IVF-PQ 的码本怎么省内存、过滤检索为什么会塌方、删除为什么永远不还内存。

这是「每日一题」专栏的第二十一篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 分库分表之后的在线扩容，今天按轮换回到 AI/LLM 方向，兑现上一篇的预告：长上下文与 RoPE 长度外推。这道题的分水岭很清楚——背过的人能说出「位置插值」四个字，真做过的人能讲清楚「为什么高频维度和低频维度的失败方式完全相反，所以一刀切必错」。

后端工程师看 LLM 应用，最容易忽略的一层是分词器。它夹在你的文本和模型之间：你发出去的每一个请求，先被转换成一串整数编号；你按量付费的每一个 token，就是这串编号里的一位。这一层没有超时、没有重试、没有连接池，看起来不像"系统"，但它是唯一决定 token 数量的环节——而 token 数量同时决定了账单、KV Cache 显存、有效上下文窗口和 decode 阶段的吞吐。

更要命的是，分词器不是中立的。它的行为由训练语料的语言配比决定：一个主要用英文语料训练出来的词表，会把绝大多数额度花在英文词素上，中文、代码和数字只能退化成更短、数量更多的符号。本文不讲"分词器很重要"这种废话，直接从零写一个 BPE，然后用它跑四组实验，把每一项都变成可以写在容量规划表里的数字。所有代码只用 Python 标准库，你可以直接复制运行。

这是「每日一题」专栏的第十九篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇是 短链接系统进阶，间隔了一个月没更新，今天按轮换回到 AI/LLM 方向，聊近两年面试出现频率陡增的一题：混合专家（MoE）——为什么 671B 的模型只需要 37B 的激活参数就能跑起来，这条路到底省了什么、又难在哪。

开源模型现在是一周一个的节奏：Kimi-K3 那篇 2.8T 的 MoE 还没消化完，DeepSeek V4 Flash 就以 284B 参数打出了「智能指数 50」的性价比，隔一周又是 GLM-5.3 把编程 Agent 安全做成卖点（见 GLM-5.3 编程 Agent 安全拆解）。对后端工程师来说，选型已经不是一个「调研一次、用半年」的静态决策，而是一个持续跟踪、反复评估、随时切换的工程问题。本文不讲具体某个模型的评测报告，讲怎么建立自己的评估框架：看什么动态、躲什么 License 坑、怎么用自家任务集跑分。

公司那台 K8s worker 是台「三无」机器：无 GPU、4 核 8 线程（AMD EPYC 9754）、30GB 内存，CentOS 7 + nerdctl，还要兼顾集群负载。我在上面用 llama-server 跑了一个给 IDE 用的代码补全/问答服务，模型从 16B 的 DeepSeek-Coder-V2-Lite 到 135M 的 SmolLM2 随意切换。这篇把选型账本和踩坑记录写下来：量化怎么选、KV Cache 每个 token 到底吃掉多少内存、CPU 上 prefill 为什么比 decode 还慢、KV cache 满载时日志长什么样。上一篇讲了 CentOS 7 + nerdctl 编译 llama.cpp 的完整流程，这篇是运行期的优化。GPU 侧的理论对比（Continuous Batching、PagedAttention）见 vLLM 推理面试题，投机解码 是另一条优化路线，这里只谈 CPU 上最现实的三个杠杆：量化、KV Cache、并发槽位。

RAG 的链路谁都能搭：文档切块、embedding 进库、相似度召回、拼 prompt。但同一套链路，有人线上答对率八成，有人五成——差距不在「会不会搭」，而在「每一步的效果账算没算清」。基础链路见 RAG 全链路解析，这篇讲进阶：切块、混合检索、Re-ranking 各值多少分、花多少钱，Graph RAG 什么时候才值得上。

文本 Agent 的标配是「工具调用」：模型说一句 search_order("sku")，代码去执行，接口是结构化的。但 2024 年底开始，OpenAI Operator、Anthropic Computer Use、各类桌面/浏览器 Agent 把目标换成了像人一样直接操作电脑——没有 API、没有 DOM、只有像素和窗口。这条技术线工程上比想象中难得多，本文按「感知 → 行动 → 验证 → 成本 → 评测 → 安全」拆开讲，附可运行的骨架代码与实测踩坑。

这是「每日一题」专栏的第十六篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇讲了 实时协作文档系统，今天按轮换回到 AI/LLM 方向，聊上一篇预告的题：为什么 vLLM 最快？Continuous Batching 和 PagedAttention 各自解决了什么？