LLM 系统优化，本质是信息流重构，而不是模型升级。
题解：「链路之外」 = 1～3 篇那条（选量化、12G 本机三进程、编排/捞上下文）不必先在你机器上 全链配齐，也能单开 试 0/1/2 三档；「一刀」 指 进主模 prompt 前 再 压字数、少误伤 的那一层。
系列位置（重要）：本系列 1→3 篇 从 选量化 说到 12GB 本机三进程 再说到 业务里捞上下文；第 4 篇 是另一条实验线——尝试语义压缩 不必 放在那台 12G 工作站上跑通 才算数；主试试在线大模型（OpenAI 兼容）+ 0/1/2 三档 时，环境成本 与 第 2 篇本机大工程 可完全不是同一局。
心智：业务层 上仍接 第 3 篇 的「候选从哪来」；实现上 本文 主打 少拉本地推理栈、摘要档走 API 也能把「进主模前再压一截」玩明白。
1. 引子：和「本机 12G 那几条」分开试，我在这层「豁然开朗」了
- 第 1～3 篇 的重体力 多在 本机/量化/多进程/编排；语义压缩 0/1/2 档 我这边是 单开 来试的——不跟「必须在那台 12G 上全链跑起来」 绑死；2 档 用 OpenAI 兼容 在线大模型 就够用，成本 在数量级上 便宜大碗（例： 某档 10 元档起充、压缩相关 只花了约 0.0001 元级 人民币——以你当时账单为准，只作量感）。
- 自己玩、不迷信「必须国外闭源大模型」、不必 为这一刀再搞本机 7B/大模型服务 也能迭代；不拉新推理栈 时，改压缩策略 会轻很多。
- 下面把「这刀插在链路的哪、和全库 RAG 什么关系」钉死，再讲 0/1/2 怎么当「一套配置」 和 怎么逐级加能力。
2. 与第 3 篇的缝、整条链路、以及：从「生硬」到「semantic」的升级
不替换「从库里捞上下文」的那一步，只在 捞完之后、塞给主模型之前，用 句向量 和 大模型 把文字压短、少误伤。
整条链路：
会话里的消息
↓
get_context_candidates（时间窗口 + 排名，谁像当前问题就靠前，第 3 篇已讲）
↓
【压缩层 · 0/1/2 是同一套可配置档位，可关可开、可只开其中几档】
↓
拼进主对话 prompt
实验上我是按「能力逐级加」来试的——不是把 0/1/2 当成三个互不相关的乱开关：
-
0 档 · 无句 embedding 的基线
机械截断 等 + 可选LongContextReorder（仅 LlamaIndex 后处理，不跑 HF 句 embedding）。能最快对拍「砍完/摆完长什么样」，但不挂 embedding 时，观感容易生硬——偏按规定砍字、调顺序，语义上贴不贴题 不好肉眼看。 -
+1 档：加 LlamaIndex 配套 embedding，看「捞进来内容」的句级相关性
在 0 之上接llama-index-embeddings-huggingface+ BGE 一类 +SentenceEmbeddingOptimizer：消息拆到句，按句与当前问题相似度 决定留哪句。这一步的直观收获是对照着看：同一批get_context_candidates之后，哪些句被留、像不像和当前问句相关——仍是 在已排序候选上筛句（素材：「用向量在上下文里做语义筛句」），不是 全库 RAG 另开一张表。 -
+2 档：加大模型 API，用「压缩用 prompt + 独立接口」测语义压缩
在 1 已经把池子缩小、误伤压下去 之后，对偏长 assistant 等 再跑 OpenAI 兼容 大模型（单独 chat/completions 类接口、单独写压缩任务 prompt；与主对话是不是同一路模型，以你接法为准）。这里测的是 大模型做摘要/压缩 的效果，不是 把主模当万能按钮搅进同一条链不区分任务。
0 / 1 / 2 在仓库里是一条「配置」：一次实验选调位组合（常见：0 对拍基线 → 开 1 看相关性 → 再叠 2 看 token），路由 / compress_meta 里 是否 挂 embed_model、是否 调 LLM，成稿 时与 04-B、context_…_compress / llm_compress 对表 写清。素材里那句也成立：0 多对应 04-A 向；1+2 叠起来是 04-B 的先句向量少误伤、再 LLM 少字数。
【和「全库 RAG / 双轨 检索」】 再钉一句（不另起一节，防和后面的 LlamaIndex 表重复讲）：不是 用向量去 百万文档 里 top-k 当唯一进路（03-C / 全库 那套另说），而是 在已排好序的一小撮候选 上 句级筛、必要时再 LLM 收一嘴——同一套数学、不同阶段（与素材一条线同向）。
3. 三档在「配置」里长什么样：无嵌入 / 句向量 / 大模型摘要
| 挡位 （与仓库命名对齐） | 做什么 （梗概） | 依赖 （骨架占位） |
|---|---|---|
| 0 | 机械截断类 + 长上下文重排等轻后处理 | 偏 04-A；不强制 句 embedding |
| 1 | 按句与当前问句 相似度 剪枝 | BGE 类 + SentenceEmbeddingOptimizer 等（HF/你当前机器 成稿时写死；不 等同「必须 12G 那套」） |
| 2 | 对偏长 assistant 等做 LLM 要点摘要；user / pinned 尽量不动 | OpenAI 兼容 API（如 DeepSeek 等，以你实际接的为准） |
（与「向量」关系 的细表 见素材三档一节；这里强调：三档 = 同一条压缩配置 里的 0/1/2 位，不是三套无关管道。）
- 路由、
compress_meta、是否 出现embed_model：与04-B、仓库context_…_compress/llm_compress对表；成稿 择要贴 1～2 个字段名 方便读者对齐，不 贴整文件。
4. LlamaIndex 在我们链上怎么接：和「索引 + query 全套」的区别 （与仓库实现可对表）
探渊对代码的口径（和本文「链路之外 / 0·1·2 档」一致即可收，不吹成另一套产品形态）：
没走 常见教程里那套 「文档 → 建VectorStoreIndex→query_engine提问」 的完整 RAG 主路；实际用的是 LlamaIndex 的postprocess_nodes后处理 +TextNode/NodeWithScore/QueryBundle这套积木，自己把候选（来自你侧召回）喂成节点 再后处理。
| 大致路径 （参考；以你真实仓库文件名为准） | 用到的 LlamaIndex 能力 |
|---|---|
context_llamaindex_compress.py 一类 | LongContextReorder + TextNode + QueryBundle；无 独立「再建一套 embedding 包进主路」那类用法；docstring 也通常会标明不额外开 embedding 的取向 |
llm_compress.py 阶段 1 一类 | HuggingFaceEmbedding（llama-index-embeddings-huggingface）+ SentenceEmbeddingOptimizer，同样落在 postprocess 一挂 |
| 阶段 2 摘要 | 直接 走 OpenAI 兼容的 openai 类调用（如接 DeepSeek），未 必包一层 llama_index.llms 的 OpenAI 包装；与 04-B 里「大模型那步可以 不用 LlamaIndex LLM」的解耦一致 |
对应到推文里那句：召回 仍是 get_context_candidates（含 PG、trgm、时间窗等，第 3 篇那侧）；LlamaIndex 只管 「候选已经定了之后，怎么截、怎么排、按句怎么筛 / 长上下文重排」 —— 和仓库对照，没有 把「全库向量 RAG 全家桶」写成你们现在的干法，不打架。
实现小提醒：阶段 1 里若用 get_content(MetadataMode.NONE)、excluded_llm_metadata_keys 等修过，目的是 别把 metadata 混进要算相似/要展示的正文；语义上 仍是 在候选上句筛，和上文不冲突。
别人一般怎么用（对照，三条就够）：
- 经典 RAG：
Document→ 切块 → Embedding → 进VectorStoreIndex（或外接向量库）→query_engine/as_chat_engine检索 + 生成 一条链。 - Agent / 工作流：
FunctionTool、ReActAgent、Workflow 等，检索/工具 是其中一步。 - 只摘 postprocessor 链（
SimilarityPostprocessor、SentenceEmbeddingOptimizer、LongContextReorder等）+ 自己组节点；「谁进候选、谁排第几」在业务层 / DB 里捞完，再交给 LlamaIndex 裁、排、句筛 ——【本项目/本仓库 实际走法】。
在官方/社区里，有时叫 cherry-pick 组件 或 postprocessor pipeline；数据源已经是业务库、不想 让框架托管全库索引时，很常见这么干。细节开关（compress_meta、embed_model 等）见 §2 / §3 与仓库 即可。
5. 本机 12G 那条线、Mac 上能跑、还有后面一个预告
-
和 第 2 篇 那台 12G / 三进程 的关系（收一句）：第 2 篇 讲的是 本机 算力与链 先通；本文 的 0/1/2 与在线摘要 不 跟「必须 在同一台 12G 上全链复刻」划等号；1 档 句向在你 任意开发机 上接 HF/本机已起的 embedding 也能试，成稿 与第 2 篇 别 重复长
nvidia-smi。2 档 若全堆本机 大模，显存/栈 又回去；本文主线 是 API 走摘要——和 §1 的「另一条线」一致。 -
Mac：这条「语义压缩 + 在线大模型、LlamaIndex 后处理、HF embedding」在 Mac 上 也能分开做实验、跑通；不 等于「没独显/没 12G 就勿入」； 与第 2 篇 以独显/三进程 为主 的叙事 是两条环境，读者各取即可。
-
几条线（量化、本机三进程、编排/捞上下文、语义压缩、在线 API）分开摸 过一轮之后，日常会打交道的 AI 相关库 粗讲 一句：LangChain / LangGraph、LlamaIndex、HF embedding、OpenAI 兼容 调用、FastAPI/业务 等，大面 上都碰过；不说 每块精通，是 脑子里有张能接着做东西 的地图。
-
先卖个关子：后面 会另起 一块 小作品——旅游 AI Agent，从设计到 轻量 可玩 的程度；不贴 逐行代码，只讲大致 怎么 用上前文这些积木 串起来；具体 长什么样、何时发，成稿/对外 再定，这里只 预告 一笔。
6. 收束
本周的「最小闭环」 先算达成了：主要时间 还是花在 本地模型 / 环境 的搭建上，但回头看 仍然很值。
四篇 从 说清 4bit 两套话，到 12G 本机全链，到编排/捞上下文，再到现在：语义压缩 + API——各管一层；本篇 不必 跟 12G 上全套 强绑，和 §1～§5 一处收。
后面 会啃一啃 Transformer、QLoRA 的底层原理，从看论文 起，分享一点 自己的读法/解读。先贷，敬请期待。
附录
下表为同系列 前三篇 的外链占位；发布到专栏/平台后 再填实际 URL 即可（当前先空着）。
| 篇 | 说明 | 链接 |
|---|---|---|
| 1 | INT4 与 Q4（GGUF）量化怎么选 | juejin.cn/post/763260… |
| 2 | 本机 12G：上下文链路、三进程 | juejin.cn/post/763247… |
| 3 | 推理与编排：捞上下文、LangChain / LangGraph | juejin.cn/post/763247… |
