你可能也遇到过这种场景：

1.RAG Demo 跑得挺顺，一上真实数据量就开始“喘气”了。

2.CPU 飙高、延迟抖动、吞吐不稳，最后大家开始怀疑人生：到底是模型慢，还是框架本身在拖后腿？

这次我们在 LazyLLM 做的事情，就是把 RAG 里最容易“卡脖子”的底层路径，用 C++ 扩展重新打磨了一遍，同时保证 Python 侧用法基本不变。

1. 业界 RAG 框架常见的经典问题

RAG 真正慢的地方，很多时候并不在“大模型推理”本身。

常见瓶颈通常是：

- 文本切分、节点构建、节点序列化/反序列化这类“高频小操作”非常多，Python 对象开销会被放大。

- 数据一大后，检索前后的数据搬运成本飙升，尤其是 node / chunk 在内存、存储、索引之间来回转换。

- 多线程并发时，经常出现吞吐没上去、上下文切换和锁竞争却上去了。

- 一旦要做优化，最怕的是“加速了，但行为变了”，线上结果和历史结果对不上。

2. 这些问题为什么难搞

难点不是“写一段更快的代码”，而是三件事要同时成立：

- 要快：热点路径得真能提速。

- 要稳：不能破坏现有 Python 语义和生态。

- 要可扩展：用户还能按原有方式自定义 splitter、transform、store 行为。

RAG 不是单点算法，而是一条链路。

你优化一个环节，可能影响到另一个环节的数据结构和行为边界。

所以这件事本质是“系统工程”，不是单纯“把 Python 改成 C++”。

3. 我们采用了什么方案

我们用了“渐进式 C++ 化”策略，而不是激进重写：

- 用户侧：用环境变量开关控制是否启用 C++ 覆盖：

export LAZYLLM_ENABLE_CPP_OVERRIDE=1

- LazyLLM开发侧：同时提供两种接入模式：

- - @cpp_class 类装饰器：整类替换（适合稳定核心对象，如 DocNode）
- - @cpp_proxy 类装饰器：方法代理（适合需要保留 Python 多态扩展的模块，如 splitter）

这意味着LazyLLM可以“按模块分批提速”，不是一次性大迁移。

4. 架构设计与技术剖析

4.1 三层架构：core / adaptor / binding

在构建层面我们明确拆成三层：

- core：纯 C++ 核心逻辑（DocNode、Tokenizer、Splitter 等）

- adaptor：跨语言桥接（例如 Python store 回调）

- binding：pybind11 导出层（Python API 映射）

核心哲学：core 与 binding 分离。

算法和数据结构不绑定 Python 细节，后续演进更稳。

4.2 DocNode：用 @cpp_class 做“整类替换”

# lazyllm/tools/rag/doc_node.py
@cpp_class
class DocNode:
    ...

这是“核心对象强下沉”策略。

原因很直接：DocNode 是高频数据结构，调用密度高、生命周期长，整类替换收益最大。

4.3 TextSplitterBase / SentenceSplitter：用 @cpp_proxy 做“热点代理”

# lazyllm/tools/rag/transform/base.py 
@cpp_proxy(funcs_to_override=['split_text', '_merge'], cpp_method_aliases={'_merge': 'merge_chunks'})
class _TextSplitterBase(...):
    ...

# lazyllm/tools/rag/transform/sentence.py
@cpp_proxy(funcs_to_override=['_merge'], cpp_method_aliases={'_merge': 'merge_chunks'})
class SentenceSplitter(_TextSplitterBase):
    ...

这套做法的关键点是：

热点方法走 C++，但 Python 类本体还在。

如果用户子类重写了 _split/_merge，框架会自动保留 Python 多态行为，不会粗暴覆盖。

4.4 三方依赖统一声明

依赖统一放在 csrc/cmake/third_party.cmake，包含 pybind11、xxHash、cpp_tiktoken、utf8proc 等，避免散落管理和隐式依赖。

4.5 用string_view代替string

cpp中的std::string_view 只是“指向原文的一段视图”，不拷贝内容。

为什么这比 std::string 更好

假设一篇 200MB 文档先被切成 50,000 个候选片段：

- 用 std::string：每个片段都会分配+拷贝，额外数据拷贝量大约再来一份（接近 200MB），还会有 50,000 次小对象分配。

- 用 std::string_view：只存指针+长度。每个 view 约 16 字节，50,000 个大约 0.8MB，几乎零拷贝。

也就是：内存峰值更低、分配次数更少、CPU 花在 memcpy/allocator 的时间更少。

这在 RAG 的“反复切分+递归切分”路径上非常明显。

// csrc/core/include/text_splitter_base.hpp
std::vector<std::string_view> TextSplitterBase::split_text_while_keeping_separator(
    const std::string_view& text,
    const std::string_view& separator)

5. 总结

这次 C++ 扩展不是“炫技式重写”，而是一次工程化升级：

- 结构上：三层架构清晰解耦。

- 接入上：@cpp_class + @cpp_proxy 双模式兼顾性能与扩展。

- 语义上：优先保持 Python 行为一致，再追求极致性能。

- 路线上：先打核心，再逐步扩大到存储和检索热点。

简单说，就是让 RAG 在真实业务里“跑得更快、改得更稳、扩得更久”。

欢迎升级体验 LazyLLM 最新版本，请大家去 github 上点一个免费的 star，支持一下～

LazyLLM 项目仓库链接🔗：

https://github.com/LazyAGI/LazyLLM

https://github.com/LazyAGI/LazyLLM/releases/tag/v0.7.1