SpringAI和 Langchain4j等 AI 框架之间的差异和开发经验

目录

• 1. 项目定位与生态
• 2. 核心抽象与编程模型
• 3. 模型与供应商支持（整体趋势）
• 4. 典型使用场景对比
• 5. 总结性对比表
• 6. 四个框架之间的关系
• 7. 市面上常见向量数据库选型
• 8. RAG 工作流 ASCII 示意图
• 9. Tools 的作用与调用关系
• 10. 经验：多模态大模型 + RAG 性能
• 11. MCP 总览与简化架构图

1. 项目定位与生态

• Spring AI

  • 由 Spring 官方维护的 LLM 集成项目（类似 Spring Data / Spring Cloud 的定位）。
  • 目标：为 Spring / Spring Boot 应用提供统一、供应商无关的 AI 接入抽象（Chat、Embedding、Image、工具调用等）。
  • 更关注“如何在 Spring 生态里用好 AI 能力”，而不是编排复杂 Agent / Chain。

• Spring AI Alibaba

  • 由阿里相关社区维护，在理念和 API 上与 Spring AI 高度对齐，通常视为“面向国内模型生态的增强版 Spring AI”。
  • 目标：更友好地支持中国境内常用的大模型服务（如阿里云通义等），提供本地化配置示例、文档和最佳实践。
  • 对国内网络环境、鉴权方式、地域/专有云等场景有更多封装和约定。

• LangChain4j

  • LangChain 的 Java 生态实现，偏“LLM 应用编排框架”，不依赖 Spring，本身就是一个通用 Java 库。
  • 目标：提供 Chain、Agent、Memory、Tool 以及对话状态管理等高级能力，用来构建复杂的 LLM 应用。
  • 可以与 Spring/Spring Boot 集成（有 Starter），但它的核心设计不依赖 Spring。

• LangGraph

  • 可以理解为在 LangChain / LangChain4j 之上的“图式工作流框架”，更关注对话/Agent 的有状态编排。
  • 目标：用节点（Node）和边（Edge）描述复杂对话流、决策树、多 Agent 协作等，把 LLM 应用抽象成可观测、可维护的“有向图”。
  • 在本项目中，可以把它看成是对 LangChain4j 的增强层，类似于 Spring 体系里「Spring AI Alibaba 之于 Spring AI」的定位。

2. 核心抽象与编程模型

• Spring AI

  • 核心抽象：ChatClient/EmbeddingClient/ImageClient等。
  • 强调“声明式 + 配置驱动”：通过application.yml配置模型供应商和参数，然后在代码里注入客户端使用。
  • 与 Spring Boot 深度集成：自动配置、@Bean、环境抽象、RestClient等。
  • 提供简单的工具调用 / Function Calling 支持，但不会强行引入“链式 DSL”。

• Spring AI Alibaba

  • 在 Spring AI 模型之上补充/增强供应商适配和 Starter，保持 Spring 风格不变。
  • 常见特征：
    • 针对国内 LLM 厂商提供 Boot Starter（依赖少量配置即可接入）。
    • 针对国内 API 的差异（签名、地域、SSE/流式协议）做适配。
  • 如果你已经熟悉 Spring AI，它基本上是“同一套编程模型 + 更多国内厂商支持”。

• LangChain4j

  • 核心抽象：ChatLanguageModel、StreamingChatLanguageModel、EmbeddingModel、AiServices、Tool等。
  • 提供“链式 / 组合式”编程模型，用代码装配 Prompt 模板、记忆模块、工具调用、路由等。
  • Agent / Chain / Memory 一等公民，更适合需要多步骤推理、复杂工作流的场景。
  • Spring 只是它的一个集成选项，你可以在纯 Java 项目、Micronaut、Quarkus 等环境中使用。

• LangGraph

  • 核心抽象：Graph、Node、State等，通常在节点内部使用 LangChain4j 的 Chain / Agent / Tool。
  • 编程模型：先定义状态结构，再通过“图 + 路由规则”描述对话流转，让复杂逻辑可视化、可拆分。
  • 更强调“有状态对话 + 分支/循环 + 人机协同”等高级模式，而不是单条链式调用。

3. 模型与供应商支持（整体趋势）

• Spring AI

  • 官方优先支持主流国际供应商（OpenAI、Azure OpenAI、Anthropic、Ollama 等），随后逐步扩展到其他厂商。
  • 追求统一配置和统一返回结构，便于在不同模型间切换。

• Spring AI Alibaba

  • 优先支持国内主流模型服务，对阿里云生态有最佳支持。
  • 为国内用户提供较好的开箱体验（示例、中文文档、演示工程等）。

• LangChain4j

  • 支持多家国际/国内模型，覆盖 Chat、Embedding、RAG、向量库等完整链路。
  • 对“供应商多样性 + 高级编排能力”关注度高，适合需要频繁试验不同模型 / 检索方案的团队。

• LangGraph

  • 模型与向量库等底层能力全部复用 LangChain4j，理论上支持 LangChain4j 能接入的所有厂商。
  • 更关注“如何把这些能力编排成可观测的工作流”，而不是新增模型适配。

4. 典型使用场景对比

• 如果你主要是 Spring Boot 应用，希望：

  • 简单地在现有微服务里调用 LLM（问答、摘要、分类、简单 RAG）。
  • 利用现有的 Spring 生态（配置、监控、安全、云原生环境）。
  • 需要的是“稳定的生产级集成方式”，而不是复杂的 Agent。
  • 优先选：Spring AI；国内模型优先时可考虑 Spring AI Alibaba。

• 如果你主要面向国内模型生态，且：

  • 使用阿里云等国内大模型服务为主。
  • 希望官方示例、中文文档、本地化配置更完善。
  • 需要跟 Spring 保持一致风格，同时解决国内网络/环境的细节问题。
  • 优先选：Spring AI Alibaba（通常仍然基于/兼容 Spring AI 体系）。

• 如果你需要构建复杂 LLM 应用，希望：

  • 做 Agent、多步推理、工具调用编排、复杂 RAG 和工作流。
  • 在 Java 世界里获得与 Python LangChain 相近的能力。
  • 框架独立，可运行在非 Spring 环境甚至桌面/命令行应用中。
  • 优先选：LangChain4j，并按需与 Spring Boot 集成。

• 如果你的应用已经比较复杂，希望：

  • 对话中存在大量条件分支、循环、人工干预（例如：客服流转、审批流、跨系统编排）。
  • 需要把多个 Agent / 工具 / RAG 流程组织成一个整体工作流，且希望后续能可视化、可观测。
  • 希望在 LangChain4j 的基础上，获得更清晰的“状态 + 流程图”编码体验。
  • 优先选：在 LangChain4j 之上叠加 LangGraph（LangChain4j 负责能力层，LangGraph 负责流程层）。

5. 总结性对比表

粗略理解：

• Spring AI：Spring 里的“LLM 驱动层”
• Spring AI Alibaba：Spring AI 在国内模型生态上的增强版
• LangChain4j：Java 版 LangChain，用来编排复杂 AI 应用
• LangGraph：基于 LangChain4j 的有状态 Agent / 工作流图框架

6. 四个框架之间的关系

• 按生态阵营划分

  • Spring 生态线：Spring AI（官方 LLM 接入层） ←Spring AI Alibaba（面向国内模型的增强版）。
  • LangChain 生态线（Java）：LangChain4j（通用编排框架） ←LangGraph（图式工作流 / 有状态 Agent 增强层）。

• 一张关系小图（抽象示意）

Spring 生态（接入层） LangChain 生态（编排层，Java） Spring Boot / Spring Cloud 应用 任意 Java 应用 / 服务 │ │ ▼ ▼ +-----------+ +--------------+ | Spring AI | | LangChain4j | +-----------+ +--------------+ │ │ （增强国内模型支持 / 本地化） （增强有状态 Agent / 工作流） ▼ ▼ +---------------------------+ +------------------------+ | Spring AI Alibaba（CN） | | LangGraph（on LC4j） | +---------------------------+ +------------------------+

• 按层次角色划分

  • 接入层：Spring AI、Spring AI Alibaba主要解决“如何在 Spring 应用里接好模型、配好参数、跑在生产环境中”。
  • 编排层：LangChain4j、LangGraph主要解决“如何把模型 + 工具 + 向量库编排成复杂的对话/工作流”。

• 增强关系（纵向类比）

  • Spring AI Alibaba之于Spring AI：在保持 Spring AI 编程模型的前提下，加强国内模型厂商支持和本地化体验。
  • LangGraph之于LangChain4j：在保持 LangChain4j 能力的前提下，引入图式状态机，让复杂 Agent / 对话流程更易表达与维护。

• 在本仓库中的推荐使用方式

  • 如果你是 Spring 团队，想先把 LLM 接入到现有服务：从Spring AI/Spring AI Alibaba入手。
  • 如果你想进一步做复杂多轮对话、Agent 编排：在模型接入稳定后，引入LangChain4j，并按需叠加LangGraph做工作流编排。

7. 市面上常见向量数据库选型

7.1 云托管型：Pinecone

• 适用场景
  • 不想自己运维，只希望“直接调用 API 就能用”的 RAG、语义搜索、推荐等大规模在线服务。
• 特点
  • 完全托管 SaaS，自动扩缩容，多副本、高可用；支持向量 + 元数据过滤、分库分表等。
• 优点
  • 基本零运维；可支撑大规模数据和高 QPS；生态成熟（SDK、多种平台集成）。
• 缺点
  • 成本相对高；厂商锁定明显；对国内用户网络/延迟不一定友好。

7.2 自托管专用向量库

7.2.1 Milvus / Zilliz Cloud

• 适用场景
  • TB 级数据、大规模 RAG / 语义检索、推荐系统；需要私有化或国产化部署的企业场景。
• 特点
  • CNCF 开源项目，多种向量索引（HNSW、IVF、DiskANN 等），支持水平扩展；Zilliz Cloud 提供托管版。
• 优点
  • 性能强，社区活跃；生态成熟（SDK、可视化工具、与 RAG 框架集成好）；适合企业级生产环境。
• 缺点
  • 集群部署和运维相对复杂（依赖组件较多）；对小规模项目而言可能显得“过重”。

7.2.2 Qdrant

• 适用场景
  • 需要高性能、强过滤能力，又希望部署简单的在线向量检索服务。
• 特点
  • Rust 实现，单机性能好；支持向量 + 结构化过滤、多租户、持久化；提供集群模式。
• 优点
  • 部署轻量、依赖少；性能和性价比好；API 设计友好。
• 缺点
  • 生态和社区规模略小于 Milvus；高级工具链相对少一些。

7.2.3 Weaviate

• 适用场景
  • 既需要知识图谱/对象建模，又要向量检索和混合检索（文本 + 向量）的知识库场景。
• 特点
  • 类“图 + 向量”的数据库，有 schema / class / 属性；内置 BM25 + 向量混合检索和一些扩展模块。
• 优点
  • 适合面向“实体/对象”的语义知识库；混合检索能力好；文档比较完善。
• 缺点
  • 架构偏重；对 schema 与类的建模有学习成本；国内社区相对较小。

7.3 通用数据库的向量扩展

7.3.1 PostgreSQL + pgvector

• 适用场景
  • 已经大量使用 Postgres，希望在一个库里同时管理结构化数据和向量（中小规模 RAG、语义搜索）。
• 特点
  • 通过 pgvector 扩展在 Postgres 中直接存向量，支持索引和相似度查询；使用 SQL 写检索逻辑。
• 优点
  • 部署简单，可复用现有 Postgres 运维体系；事务、备份、权限等能力齐全；方便做“向量 + 业务数据”的联合查询。
• 缺点
  • 面向超大规模向量和极高 QPS 时性能有限；索引和存储成本偏高；向量算法选择比专用向量库少。

7.3.2 Elasticsearch / OpenSearch（向量检索）

• 适用场景
  • 原本就用 ES/OS 做全文检索，希望顺带支持语义搜索/向量检索，而不想引入额外组件。
• 特点
  • 向量字段 + 近似 kNN；可以同时用 BM25 + 向量打分做混合检索。
• 优点
  • 一套集群同时搞定全文 + 结构化 + 向量；生态成熟、运维经验丰富。
• 缺点
  • ES 本身较重，资源消耗大；向量检索属于“附加能力”，在极端性能/延迟场景不如专用向量库。

7.3.3 Redis / Redis Stack（RediSearch 向量）

• 适用场景
  • 对延迟极度敏感、数据量中小、数据适合放在内存里的场景（对话短期记忆、session 级向量缓存等）。
• 特点
  • 在 Redis 中为文档增加向量字段，并建立向量索引；全部在内存里计算。
• 优点
  • 延迟极低，开发简单；可顺便利用 Redis 的缓存、TTL、发布订阅等能力。
• 缺点
  • 内存成本高、容量受限；不适合超大规模数据；复杂检索需求时维护成本上升。

7.4 原型/本地开发常用：Chroma 等

• 适用场景
  • 本地快速搭建 RAG Demo、PoC、小工具，尤其是 Python 场景。
• 特点
  • 内嵌/本地向量库，零运维、安装简单，常与 LangChain 等框架深度集成。
• 优点
  • 上手非常快，适合验证想法和小规模项目。
• 缺点
  • 不适合生产级、分布式和高可用场景；多语言支持和生态相对弱。

7.5 简单选型建议

• 如果数据量和并发都很大，且是长期的核心业务：
  • 优先考虑 Milvus / Zilliz、Qdrant、Weaviate 等专用向量库；不想运维时可以考虑托管服务（如 Zilliz Cloud、Pinecone）。
• 如果团队已有稳定的 Postgres 或 ES 集群，且规模中小：
  • 优先考虑 Postgres+pgvector 或 Elasticsearch/OpenSearch 的向量能力，减少新组件。
• 如果对延迟极度敏感、数据规模不大：
  • 可以考虑 Redis 向量能力，用作对话短期记忆或 session 级缓存。
• 如果只是本地开发、实验或 PoC：
  • 使用 Chroma 等本地向量库即可，后续再迁移到生产级向量数据库。

8. RAG 工作流 ASCII 示意图

RAG 工作流（与上方示意图中的节点和箭头一一对应） [文档] --切分--> [chunks] --Embedding--> [向量数据库] 用户 -----------------------> [问题] --Embedding--> [向量] --检索--> [向量数据库] ^ | | | | v | | [context] | | | | +---------------------------> [prompt] <-------+ | | | v +--------------------------- response ------------------------ [LLM]

9. Tools 的作用与调用关系

9.1 Tools 是什么？

• 在 Spring AI、LangChain4j、LangGraph 等框架中，Tools（工具调用 / Function Calling）本质上是：
  • 一组由开发者实现的“受控函数”，对外暴露清晰的名称、入参和返回值；
  • 这些描述会以结构化方式（schema）告诉大模型，让大模型在需要时主动“调用函数”，而不是只靠自然语言胡乱猜。
• 作用可以概括为：
  • 把“只能聊天的模型”升级成“能调用系统能力的智能体”（查库、HTTP 请求、执行业务逻辑等）；
  • 明确模型可用的能力边界，降低安全风险和幻觉（模型必须通过 Tools 才能动数据）。

9.2 Tools 与程序、模型之间的关系（ASCII 示意）

业务代码 / 应用程序 │ │ 调用 v [ChatClient / Agent] │ 自然语言对话 / Tool 调用协议 │ v [LLM / Model] │ （根据工具描述决定是否调用某个 Tool） │ function call v [Tools：Java 方法等] │ ┌─────────────┼──────────────┐ v v v 数据库 向量数据库 第三方 API

• 对开发者：
  • 只需要用代码实现好 Tools（例如 Spring Bean / Java 方法），并按框架要求暴露出去；
  • 其余工作（向模型暴露 tool schema、解析 function_call、执行并把结果回填给模型）由框架负责。
• 对模型：
  • 它只“看见”一个个带说明文档的工具列表，按需要选择调用哪些工具、以什么参数调用。

10. 经验：多模态大模型 + RAG 性能

10.1 为什么多模态 + RAG 会更慢？

• 模型本身更“胖”

  • 多模态模型 = 文本 LLM + 图像/音频编码器 + 对齐模块，参数更多、推理图更复杂。
  • 即便没有传图片/音频，这套结构仍然要跑，单 token 计算量几乎一定大于同家族的纯文本模型。

• RAG 带来的额外链路

  • 相比“直接聊天”，RAG 多了几步：问题 Embedding、向量库检索、拼接 context，再交给模型生成。
  • 每一步都增加一定延迟，当最终调用的是本来就偏慢的多模态模型时，整体响应会更慢。

• 上下文更长，计算量线性变大

  • 多模态模型上下文窗口通常更大，RAG 又会把检索到的 chunks 全部拼进 prompt。
  • LLM 的复杂度大致随“输入 token + 输出 token”线性（甚至略高）增长，长上下文 + 大模型 = 显著变慢。

• 服务端策略和资源调度

  • 厂商往往对多模态模型设置更保守的速率限制，或者放在资源更紧张的集群中。
  • 即使用的是同版本号，实测首 token 延迟和整体吞吐通常都不如纯文本模型。

10.2 实战中的使用建议

• 只做文本对话（包含 RAG）时

  • 优先选择对应的纯文本大模型版本（例如同家族的 text-only 模型），多模态模型保留给确实需要“看图/看表”的场景。

• 拆分 Embedding 模型与对话模型

  • 文档向量离线用专门的 embedding 模型计算，在线查询时也用轻量的 embedding 模型。
  • 最终回答使用一个高效的文本对话模型，而不是多模态模型。

• 控制 RAG 的负担

  • 合理设置 topK、chunk 大小和拼接策略，避免每轮调用塞入过多 context。
  • 对长对话定期做“总结压缩”，减少历史消息 token 数量。

• 区分文本请求和多模态请求

  • 在网关或业务层按请求类型路由：纯文本走文本模型，多模态任务（图文问答等）才调用多模态模型。

11. MCP 总览与简化架构图

11.1 MCP 是什么？

• MCP（Model Context Protocol）是用来规范“大模型 ↔ 外部工具 / 资源 / 提示模板”交互的开放协议。
• 核心思想：
  • 把 Tools、Resources、Prompts 抽象成一个标准化的“能力服务”（MCP Server）；
  • 任何支持 MCP 的客户端（包括 Spring AI、编辑器插件、命令行工具等）都可以发现并调用这些能力；
  • 协议本身与具体模型厂商无关，仅定义消息格式与传输方式（stdio / SSE / HTTP 等）。

11.2 程序 - 大模型 - MCP 的简化架构（ASCII 示意）

用户 / 业务调用 | v +--------------------+ | 应用程序 / 服务 | | (Spring Boot 等) | +---------+----------+ | | 自然语言请求 (chat) v +--------------------+ | LLM 客户端层 | | (Spring AI 等) | +---------+----------+ | | 1. 调用大模型，携带可用工具描述 v +---------+ | LLM | | Model | +----+----+ | | 2. 模型决定调用某个外部 Tool | （function_call / tool_call） v +--------------------+ | MCP Client | +---------+----------+ | | 3. 按 MCP 协议转发调用 v +--------------------+ | MCP Server | | (工具与资源服务) | +---------+----------+ | +---------+----------+ | DB / 向量库 / API | +--------------------+

• 应用只需要面向 LLM 客户端层（如 Spring AI）编写对话逻辑；
• LLM 通过 MCP Client/Server 访问统一的工具与数据，不再被某个应用或厂商的专有 Tool 定义锁死。

11.3 MCP 中的 Tools / Resources / Prompts 是什么？

• Tools

  • Tools 是 MCP 里的“执行者”，让 LLM 不只是嘴炮，还能干活。简单说，就是服务器提供一些函数或者 API，LLM 可以直接调用去完成具体任务。
  • 面向“动作/调用”的能力，类似一组可以被模型调用的受控函数或命令；
  • 每个 Tool 有名称、说明和参数 schema（通常是 JSON Schema），返回结构化结果；
  • 常用于查数据库、查向量库、调用业务接口、触发工作流等。

• Resources

  • 相当于给 LLM 提供“原材料”；服务器（MCP Server）把这些数据暴露出来，客户端（比如 LLM 应用）可以读取它们，然后塞进模型的上下文里去推理或者生成内容。比如你有个日志文件 app.log，通过 Resources 就能让 LLM 直接看到里面的错误信息。
  • 面向“数据/文档”的只读资源抽象，可以理解为受控的“文件 / 文档 / 记录”视图；
  • 客户端可以枚举可用资源，或按标识读取具体内容；
  • 适用于暴露说明文档、配置、知识库条目等，而不直接开放底层数据库或文件系统。

• Prompts

  • Prompts 是 MCP 的“模板大师”，提供预定义的交互模式或者推理指引。可以说它是 LLM 的“剧本”，告诉它怎么开口、怎么思考。
  • 服务器定义好一堆 Prompt 模板（比如“写个产品描述”或者“调试错误”），客户端可以直接选一个，填入参数，然后丢给 LLM 执行。
  • 面向“提示/模板”的能力，用于集中管理系统提示、角色设定、任务说明等；
  • 支持变量占位符，客户端在使用时填充具体内容；
  • 多个应用可以复用同一套提示模板，避免在各处复制粘贴提示词。

三者的关系可以简单理解为：

• Tools：负责“做事”；
• Resources：负责“提供数据”；
• Prompts：负责“指导模型如何理解任务及如何使用前两者”。

面试流程的类比示例

以“技术面试流程”为例，可以这样理解：

• 如果把模型当成一个“面试助理”，那么：
  • Tools 像是它可以执行的一系列操作按钮：
    • 安排面试时间：调用日程系统给候选人和面试官找共同空档，并创建日历事件；
    • 更新候选人状态：把候选人标记为“已初面 / 待终面 / 已发 Offer”等；
    • 记录面试反馈：把面试官的打分和评语写入招聘系统。
  • Resources 像是它随时可以查阅的资料库：
    • 候选人的简历、作品集、测评结果；
    • 岗位 JD、团队介绍文档；
    • 公司统一的面试流程和评估标准说明。
  • Prompts 则像是给这位“面试助理”的工作手册和话术模板：
    • 系统提示：你是一名严谨的技术面试助理，要根据岗位 JD 和面试标准帮助面试官做判断；
    • 模板提示：根据候选人表现，用专业但礼貌的语气生成一份面试反馈邮件；
    • 变量占位：{候选人姓名}、{岗位名称}、{面试结果}等在使用时再填充。

在这个类比下：

• Tools 让助理“能真正动手做事”（排期、更新系统）；
• Resources 让助理“心中有数”（了解候选人和岗位、知道公司规则）；
• Prompts 让助理“说对话、按对的流程办事”（用合适的风格和步骤执行面试相关任务）。

12. RAG 场景下常见的文档切分策略

在spring_ai_alibaba-demo/src/main/java/com/zhoubyte/spring_ai_alibaba_demo/rag/RagChatClientController.java中，使用的是TokenTextSplitter对输入文本进行切分并写入PgVectorStore。这里补充几种常见的文档切分方案，方便在不同业务中进行选择。

12.1 TokenTextSplitter 参数说明

代码示例：

TokenTextSplittertokenTextSplitter=TokenTextSplitter.builder().withChunkSize(50).withKeepSeparator(true).withMaxNumChunks(1024).withMinChunkLengthToEmbed(20).withMinChunkSizeChars(10).build();

核心参数含义（结合源码推断）：

• chunkSize：每个分片的最大 token 数（基于 jtokkit 进行编码），控制单个 chunk 的上下文长度。
• minChunkSizeChars：在选择切分位置时，最小字符数阈值，用来避免切得过碎（比如刚好在换行符前切断）。
• minChunkLengthToEmbed：最终参与 embedding 的最小长度，小于该长度的分片会被丢弃，不入库，减少噪声与向量数量。
• maxNumChunks：单个输入允许生成的最大分片数，防止一次性上传超长文档产生过多 chunk。
• keepSeparator：是否保留换行符等分隔符；保留有利于维持段落/格式信息，不保留则更“干净”。

优点：

• 以 token 为单位切分，能更精确地控制接近模型上下文窗口（比如 512、1024 tokens）的尺寸。
• 适合中英文混合文本，不需要显式处理多语言的字符长度差异。
• 搭配minChunkLengthToEmbed可以自动过滤过短噪声，减少向量存储与检索开销。

缺点：

• 需要依赖 tokenizer（jtokkit），实现复杂度高于简单字符分割。
• 默认不会显式感知“语义边界”（句子、段落、标题），可能在中间切断语句。

适用场景：

• 已经明确使用某个 LLM 的 token 限制（如 4k/8k/32k），希望严格控制 chunk 大小的通用 RAG 场景。
• 知识库文本结构不算特别规整（例如 FAQ、Chat 记录等），更关心“上下文长度”而非完美的段落边界。

12.2 其它常见文档切分方案概览

下面几类方案是 RAG 项目里最常用的文档切分思路，可以在 Spring AI 中通过自定义TextSplitter或自定义DocumentTransformer来实现，在 LangChain4j 等框架中也有类似抽象。

一些实践经验：

• 如果只是做 RAG Demo 或内部小工具：优先用TokenTextSplitter或简单“固定字符长度 + 小重叠”的方案即可。
• 如果面向生产、且文档是 Markdown/手册类：可以考虑“结构化层级切分（标题/段落优先） + Token 级限长”组合。
• 如果业务对召回准确性要求非常高（如法律、金融风控）：可尝试在关键文档上使用“语义切分”，但要接受更高的计算和实现成本。