JoeSmile

深入理解 use 在服务端渲染中的角色，看懂 Promise 何时等待、数据如何流动，以及它在哪一环节真正提速。

一、引言：use 不是客户端数据请求工具

React 19 引入的 use API 是一个在渲染期间读取 Promise 或 Context 的原语。在 Next.js 等 RSC 架构下，典型用法是：Server Component 创建但不 await Promise，Client Component 用 use(promise) 挂起等待——这样 Server Component 本身不会被阻塞，页面可以更早开始流式输出。

当你发现「答案对了，但工具选错了」，才算真正开始调优 RAG 系统。

前言：别急着调模型，先建 Benchmark

我们的系统是一个世界杯数据问答 Agent：FastAPI → Workflow Router → simple_qa / complex_flow / gossip，底层是 pgVector fact card + 分析视图（vw_*），上层是 LangChain Agent + 三级 Query Cache（L1 内存 / L2 Redis 精确 / L3 语义）。

以世界杯知识问答系统为例，聊聊我对 RAG 评测的理解与实践

引言：为什么 RAG 系统尤其需要 Benchmark

在传统软件开发中，单元测试和集成测试已经是很成熟的实践。但对于 RAG（检索增强生成）系统，情况要复杂得多——我们不仅要验证代码逻辑是否正确，还要验证检索质量和生成质量是否达标。更棘手的是，大语言模型具有随机性，同样的输入在不同时刻可能给出不同的输出。

说明：下文「重试 / 降级 / 兜底」三分法是教学模型，便于分层设计；各团队 Runbook 里的叫法可能不同。代码基于 LangChain Core 0.3.x 的 Runnable API（with_retry / with_fallbacks）。

在企业级 RAG、Agent 系统上线后，大量线上故障往往来自下游依赖——第三方 API 超时、向量库连接抖动、工具调用异常、大模型限流……如果没有完善的重试、降级与兜底机制，单次依赖故障会直接传导到用户侧。

LangChain / LangGraph 提供了从单 Runnable 重试到全图状态化兜底的多层能力。本文梳理 5 套常用方案、一个常见 API 误区，并给出企业级组合架构与 MemoryOS 对照。

说明：下文以 LangChain / LangGraph 生态为主，兼写 企业自研 Registry + Executor 路线（如 MemoryOS）。RAG 上下文、用户记忆等常通过 Graph 节点 + system prompt 注入，与 Tool 并行，并非「一切能力都必须是 Tool」。

一、核心基础认知（必须吃透）

1. 工具本质：Tool 是 LLM 主动决定调用的外部能力接口；LLM 仅通过 name、description、参数 Schema 决策，看不到 handler 源码。
2. 与被动上下文的区别
   • Tool：模型输出 tool_calls 后才执行（如联网搜索、下单、查实时 API）
   • RAG / Memory：编排层在 call_model 前注入 system / 检索结果，不经过 tool_calls
3. 核心三要素
   • name：唯一标识，语义清晰
   • description：使用说明书，是选 tool 的核心依据
   • args_schema / JSON Schema：约束入参类型与必填项
4. Function Calling vs Tool
   • Function Calling：模型原生结构化调用指令
   • Tool（LangChain）：Runnable 封装；企业项目也常用 自研 ToolDefinition + OpenAI schema
5. 标准消息链路 用户提问 → LLM 生成 tool_calls → 执行 Tool → ToolMessage（带 tool_call_id）→ LLM 生成回答

在RAG系统中，Word、Excel这类富文本Office文件的提取常常被低估：很多团队直接用纯文本工具抽取出无格式的纯文字，丢失了标题层级、表格关系、图文关联，导致后续语义分块错乱、检索匹配失效、大模型幻觉频发。

做企业级RAG的团队大多踩过同一个坑：花了大量精力优化向量模型、调参分块策略、堆砌重排算法，最终却发现80%的回答误差来自最前端的PDF解析环节。

在RAG系统中，PDF解析是决定最终回答质量的「地基环节」。不同PDF Loader的能力边界差异极大：有的只擅长快速提取纯文本，有的能AI还原版面结构，有的专门处理扫描件。企业级落地从不会只依赖单一款Loader，都是采用「底层渲染+中层版面解析+上层专项增强」的分层组合方案。