abca1101的博客

原创 （二）手搓最小版本的Decoder-only框架

SwiGLU 的维度与「3 个矩阵」绑定（8/3 才与 4× FFN 持平，本项目用 4/3 是刻意缩小）；从token_ids到logits的完整张量数据链路，标注每一步的形状变化，配置：L=序列长度，d=512维，H=8头，hd=64单头维度， V=152064词表。3 × d × (8/3)d = 8d²← 代入 d=512 得 1365（8/3 × 512 = 1365.33）3 × d × (4/3)d = 4d² ← 恰好等于 Attention 的4d² （QKVO 四个 d×d）

原创 （四）在GPU上把KV Cache讲清楚：从vLLM压测到有/无缓存对照的完整实测

做过大模型推理优化的开发者，大概率被这几个概念反复困扰。KV Cache 到底优化了哪个推理阶段？Prefill 还是 Decode？行业常说「上下文越长，KV Cache收益越高」，这个结论能否量化验证？vLLM堆叠了PagedAttention、CUDA Graph诸多优化，为什么单请求TPOT提升并不明显？纸上原理永远有歧义，真实硬件实测数据才是唯一标准答案。本文基于阿里云PAI-DSW + NVIDIA A10 24GB。

原创 （三）Prefill&Decoder拆解验证

Decoder‑Only 架构是当前 LLM 主流实现，推理分为Prefill（预填充）与Decode（逐 Token 生成）两个核心阶段,本文结合 Qwen2.5‑0.5B‑Instruct CPU 实机对照实验，从原理拆解、数学复杂度、有无 KV‑Cache 性能对比、瓶颈迁移、内存开销、选型落地建议完整梳理，附带大量实测表格数据分析，帮你彻底搞懂 LLM 推理底层。

原创 （二）Transformer整体框架

本文完整梳理大模型架构演进，依次讲解原版 Transformer、Pre‑LN Decoder‑Only、2026 主流稠密 Decoder‑Only、MoE 稀疏专家模型、Mamba 状态空间模型，给出各架构关键组件数学公式，区分理论定义与工业工程实现，对比不同方案的复杂度、优劣及代表模型，为理解现代 LLM 底层原理提供完整参考。

原创 （一）LLM必备数学基础手册

线性代数是Transformer、向量嵌入、注意力机制的运算基础，所有模型的张量变换、权重计算均基于本章原理。激活函数为LLM引入非线性能力，是模型拟合复杂语义规律的关键，本章覆盖GPT、LLaMA、Qwen全系默认激活函数。本模块整合前面所有数学基础，聚焦Transformer、LLM推理、优化的专属核心公式，是整本手册的核心重点。微积分是LLM反向传播、参数更新、损失优化的数学核心，所有模型训练的梯度计算均基于本章原理。线性代数、微积分、概率理论的终极融合场景，是Transformer架构的核心灵魂。

原创 AI工程化：42周实战学习计划

【代码】AI工程化：42周实战学习计划。

原创 （十五）Agent状态持久化

原创 （十四）Agent错误恢复

【代码】（十四）Agent错误恢复。

原创 （十三）多步决策与多工具编排

【代码】（十三）多步决策与多工具编排。

原创 （十二）Function Calling原理与单工具调用

【代码】（十二）Function Calling原理与单工具调用。

原创 （十一）RAG评估与工程化实现

承接上一篇《（十）端到端 RAG 问答系统构建 (进阶篇)：Rerank 重排序查询改写》的内容，本文聚焦，以 5 天迭代模式完成测试集构建、四大核心评测指标开发、自动化报告生成、失败案例归因分析、针对性优化、前后效果对照，最终搭建一套的 RAG 全链路评测体系，实现 RAG 系统从「功能可用」到「工程可控、效果可测」的进阶升级。，无缝对接原有 RAG 主链路，无架构侵入，可直接落地生产环境。

原创 （十）端到端RAG问答系统构建 (进阶篇)：Rerank重排序查询改写

技术收益查询改写解决用户提问语义模糊问题，Rerank解决向量检索噪声干扰问题，两大模块组合后，RAG 系统适配场景更广、回答准确率更高。

原创 （九）端到端 RAG 问答系统构建(初版)

复用上周最优分片生成的向量库，从根源规避暴力切分断句、短分片向量失效问题，检索段落相关性显著优于旧基线分片；检索函数模块化拆分：向量加载、相似度计算、结果排序相互解耦，后续 Day2 可直接导入函数做 Prompt 拼接，无需重复开发；全量测试 5 道业务问题，全部正常返回有效片段，Top1 相似度均大于 0.75，无无效低相关数据，满足后续 RAG 生成前置要求；Prompt 规则约束生效，模型稳定输出[1][2]引用标记，完成「提问→检索→拼提示词→生成」基础 RAG 闭环；无相似度阈值过滤。

原创 （八）RAG文档切分策略

经过静态筛选→参数矩阵→消融实验→多场景验收五轮验证，产出可直接上线的标准化分片配置，彻底摒弃行业经验式随手配置的陋习；收益量化：常规文档效果持平，超长文本召回 + 30%，多知识点知识库相似度 + 0.1083，全场景整体命中率提升超 15%，满足优化目标；字符暴力切分仅用作实验基线，禁止生产使用：短文档靠模型容错可用，超长、多知识点场景出现系统性精度下滑；原生段落切分受排版约束，天然存在短分片隐患，必须搭配短分片合并优化；

原创 （七）SQLite+Embedding搭建RAG向量检索

向量化就是把文字这种计算机看不懂的自然语言，转换成一串固定长度的数字数组。文字变数字，语义相近的文字，数字也相近。测试中借助智谱Embedding-3接口，把中文文档文字转换成一组2048位浮点数字。语义差不多的内容，生成的数字数组整体就靠近，程序靠数字远近判断内容相似度。项目里函数，就是调用智谱 Embedding-3 完成文本转向量。

原创 （六）搭建LLM多轮CLI聊天机器人

在大模型应用落地中，多轮上下文记忆、流式输出、上下文窗口限制是对话产品三大底层基石，ChatGPT、豆包等产品交互逻辑均基于这套设计思想。本文记录为期 5 天循序渐进的实战开发，依托智谱、火山引擎大模型 OpenAI 规范 API，从极简单轮调用起步，迭代出角色设定、多轮上下文、SSE 流式打字、自动上下文截断、彩色终端交互全功能 CLI 聊天机器人，完整还原工程落地思路。

原创 （五）API 行为背后的 Transformer 底层原理：从 API 现象深挖大模型本质

缓存逻辑：已生成字符的 K、V 向量固定不变，首次运算存入缓存，后续只计算新增 token；每个 token 生成 Q（我要查什么）、K（我有什么特征）、V（我携带的语义）三组向量，Q 与全句 K 做相似度计算，加权聚合 V 得到新语义。自注意力天生没有语序感知，“我爱你” 和 “你爱我” 原始计算结果一致，位置编码给每个位置的 token 附加专属位置向量，区分字符先后顺序。RoPE 旋转编码（Llama3、Qwen、火山商用模型）：行业主流，支持长度外推，训练 8K 上下文，推理可拓展至 128K。

原创 (四)Transformer

（双模型对照：BERT 双向 + 中文 GPT 单向）结果分析思考：上述都是“底层原理剖析”阶段，感觉不太直观，补充“上层应用表现”阶段。

原创 （三）Prompt实战

用于从文本中抽取结构化信息的模版掌握大模型结构化输出能力，实现新闻文本自动抽取：人名、地名、事件、时间，输出标准可解析 JSON 格式，对比智谱、火山双模型稳定性。结构化任务必须做强约束：明确要求模型只输出 JSON、无解释、无 markdown、无多余文字，搭配低随机性参数 temperature=0.1，彻底杜绝格式错乱问题。编写抽取模板脚本，复用通用调用函数，分别请求智谱、火山模型准备5条新闻类测试文本，批量跑双模型测试产出：extract_template.py 完整可运行脚本。

原创 （二）LLM API 直连调用

国产大模型看似接入简单，实则布满细节陷阱：域名、接口路径、模型名称、参数兼容性、超时配置，任何一处疏漏都会导致调用失败。推荐实战方案：统一使用原生 REST 接口调用，一套代码适配多模型，搭配自动降级、异常重试等容错逻辑，无论是新手学习还是项目落地，都能大幅降低维护成本。附件：1、deepseekAPI 调用demo# 调用deepseek api，返回参数import osimport re# 加载 .env 文件中的环境变量。

原创 （一）Python基础学习

无需从头学起，遇到不懂的数据结构直接对照Java思维转换。不同点：这个地方差别也挺大的，在Java中多线程都必须显示声明线程池或者线程创建，在Python中使用TaskGroup和gather还是有区别，调用方法也有区别asyncio.run(函数)，普通函数都是直接调用。不同点：java是一个强制类型的语言，每一个变量都要指定对应的类型，python在这方面比较宽松，这是一个差异比较大的地方。这一块Python的功能和性能都优于Java。

原创 供应链计划系统架构实战（十）：回顾与未来展望

在此基础上，构建四类库存策略：“打底库存” 适配需求不稳定物料，“控制库存” 平衡稳定需求与市场容量，“目标平衡” 聚焦核心盈利物料的库存周转率，“保供优先” 保障关键物料供应，且支持策略动态切换。针对超大容量数据，按 SKU 编号、时间维度分表，解决单表查询性能瓶颈。构建算法自适应机制：通过 Python 实现模型动态选择与优化，核心逻辑为：针对单个 SKU，加载候选算法集合（ARIMA、LSTM、规则模型），利用历史数据交叉验证，计算 MAE（平均绝对误差）等指标，选择误差最小的算法执行预测；

原创 供应链计划系统架构实战（九）：补货计划引擎的核心算法与工程实现

在供应链计划系统中，补货计划引擎是保障库存健康、平衡供需的核心模块 —— 它需要基于多层级仓库的供需关系，精准计算每个节点的补货量。今天我们就拆解其核心算法逻辑与工程实现思路。

原创 供应链计划系统架构实战（八）：高性能存储与查询架构--MySQL主从与分表的应用

角色核心职责主库（Master）接收所有写操作（insert/update/delete）,记录数据变更到二进制日志（binlog）从库（Slave）读取主库的binlog，重放日志同步数据，仅处理读操作（select），可多台部署。

原创 供应链计划系统架构实战（七）：轻量级分布式计算框架设计与实现

无限循环运行的守护线程，负责监控和管理集群中所有进程的执行状态，分布式锁：使用 PROCESS_APPLICATION_LOCK_KEY 确保集群中只有一个节点执行监控。无限循环运行的守护线程，负责监控节点的状态信息，分布式锁：使用 ALL_NODE_PROCESS_LOCK_KEY 确保集群中只有一个节点执行监控。1、服务注册与发现（Redis）基于redis缓存去更新。

原创 （二）前端基础框架构建

使用Vue语法一套代码多端发布（微信小程序为主）这是最核心的一步，请确保你选择了正确的文件夹。管理项目依赖（当前项目用npm即可）1. 安装Node.js (18+)构建响应式后台的单页应用(SPA)提供小程序风格的UI组件，加快开发。提供类型安全，提升代码质量与维护性。这是linux命令，手动创建也可以。uni-app的Vite编译插件。提供丰富、成熟的桌面端UI组件。极速的现代化构建与开发体验。编写更强大、可维护的样式。统一代码风格，自动格式化。- uni-app配置。2. 安装VSCode。

原创 （一）系统介绍及后端框架构建

技术上的特点是：后端用您擅长的 Java (Spring Boot) 稳定可靠地处理数据和业务；前端用 Vue 3 快速搭建后台网页，用 uni-app 一套代码生成微信小程序，省钱省力。简单说，它就是把培训机构的日常工作（管课、招生、收款）和学生的体验（报名、学习）都搬到了线上，让双方都更省事。

原创 计划体系详解

一个卓越的计划体系，本质上是企业将战略目标转化为日常行动的中枢神经系统。它不仅仅是排产工具，更是企业整合内外部资源、应对市场变化的核心能力。在不确定性成为常态的今天，那些能够构建起敏捷、智能、协同计划体系的企业，将在供应链韧性、客户响应速度和运营效率上建立起持久的竞争优势。计划永远赶不上变化，但卓越的计划体系能够让企业在变化中保持方向，在波动中维持节奏，在挑战中把握机遇。这或许就是现代企业计划体系的真正价值所在。

原创 供应链计划系统架构实战（六）：技术选型-构建高可用高性能技术栈

在数字化转型浪潮中，构建一个高性能、可扩展、易维护的全栈应用需要精心选择技术栈。本文将详细介绍一个完整的企业级技术架构，涵盖后端Java服务、Python计算服务、前端Vue应用以及基础设施等各个层面，每个组件都经过精心选型和版本适配，确保系统的稳定性和前瞻性。

原创 供应链计划系统架构实战（五）：数据模型设计-全球网络模型与数据分布

一个优秀的供应链计划系统，是。

原创 供应链计划系统架构实战（四）：架构蓝图--支持全球业务的微服务架构设计

上下游系统之间的交互如下图所示。

原创 供应链计划系统架构实战（三）：全球系统数据与实现难点分析

上述四点都是技术上所会碰到的难题。实际上来说，除了技术上碰到的难题，业务上需要解决的难题也不在少数，下列列举一下其他方面的一些难题。

原创 供应链计划系统架构实战（一）：核心概念与体系概述

形成一个矩阵，对不同类型的配件才去不用的预测算法结果和配置不同的库存策略，例如，AX类采用时序预测算法即可满足比较精准的预测与连续补货，CZ类配件可能就采用简单的打底库存策略和上限控制需求。定义物料在不停地区的一个可接受的现货满足率，这个目标应该按照配件的不同重要性进行分级设定，比如重要配件的满足率95%，此等级85%，依次递减的方式设置。根据物料在不同地区的一个销量数据和预测数据，选择不同预测库存策略，包括（打底库存、控制库存、目标平衡、保供优先）等策略。将库存策略转化为具体的补货计划，并执行补货操作。

原创 供应链计划系统架构实战（二）：全球四级供应网络与三级储备策略

这个分析主要表现为四级网络下，一个配件从“生”（采购）到“死”（消耗）的旅程，是如何被精密设计的，计算最经济的库存水线和补货路径，最终实现服务水平和总持有成本的最优平衡在国家子仓实现“秒杀”，在国家总仓实现“日达”，在区域中心仓实现“区域覆盖”，在国内总仓实现“全球保障”。策略是逐级下沉，全面覆盖。主要集中在国家总仓和区域中心仓。策略是区域集中，快速响应。高度集中在国内总仓。策略是全球一本账，按需空运直发。配件四级分类（基于功能与需求特性）关键、重要，单价高，导致设备停机。

原创 补货计划生成

专栏前面介绍了很多供应链体系的一些相关知识，接下来介绍核心的供应链管理问题-补货建议，一个优秀的补货建议系统能够显著降低库存成本、提升客户满意度并优化现金流。下面简单介绍一下补货建议的实现逻辑，实际到业务中，一个补货建议的生成比这个更加复杂，涉及到多个系统之间的协作，每个环节都很重要，补货建议的产生是一个集成了数据治理、生产制造、物料、客户关系管理、订单管理等等多个系统之间数据的交互，是一个多维度，实时动态数据共同协助驱动的决策。

原创 间歇性预测算法 - SBA

之前介绍过间歇性算法-Croston()，从验证上来说Croston会系统性的高估需求预测值10-30%，所以引入SBA（Sybtetos-Boylan Approximation）算法修正Croston的系统性偏差。

原创 间歇性预测算法 - TSB

上文介绍了入门的间歇性预测算法Croston，它在实际的预测场景中还是存在一些不足，本文将介绍它的一个改进算法TSB(Teunter-Syntetos-Babai)。

原创 间歇性预测算法 - Croston

上一篇文章中已经介绍了五种时序预测算法针对快中慢流件的不同产品之间的一个使用效果，发现时序预测算法对慢流件的预测效果很差，因为慢流件的需求往往很稀疏，不规则，所以需要引入新的预测算法，比如间歇性需求预测算法。本文将介绍经典的几类间歇性预测算法。

原创 供应链计划 - 物料分类

数据收集：收集配件SKU、历史需求、单价、供应商、提前期、设备BOM及关键性标识等数据。关键性分析：联合服务、维修和工程部门，为每个配件评定关键性等级（A/B/C）。需求模式分析：分析每个配件的历史需求数据，划分为快流、慢流或零流。矩阵定位：将每个配件放入“关键性-需求频率”矩阵。制定差异化策略：为每个象限的配件制定明确的库存策略（库存与否、库存水平、订货策略）、采购策略和供应商管理策略。系统执行与监控。

原创 需求预测算法 - 时序预测算法分析

针对已经介绍过了5类算法，算数平均法、简单移动平均法、加权移动平均法、一次指数平滑法、二次指数平滑法，通过对实际生产中的几类产品（快流件/中流件/慢流件）进行模拟。通过对不同的产品类型与数据的模拟计算，综合分析几类算法的优缺点。