少林码僧-优快云博客

原创动态规划实战：如何实现搜索引擎中的拼写纠错功能？

我们可以用一个二维数组dp[i][j]来表示将错误单词的前i个字符转换为正确单词的前j个字符所需的最少编辑操作次数。通过动态规划，我们可以有效地实现搜索引擎中的拼写纠错功能。这个方法不仅能够准确地找到与错误单词最接近的正确单词，而且具有较高的效率。在实际应用中，可以根据具体情况对算法进行优化，例如使用哈希表等数据结构来加速查找正确单词的过程。希望本文能够帮助你更好地理解动态规划在拼写纠错中的应用。

2024-09-21 00:00:00 3358 1

原创 elasticsearch亿级数据性能调优实战指南

文章目录慢查询日志es优化黄金原则1、搜索结果不要返回过大的结果集2、避免超大的document3、避免稀疏的数据（1）避免将没有任何关联性的数据写入同一个索引（2）对document的结构进行规范化/标准化（3）避免使用多个types存储不一样结构的document（4）对稀疏的field禁用norms和doc_values写入性能优化1、用bulk批量写入2、使用多线程将数据写入es3、增加r......

2019-10-14 22:34:32 294760

原创 elasticsearch的底层模块深入解析

文章目录shard分配相关的配置及原理1、shard allocation的介绍2、cluster level shard allocation（1）shard allocation settings（2）shard rebalance settings（3）shard balance heuristics3、disk-based shard allocation4、shard allocatio...

2019-10-14 18:12:56 3860

原创生产环境Elasticsearch索引管理篇

索引创建修改删除压缩及滚动创建1、创建索引（1）创建索引的语法用settings给这个索引在创建时可以添加一些设置，还有可以初始化一些type的mappingcurl -XPUT 'http://elasticsearch02:9200/twitter?pretty' -d '{ "settings" : { "index" : { "nu...

2019-10-14 17:30:33 3723

原创 Promise执行流程分析

先上代码console.log(1);new Promise(function (resolve, reject){ reject(true); window.setTimeout(function (){ resolve(false); }, 0);}).then(function(){ console.log(2);}, function...

2019-01-17 10:06:39 5087

原创 php的生命周期

图解php的生命周期

2018-09-05 21:47:11 3526

原创 linux conf配置文件(全)

用户账号相关etcprofilebash_profileetcbashrcbashrcbash_logout用户环境配置 bash_profilebashrc和bash_logoutetcgshadow网络配置修改IP地址等网络相关的配置文件 etcsysconfignetwork-scriptsifcfg-ethetcsysconfignetwork 网关配置相关的配置文件e

2017-09-22 15:52:22 26658

原创用户访问网站基本流程及原理(史上最全,没有之一)

[TOC] 　用户访问网站流程框架第一步：客户端用户从浏览器输入www.baidu.com网站网址后回车，系统会查询本地hosts文件及DNS缓存信息，查找是否存在网址对应的IP解析记录。如果有就直接获取到IP地址，然后访问网站，一般第一次请求时，DNS缓存是没有解析记录的；第二步：如果客户端没有DNS缓存或hosts没有对应www.baidu.com网站网址的域名解析记录，那么，系统会把浏览器的

2017-06-04 10:38:28 40925 8

原创流式输出工程：SSE、增量渲染与中断恢复

流式传输有三种常见方案：轮询、WebSocket、SSE（Server-Sent Events）。轮询是最笨的：客户端每隔几百毫秒发一次请求，问"有没有新内容"。它的缺点是延迟不可控（取决于轮询间隔）、请求数爆炸（一个回答可能几十次请求）、以及服务端压力大。只适合"状态变化很慢"的场景，比如任务进度查询。WebSocket是双向的，功能最全。但用于 LLM 流式输出其实是杀鸡用牛刀——因为输出是单向的（服务端推给客户端），用不上双向能力。WebSocket 的问题在于：需要额外的连接管理、心跳、重连逻辑；

2026-11-06 08:30:15 39

原创微调数据工程：从业务日志到高质量 SFT 数据集

谈到微调，大部分讨论都集中在"用哪个框架"、“LoRA 的秩设多少”、"要不要用 QLoRA"这些技术细节上。但真正决定微调效果的，从来不是这些——。一份 5000 条精心构造的数据，效果往往超过 50000 条噪声数据。而大多数团队在做微调时，数据来源是"业务日志导出 + 简单清洗 + 直接开训"，结果训出来的模型在测试集上很好，上线就崩。这篇讲的是怎么把原始日志变成可训练的高质量数据集。

2026-11-06 08:27:21 49

原创向量索引选型与调优：HNSW、IVF-PQ 与内存预算

很多团队反过来了——先挑一个热门库，然后被内存问题逼着改架构，代价极大。

2026-11-06 08:24:53 6

原创长任务 Agent 的上下文压缩：摘要、外置与断点恢复

把早期的对话交给一个小模型，生成一段结构化摘要，用摘要替换原文。这是目前最主流的做法。关键是摘要的格式要固定，不能是自由文本。

2026-11-06 08:22:03 31

原创文档解析管道工程：PDF、表格与扫描件的抽取链路设计

做 RAG 的团队常有一个误区：把 80% 的精力花在 embedding 和检索上，只用 20% 的精力做文档解析。结果上线后发现，召回的片段里全是页眉页脚、表格被切得七零八落、扫描件的 OCR 错字连篇，模型拿着这样的输入，再强的检索能力也救不回来。。一份 PDF 如果解析出来就是错的，后面所有环节都是在错误的基础上做优化。这篇文章讲的是怎么把解析做成一条可靠的工程链路。

2026-11-06 08:19:38 114

原创把 Prompt 当代码管：版本管理、回归测试与灰度发布

一个 LLM 应用迭代三个月后，最容易被忽视的资产不是模型、不是数据，而是那一坨坨散落在代码里的提示词。它们通常以字符串常量的形式存在，改一句就要发版，出问题回滚要靠 git history 里翻半天，评估全靠"我试了试感觉还行"。这套做法在 demo 阶段没问题，但一旦有真实用户、真实收入，它就会成为最大的技术债。，但它的工程化管理水平往往落后代码两个时代。

2026-11-06 08:17:07 121

原创 Agent 代码执行沙箱：隔离级别、资源限额与逃逸防护

即使做了上面所有事，仍要假设"可能会被逃逸"。所以还需要一层运行时检测。常见的逃逸信号包括：尝试访问、调用ptrace、加载内核模块、访问 Docker socket、异常的文件权限变更。这些行为在正常代码里几乎不会出现，可以用 eBPF 或 auditd 监控，一旦触发立即 kill 容器并告警。另一个实践是蜜罐。在沙箱里放一些看起来有价值但实际是诱饵的文件（比如假的.env），一旦被读取就说明有异常行为。这个方法成本极低，命中率却不低。最后是定期演练。找安全团队做红队测试，尝试从沙箱逃逸。

2026-11-06 08:14:25 100

原创模型路由与级联推理：成本与质量的动态权衡

做 LLM 应用超过半年的团队，几乎都会遇到同一个账单问题：功能上线后请求量涨了三倍，成本涨了五倍。排查下来发现，大部分请求其实非常简单——查个订单状态、改个格式、判断一句话的情感倾向，却全都在用最贵的模型。这件事的不合理之处在于，我们不会为了寄一封平信用顺丰，但在 LLM 应用里，几乎所有请求都走了"最贵的那条路"。模型路由（Model Routing）和级联推理（Cascade Inference）就是用来解决这个问题的两套机制。它们听起来像同一件事，实际解决的是不同层面的问题。

2026-11-06 08:11:42 47

原创 RAG 评估体系：从检索指标到答案忠实度的闭环设计

RAG 项目最危险的阶段不是上线前，而是"演示很成功"之后的那两周。团队会在这个窗口里产生一种错觉：检索能出结果、回答看起来通顺、还能引用文档，于是认为系统已经可用。等到真实用户进来，问题才开始成片暴露——回答里引用了不存在的条款、数字张冠李戴、把两份文档的内容拼接成一句从未出现过的话。。你必须把 RAG 拆成检索和生成两段，分别度量，再合起来看端到端表现。这篇文章讲的就是这套度量体系怎么搭。

2026-11-06 08:09:15 184

原创 Agent 的规划-执行分离：计划表示、重规划触发与并发调度

很多团队在做 Agent 时，第一版几乎都是同一个样子：一个 while 循环，把用户目标、历史消息、工具列表一股脑塞进上下文，让模型输出下一步动作，执行完再塞回去。这个结构在演示阶段非常好用，因为它足够简单，也足够"像人"。但只要任务超过五步，它就开始暴露出三个很难绕开的问题：模型忘记最初目标、在无关分支上反复打转、以及在某个工具连续失败后仍然固执地重试同一条路径。问题的根源不在模型不够强，而在于"边想边做"这种结构本身缺少一个稳定的中间层。

2026-11-06 08:07:04 140

原创 LLM 应用的评测体系：从离线评测集到线上灰度

几乎所有 AI 团队都经历过这样的对话：“我们换了个新提示词，感觉回答质量好多了。“好多少？“……就是感觉更自然了。这种讨论无法沉淀，也无法指导决策。更危险的是，它会导致：新版本在某些场景变好，在另一些场景变差，但因为没人测，差的那些场景会一直烂下去，直到用户投诉。。传统软件可以用断言测试，LLM 的输出是自然语言，"正确"有无数种表达方式。所以需要一套专门的评测体系。这篇文章讲三层：离线评测集怎么建、LLM-as-Judge 怎么做才可信、线上怎么灰度验证。

2026-11-05 08:39:51 52

原创多智能体协作的拓扑设计与冲突消解：从“能聊起来“到“能交付“

先讲一个真实的项目。三个人用两周搭了一个"智能投研系统"：一个规划 Agent 拆任务，一个检索 Agent 找资料，一个分析 Agent 写报告，一个审校 Agent 挑毛病。Demo 效果惊艳，发布会顺利。多智能体系统的复杂度不是线性的。两个 Agent 有一个通信方向，四个 Agent 就有十几个潜在路径，加上循环和并发，状态空间爆炸。这篇文章讲三件事：拓扑怎么选、冲突怎么解、以及怎么让系统"收敛"而不是"发散"。

2026-11-05 08:36:20 65

原创 Vibe Coding 工作流：从自然语言到可合并 PR 的工程约束

"Vibe Coding"这个词火起来之后，被两种极端解读包围。一种说法是"以后不用写代码了，动动嘴就行"；另一种说法是"AI 写的代码全是垃圾，只能做玩具"。两种都不对。。而这 20% 恰恰决定了代码能不能合并、能不能维护、能不能上线。我过去一年把日常开发基本切到了 AI 协作模式，从一个人写，变成"我定架构、AI 实现、我审查"的循环。有效率提升很明显，但踩过的坑也很具体。这篇文章不讲"怎么跟 AI 对话"，而讲。核心是三件事：任务切分、验收标准、以及反馈回路。

2026-11-05 08:32:14 60

原创连续批处理与投机解码：吞吐与延迟的取舍方法论

优化推理服务，本质上是在这条曲线上找到业务能接受的那个点。而理解这条曲线的形状，需要先理解两个技术：连续批处理（Continuous Batching）和投机解码（Speculative Decoding）。它们分别从两个方向优化：前者是"把 GPU 喂饱"，后者是"少算几步"。这篇文章讲清楚它们的原理、适用边界，以及怎么组合。

2026-11-05 08:29:03 129

原创 KV Cache 的显存预算：LLM 推理服务的容量规划方法

这是被问得最多的问题，也是最容易被错误回答的问题。常见的错误回答是"80G 显存，7B 模型占 14G，能跑 5 个并发"。这个算法忽略了三件事：KV Cache、激活值和碎片。在 80G 卡上，权重 14G、其余开销算 5G，剩 61G 给 KV Cache。61 / 2.1 ≈ 29 个并发。这还没算上不同请求长度不一致带来的碎片。所以"能跑 5 个并发"这个数字，大概是按"每个请求都占满 32K 上下文"算的。。

2026-11-05 08:25:50 131

原创混合检索与重排序：BM25、向量与 Cross-Encoder 的工程组合

过去两年，向量数据库几乎成了 RAG 的标配。很多团队的原话是"上了向量库就等于上了检索"。用户问"XJ-2024 型阀门的检修周期"，向量检索召回了一堆"阀门检修"的通用文档，但精确包含XJ-2024的那段没进来。原因是这个型号在预训练语料里从没出现过，embedding 模型不认识它，只能把它当成一个无意义的字符序列，向量被周围的"阀门""检修"稀释掉了。问"错误码 E1042 是什么原因"，向量检索基本抓瞎。E1042和E1043在向量空间里几乎重合，但对排障来说是两个完全不同的东西。

2026-11-05 08:22:48 150

原创 RAG 的分块策略：父子块、语义边界与元数据增强的工程实现

但这句话容易被误读成"把块切小一点"。实际上分块要解决的是一个矛盾：块太小，语义不完整，模型读不懂；块太大，噪声多，检索精度低。举个具体的例子。一份保险条款里写着：第 3.2 条责任免除因下列情形之一导致被保险人身故的，本公司不承担给付保险金的责任：（一）投保人故意造成被保险人死亡、伤残或者疾病的；（二）被保险人故意犯罪或者抗拒依法采取的刑事强制措施；（三）被保险人自本合同成立之日起二年内自杀，但自杀时无民事行为能力人的除外。

2026-11-05 08:19:27 7

原创 Agent 记忆的三层架构：工作记忆、项目记忆与长期记忆的工程化落地

Agent 的记忆不是一个向量库能解决的问题，而是一套关于"什么该记、记在哪、什么时候取"的设计。三层架构的核心不是复杂度，而是克制：工作记忆只放这一步要用的，项目记忆只放会复用的结论，长期记忆只放稳定的事实。每一层都严格把关，整体的上下文质量才能上来。如果你的 Agent 换一个全新的会话，表现明显变差，说明长期记忆没做好；如果它在长任务里越跑越糊涂，说明工作记忆没压缩好；如果它总是重复问同样的问题，说明项目记忆没沉淀下来。三个症状对应三层，对症下药即可。

2026-11-05 08:16:02 66

原创 Function Calling 的工具契约设计：参数校验、幂等与错误恢复

给 Agent 接工具，很多人的第一反应是"写个函数、加段 docstring、注册进去"。跑通 Demo 没问题，但一旦上了真实业务，问题就会密集出现：模型传了个不存在的枚举值、把金额传成字符串、在必填字段里塞了null、同一个工具在一次任务里被调用了四次、工具报错后模型开始编造结果。这些问题的根源不在模型，而在于大多数人把工具当成了"给模型调用的函数"，而实际上它是。契约有两个方向的责任：服务端必须把"能接受什么"写清楚、把"不接受什么"拦住；模型必须能理解"为什么被拒绝"，并据此调整。

2026-11-05 08:12:55 199

原创大模型应用的会话状态管理与幂等设计：把“能聊“做成“能托付“

去年冬天，一个做企业客服的团队找到我，说他们的 AI 助手"偶尔会重复下单"。现象很怪：用户只点了一次"确认退款"，系统却生成了两条退款单；用户只问了一遍"我的订单到哪了"，助手连着回了三遍完全相同的话。日志里看不出任何异常，模型调用成功、工具调用成功、数据库写入成功，链路追踪一片绿色。排查到第三天，问题定位在两个地方。第一，前端在流式响应超时后自动重发了请求，后端把两次请求当成两次独立会话处理。第二，工具层没有幂等键，被调用了两次，就真的退了两笔钱。这两件事单独看都不致命，合在一起就是资损。

2026-11-05 08:09:27 170

原创 Agent 的成本与延迟预算：token 分配、模型路由与提前终止

单次对话的成本是可预测的：输入长度加输出长度，乘单价。但 Agent 不一样，它的成本是，而且乘数隐藏在循环里。一个任务跑 12 轮，每轮都带完整历史，第 12 轮的输入是第 1 轮的十几倍。如果中间调了 5 次工具，每次返回 2000 token 的 JSON，这些内容又全部进入下一轮的上下文。最后算下来，一个"看起来很简单"的任务花了 8 万 token，而用户只看到三行答案。更麻烦的是失控是渐进的。

2026-11-04 08:34:02 76

原创 A2A 与 MCP 的边界：多智能体协作该在哪一层解耦

只要开始做多智能体系统，很快会同时遇到 MCP 和 A2A 这两个名词。然后就会看到大量把它们并列介绍的文章，配上"四件套""双协议底座"之类的说法，读完之后依然不清楚：我现在要接一个数据库，该用哪个？我要让两个 Agent 协作，又该用哪个？混淆的根源在于，这两个协议解决的是完全不同的层次的问题，但它们的表面形态很像——都是"一方发起请求，另一方返回结果"。这句话展开之后，几乎所有设计决策都会变得清晰。这篇文章就按这个线索，把边界、取舍和常见错误讲清楚。

2026-11-04 08:28:48 20

原创并行子代理与工作区隔离：多 Agent 同时改代码的工程约束

当你习惯了让一个 AI 代理连续完成"读代码 → 改三个文件 → 跑测试 → 修报错"这一套流程之后，很快会发现新的瓶颈：它在等，你也在等。一个典型的重构任务，代理执行时间是 8 分钟，其中 6 分钟在等模型返回和跑测试。这段时间里，CPU 在等网络，人在等 CPU。如果能把任务拆成 4 个互不干扰的子任务并行跑，理论上 8 分钟能压缩到 3 分钟。这个直觉是对的，但直接实施会立刻遇到麻烦：两个代理同时改同一个文件，后写的覆盖先写的；两个代理同时跑测试，端口冲突；两个代理同时改依赖版本，锁文件打架。

2026-11-04 08:26:14 78

原创 Vibe Coding 的测试先行闭环：让 AI 用测试证明自己

用 AI 写代码，最让人放松也最让人吃亏的一句话是它在末尾说的那句"功能已实现，可以直接运行"。它可能确实能运行。问题在于"运行"和"正确"之间的距离，比大多数人想象的要远得多。一个表单提交接口能返回 200，但它可能没有校验空值、没有处理重复提交、没有在数据库事务失败时回滚、没有对超长输入做截断。这些都不会在"能跑"这个标准里暴露。传统开发里，这些问题由测试兜住。而 Vibe Coding 的典型流程是"提需求 → 生成代码 → 看页面 → 觉得没问题 → 继续下一个功能"，测试环节被系统性地跳过了。

2026-11-04 08:23:55 65

原创云边混合推理路由：小模型分流与大模型兜底

大模型应用上线三个月后，几乎所有人都会做同一件事：看账单，然后想办法把它降下来。降本的常规手段有三种：换更便宜的模型、做量化、加缓存。。真实流量里，请求的难度分布极不均匀。一个客服系统，60% 的请求是"查订单状态"“退货流程是什么”"营业时间"这类模式固定、答案明确的问题；30% 需要一定的理解，但仍在中等模型的射程内；只有 10% 左右是真正复杂、需要强推理的。如果所有请求都走同一个大模型，等于用 100% 的算力去处理 10% 的难题。

2026-11-04 08:21:29 62

原创 PD 分离部署：把 Prefill 与 Decode 拆开后的调度设计

几乎所有团队在单机跑推理时都会遇到同一个矛盾：Prefill 和 Decode 这两种负载，对硬件的要求几乎相反。Prefill 阶段一次并行处理全部输入 token，矩阵乘法密集，是标准的计算密集型任务。它喜欢大 batch、高算力，Tensor Core 越满越好。Decode 阶段每步只生成一个 token，但每生成一个都要把全部权重和整段 KV Cache 从显存里读一遍。它是标准的访存密集型任务，瓶颈在显存带宽，算力单元大部分时间在等数据。把两者放在同一张卡上，问题就来了。

2026-11-04 08:15:20 150

原创长上下文还是 RAG：一次基于成本与召回率的工程决策

每隔一段时间，"长上下文会取代 RAG"的论调就会重新流行一轮。支持者的论据很直接：上下文窗口已经能装下几十万字，把整本手册塞进去不就行了，何必搞切分、向量化、重排这一整套复杂工程。反对者的论据同样直接：一次请求塞 20 万字，成本高得离谱，延迟高得离谱，而且模型在长上下文中间位置的信息利用率会明显下降。两边都对，但争论本身问错了问题。真正的问题不是"哪个更好"，而是。这篇文章试图给出一套可操作的判断方法，而不是一个立场。

2026-11-04 08:12:54 107

原创 RAG 的查询理解层：改写、指代消解与检索路由

知识库问答效果差，团队的第一反应通常是换模型、换 Embedding、调 chunk size、加 rerank。这些手段都有效，但如果方向错了，投入会全部沉没。。举个真实例子。用户问"那个能退吗"，检索器把这句话编码成向量，去库里找最相似的片段。结果召回了"退款流程说明"里的一段，看起来相关，但答非所问——用户其实是在问上一轮提到的那个已签收三天的订单能不能退。查询里缺失了三个关键信息：对象（哪个订单）、约束（签收三天）、意图（是否满足退货条件）。

2026-11-04 08:10:35 162

原创结构化输出工程：从 JSON Schema 到约束解码的可靠链路

把大模型接进业务流程，第一个撞上的墙往往不是模型不够聪明，而是它输出得太自由。你让它返回一个订单判断结果，它给你一段三百字的分析，最后附一句"综上所述，建议拒绝该订单"。人看着很舒服，程序却完全无从下手。于是所有人都会走同一条路：先说"请以 JSON 格式输出"，然后加一句"不要输出其他内容"，然后写正则表达式去抠 JSON，然后在正则失败的地方加 try-except，然后发现自己在一个月里维护了四十行容错代码，仍然每周收到几次解析失败的告警。。提示词是软约束，模型有权不遵守；

2026-11-04 08:08:09 160

原创提示词缓存与上下文分层：把长对话的推理成本压到三分之一

反例：依赖字典插入顺序，重启后可能变化# 正例：按名称排序 + 固定分隔符，保证字节级一致```这一点在多团队协作的项目里尤其重要。A 团队改了工具描述里的一个错别字，缓存会全量失效一次，这是可接受的；但如果每次部署顺序都在变，命中率就会长期在低位徘徊。### 4.3 会话历史用"追加"而不是"重写"多轮对话里，历史消息应该只追加、不改写。有些实现为了控制长度，每轮都把历史做一次摘要然后替换掉，这会导致前缀每轮都变。更合理的策略是：- 保留最近 N 轮原文（前缀稳定）；

2026-11-04 08:05:22 63

原创大模型应用的评测体系：从离线集到上线门禁

不要追求"一个完美的评测体系"。它的价值在于让讨论有依据，而不在于精确。一份 100 条、由工程师手工确认、每周跑一次的评测集，远胜过一份 5000 条、机器生成、没人看的结果。前者会真的改变决策，后者只会变成 CI 里一个被忽略的红点。

2026-11-03 09:02:05 68

原创多智能体协作系统设计：模式选型、通信契约与失败处理

一个配置良好的单 Agent 加一套好工具，能覆盖八成需求。过早拆分带来的复杂度是实打实的：多次模型调用的成本、跨 Agent 的状态同步、错误传播后的定位困难。单一 Agent 要同时处理检索、计算、格式生成、合规检查，系统提示膨胀到几万字，工具二十几个，模型开始选错工具、忘记约束。这说明不同职责在争夺同一段注意力。写手要发散，审稿要苛刻，客服要耐心，风控要怀疑。把相反的倾向塞进一个系统提示，模型会在两端摇摆，输出忽松忽紧。分开成两个 Agent，各自的人格可以写得很纯。

2026-11-03 08:58:59 84