Transformer 解码器：大模型是怎么“一个字一个字”写出来的
上一篇《Transformer 编码器》回答的是”读”的问题：一个词，怎么吸收整句话的上下文。今天翻到另一半，回答一个你天天见、却可能从没往深里想过的问题—— 你问大模型一个问题，它为什么要”一个字一个字”往外蹦？在”写”的过程里，它脑子里到底在一步步算什么？ 先立一句话贯穿全文，后面所有内容都在给这句话做注脚： 解码器 = 戴着一副”只能看左边”的眼罩，一遍遍地猜”下一个词该是谁”，猜出来就拼回输入、再猜下一个，直到猜出一个”该停了”的信号。 你可能觉得”自回归”“预测下一个词”这些词都听腻了。放心，这篇不重复《向量数据库原理》 §13 已经讲过的概念，而是把那里”一句话带过”、以及前几篇从没展开过的三样东西讲透： 因果掩码的代码长什么样、位置编码（RoPE）到底在干嘛、以及同一个解码器为什么训练时能”并行”、推理时却只能”串行”。 一、先定一个锚：大模型用的只是...
阿里 AgentScope 详解：一个多智能体框架，从 ReAct 循环到企业级 Harness
你写了一个”客服智能体”，能查订单、能退款、能安抚用户，单机跑得好好的。可产品经理说：再给我加一个”质检智能体”，让它审客服的回复；再加一个”运营智能体”，让它看质检结论出报表。三个智能体要互相喊话，还要部署到线上——多个实例、多个租户、数据互相隔离、跑挂了能定位。这时候你发现，手写 if-else 和几段 async/await，已经撑不住这套东西了。 这不是你一个人的困境。单智能体（Single Agent）早就不是瓶颈，真正难的是多智能体怎么协作、怎么上线、怎么治理。而这，正是阿里 AgentScope 这类框架要解决的问题。 这篇文章延续之前《从大模型到 Agent》《Agent 的循环与目标》的剖析风格，回答三个问题： 是什么：AgentScope...
Transformer 编码器如何实现向量"吸收"：一句"句内 RAG"讲透
上一篇《向量数据库原理》的 §12，我用”库存不足”带你走了单头注意力的数字：算出来”库存”的新向量里，混进了约 52% 的”不足”。你当时追问的那句——“Transformer 编码器，是怎么实现向量’吸收’的？”——那一节为了不打断主线，把很多零件一句话带过了。 这篇就是它的放大镜：把”吸收”这个动作，拆到每一个零件、每一行代码。 先立一句话贯穿全文，后面所有内容都在给这句话做注脚： 吸收 = 每个词对整句话做一次”句内 RAG”：用 Q...
向量数据库原理：从 1536 维坐标到语义检索（通俗解释）
上一篇《企业级记忆知识库》里，我把”代码库信息、业务知识怎么写进向量数据库、怎么被检索回来”讲到了代码级。但写完我自己回头看，发现一个更根本的问题被跳过了： 向量数据库内部，到底是怎么回事？ 那段话、那篇企业发文，是怎么被算成一串 1536 个数字的？两个没有一个共同词的句子，凭什么说它们”语义相近”？为什么高维空间里树索引会失效？Transformer 那”一坨矩阵乘法”到底在算什么？ 这篇文章就是补这一课。它不是那篇的续集，而是那篇的地基——上一篇告诉你”怎么写代码调用向量库”，这一篇告诉你”向量库背后那套原理，以及顺着它引出来的一整条链路”。 写作方式跟以往不一样：这一篇按”你可能会问的问题”来组织，每个问题都是从真实困惑里来的。你可以跳着读，卡在哪就读哪一节。 先立一句话贯穿全文： 向量数据库不是”存文本”的数据库，而是”存高维坐标点”的数据库；它的”索引”是一张导航图或一堆簇；它的”查询”是”找到离我最近的点”。 一、先忘掉”数据库”，它本质只解决一个问题 MySQL...
企业级记忆知识库：短期上下文与四层记忆的 RAG/向量检索实现
你是一个 Java 后端工程师，手上有一个订单中心。某天你让 Agent “帮我在下单流程里加一个库存不足的兜底”。 它没有翻代码，也没有问你 createOrder 里调了哪几个服务，而是直接告诉你： 下单流程依次是 RiskService.checkRisk → InventoryService.freezeStock...