LazyLLM 黑科技 | 给RAG装上C++涡轮：不改接口，性能直接起飞-CSDN博客

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

RAG Demo 跑得挺顺，一上真实数据量就开始“喘气”了。
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)