6 posts tagged with "LLM"

先把本文里的 “Loop” 说清楚：它不是编程语言里的 for/while 循环，也不是增长黑客里的用户增长飞轮，而是 AI Agent / LLM 应用中的执行闭环。

可以先不用技术词，直接想一个人类协作场景：你让一个人写方案、排查问题、整理资料、修一段代码，他第一次给出的结果通常只是 50% 左右的草稿质量。不是因为他不会做，而是因为第一次输入里一定缺东西：目标不够清楚、约束没说完、证据没查全、边界条件没暴露。

真正让质量上去的，是后面的过程：

初稿 -> 追问 -> 补上下文 -> 查证据 -> 修正 -> 再评估 -> 继续收敛

每一轮可能只提升 10%、8%、6%、5%，越到后面越慢，但结果会从“能看”逐渐接近“可发布、可上线、可交付”。这就是 Loop 最朴素的直觉：不是一次生成奇迹，而是用反馈持续减少不确定性。

普通 LLM 应用通常是：

用户输入 -> 模型回答 -> 结束

而 Agent Loop 更接近：

目标 -> 装载上下文 -> 模型规划 -> 调用工具 -> 观察结果 -> 评估状态 -> 继续或停止

把上面的人类协作过程翻译成系统结构，就是这张图：用户的追问变成目标澄清，人的查证变成工具调用，人的复盘变成评估器，人的“先别发出去”变成人工审批和护栏。

它看起来只是多了几步，实际改变很大：模型不再只是“生成文本”，而是在一个被工程系统约束的环境里持续做决策、拿证据、修正路径，直到任务完成、失败、超预算、触发人工审批，或者到达最大轮数。

这也是它最近巨火的原因。过去大家主要把 LLM 当成“回答引擎”，现在越来越多产品开始把它当成“任务执行器”：写代码、查资料、跑 SQL、改文档、处理客服、调浏览器、编排内部系统、跨工具完成工作。真正的能力不只来自模型本身，而来自 模型 + 工具 + 状态 + 反馈 + 退出条件 组成的闭环。

但我会先给一个比较尖锐的判断：

Loop 的价值不是让 AI 无限自治，而是把“不确定任务”变成可观测、可中断、可评估、可恢复的控制系统。

没有目标、没有观测、没有停止条件、没有权限边界的 Loop，不是智能，是昂贵且危险的自动重试。

量化不是“把模型变小”这么简单。它是一套横跨数值表示、压缩算法、硬件指令、推理内核、模型结构、评测方法和部署系统的工程体系。

本文讨论的是 AI/LLM 模型量化，不是金融量化交易。

如果用一句话解释：模型量化是把原来用高精度浮点数表示的权重、激活、KV Cache 或梯度，映射到更低比特的离散表示，从而降低显存、内存带宽、存储和计算成本。

它看起来像一个“压缩模型”的技巧，但真正落地时会牵涉到：

• 数学：舍入、缩放、零点、误差传播、率失真；
• 模型：权重、激活、注意力、MoE、视觉塔、LoRA；
• 算法：PTQ、QAT、GPTQ、AWQ、SmoothQuant、QLoRA、AutoRound；
• 格式：GGUF、GPTQ、AWQ、bitsandbytes、safetensors、compressed-tensors；
• 硬件：CPU SIMD、GPU Tensor Core、FP8、INT8、INT4、FP4、NPU；
• 内核：GEMM、GEMV、weight packing、dequant fusion、KV Cache；
• 服务：prefill、decode、continuous batching、PagedAttention、吞吐与延迟；
• 评测：困惑度、MMLU、GSM8K、长上下文、领域集、安全与回归。

本文从历史讲起，再把专有名词、复杂体系、现代方法和开源生态串成一张完整地图。

图 1 把量化放到完整工程链路里看：先有 FP16/BF16 基座模型和校准样本，再统计权重/激活分布，选择量化粒度和算法，最后打包成 GGUF、GPTQ、AWQ、compressed-tensors 等制品，并交给 vLLM、llama.cpp、TensorRT-LLM 或 Transformers 这类 runtime 执行。任何一个环节选错，都会出现“文件很小但速度不快”“benchmark 没掉但业务格式崩了”“同样 4-bit 在不同框架结果不同”这类问题。

LLM Wiki 不是“给大模型看的百科页面”，而是把组织知识编译成一种人能读、机器能检索、Agent 能遍历、系统能验证的长期知识结构。

先澄清一个容易混淆的点：OKF 在开放知识领域通常指 Open Knowledge Foundation；而本文讨论的 OKF 是面向 LLM Wiki 的 Open Knowledge Format，可以理解为一种工程规范提案，用来约束 AI 原生知识库的目录、页面、元数据、引用、链接、校验和演进方式。

截至 2026-06-19，LLM Wiki 更像一个快速成型的系统范式，而不是已经被 W3C、ISO 或某个基金会正式标准化的协议。腾讯研究者在 2026 年 5 月的 LLM-Wiki 论文中，把它描述为一种“Retrieval as Reasoning”的检索范式：把原始文档编译成结构化 Wiki 页面，提供搜索、阅读和链接跟随工具，并用 Error Book 记录和修复知识构建错误。本文的 OKF 则是在这个方向上给出一套更可落地的格式规范。

"To chunk, or not to chunk — that is the question. But how to chunk is the engineering battle."

在 RAG（检索增强生成）系统中，分块（Chunking）是整个 Pipeline 的地基。检索质量上限由 Embedding 模型决定，下限却由分块质量决定。无论你使用多么强大的 LLM 或 向量数据库，一旦 Chunk 切错了位置、割裂了语义，后续所有优化都是徒劳。

本文将带你由浅入深地走完整条 Chunk 技术发展路线图——从最原始的固定切片，一路升级到 VLM 端到端文档理解。

2026 年初，一个名为 OpenClaw 的开源项目在 GitHub 火速登顶，短短数周内收获超过 30k+ Stars。它不是又一个聊天机器人套壳——而是一个运行在你自己设备上的自主 AI 代理（Autonomous Agent），能够读写文件、执行脚本、控制浏览器、收发消息……如同一个真正的 AI 贾维斯，7x24 小时守候在你的终端里。

本文将以 Windows + WSL 为主线，从零开始带你走完 OpenClaw 的完整安装、配置与深度调优之旅。

"The future of AI is not just chatbots, but autonomous agents working together."

Agentic AI（智能体人工智能）正在改变我们构建应用的方式。传统的基于单次调用（One-shot）大模型的应用在处理复杂任务时往往力不从心，而引入多步骤推理、工具调用和状态管理的 Agent 系统则能极大地提升任务完成率。

在众多 Agent 框架中，LangGraph 凭借其独特的基于图（Graph）的架构设计脱颖而出。它作为 LangChain 生态的重要扩展，专门为了解决复杂多 Agent 工作流中的状态管理 (State Management) 和循环执行 (Cyclic Execution) 问题而生。