全球首发：第二代 RAG 系统 auto-coder.rag 相比市面主流RAG系统 20%-60% 效果提升

先看评测结果

基本效果上全面碾压当前市面上某主流的一代 RAG 系统。我们在文末会放出评测数据集以及问题，使用流程。欢迎大家和其他 RAG 系统做对比，并且发出自己的评测结果。

在 9月13号，我们又新增了五道更加困难的题目，更加拉开了差距：

下面是一些评测要求和指导：

用户好评

有用户第一时间应用于编程的文档库召回，反馈效果：

也有人第一时间用来给黑神话悟空做攻略：

还有人来做 Linux 内核分析：

效果很好，第一时间在小红书推荐了我们产品：

第一代RAG 系统

要搞第一代 RAG 系统,大模型，向量模型，向量存储这三个是标配，接着呢，为了让效果变得更好, 就要继续加，先来个 rerank 模型，提高下精度，向量存储不够，再加个全文检索，做混合多路召回。瞬间就把系统复杂度拉满，然后又要开始做资源隔离，做运维了，保证多系统协同工作，高可用 balabala...

光把系统搞复杂是不够的，应用也要搞复杂！效果还不行，引入llama_index，这个库提供了上百种存储，召回策略，搞 oneapi, 这系统封装了无数个大模型接口。

接着发现，开发应用还是太复杂了，要不再引入个 workflow ，减轻下开发的压力，把一些工作转移给业务？然后成功转移，大家都有活干。

最后，又发现和以前大数据时代一样的问题，实时性好像不太好搞了，得搞个实时系统啊，那得再加kafka,全量批量更新向量数据库 继续折腾中。。。

当然，前面的问题还不是根本。

第一代 RAG 系统根本问题是：

以 chunk 为粒度，使用emb召回的系统，存在严重的信息损耗，并且基本不可解决。这个损耗包括：

1. 数据切片导致的信息丢失

2. 召回过程中存在chunk 同质化严重（比如topN 的chunk 可能都是类似的话)

3. chunk 的排序导致人为的将数据打乱，极大的干扰了大模型的理解

这些问题是一代RAG系统的基因问题，很难通过革新来解决，必须推倒重来。

此外，天花板还低：

1. 依赖的 emb/rerank 模型自身提升上限很低

2. 效果想要好，严重依赖人工做定制

第二代 RAG 系统: auto-coder.rag

auto-coder.rag 是一个完全 llm-native 的 RAG 系统，依托于 Deepseek 支持大窗口，高并发，成本低廉的优势以及我们自身的算法创新，实现了突破性的效果提升。不破不立，我们完全摒弃了一代RAG中的技术栈诸如向量数据库，向量模型，各种存储加工策略，召回策略等。

auto-coder.rag 无需复杂的数据预设计和处理，全流程大模型驱动，通过暴力美学完成计算。

整体流程大致分成三部分：

1. 根据 query 过滤动态文件

2. 根据 query 排序，通过窗口分区来填充信息

3. 最后基于新的信息对 query 进行解答

auto-coder.rag 创新性包括：

1. 整体实现了百K token 输入, 个位数 token 输出，可以充分利用GPU算力，避开 decode 部分的限制，给大模型推理厂性能优化提供较大的空间，上限极高。
   

2. 通过工程优化极限命中 deepseek 缓存,缓存和miss token比例为2:1,降低成本。

2. 首创对 deepseek 的128k窗口分区管理（类似内存分区管理），提供了文件区，片段区，系统buff区，最大限度了利用了窗口以及保证对信息的覆盖的完整性。

应用场景

RAG 系统几乎是大模型在企业级市场落地的基础，也是盘活企业数据最重要的一个环节。举个简单的例子，NL2SQL 最依赖的能力实际上是表召回，以及上下文召回（诸如示例，企业术语，黑话）。可以看到，一个NL2SQL系统至少需要用到两个知识库实例，知识库的准确率直接决定过了NL2SQL的准确率。

快速体验

多说无益，大家可以快速通过自己的数据来体验：

pip install -U auto-coder
auto-coder.rag serve \--tokenizer_path <你下载的token文件路径> \--rag_doc_filter_relevance 2 \--doc_dir <你文档的路径>

其中 tokenizer.json 可以在下面地址中下载：

https://modelscope.cn/datasets/WilliamZhu/auto_coder_rag_financial_report 

文档路径为一个绝对路径的目录。里面支持的文件类型包括: excel, ppt,pdf, word 以及任意文本。

启动过程中会让大家填写 deepseek token，大家可以去官网申请一个。

现在，你可以使用 OpenAI SDK 来访问：

from openai import OpenAIimport json
client = OpenAI(api_key="xxxx", base_url="http://127.0.0.1:8000/v1")
response = client.chat.completions.create(messages=[ {"role": "user","content": "董事会审议通过的利润分配预案为：以2,968,907,902股为基数 这个数字准确么？"}],model="deepseek_chat",)print(response.choices[0].message.content)

你也可以使用 OpenAI  SDK 的流式输出。

如果你喜欢用客户端，可以使用 NextChat 之类的客户端软件：

评测数据集，测试问题 下载地址

大家也可以自行下载我们的评测数据集以及我们测试的问题，进行效果验证。

地址： 

https://modelscope.cn/datasets/WilliamZhu/auto_coder_rag_financial_report

<开源版>费用以及速度

1.  测试数据集首次提问，大概7-8块钱。

2.  测试数据集命中缓存后，3-4块钱

3.  回答速度取决于 Deepseek 的当前的负载，单次请求一般 1-3分钟，通常第一次使用时间较长，后续会明显变快,如果当前用户较大很忙，可能时间会很长(5分钟+)。

4. NextChat 客户端无法配置超时，所以第一次请求有可能会超时，通常第第二次就会正常。如果数据规模较大，可以直接使用 OpenAI SDK 或者其他客户端。

4. 我们允许高级用户不同阶段使用不同的模型，从而在成本，速度和效果获得一个较好的平衡。

<开源版>单实例数据规模

推荐当前一个实例总token数不要超过 600w。auto-coder.rag 启动的时候会帮你计算总 token 数。

此外，对于单个文件，你还可以用我们的工具来计算 token:

auto-coder.rag tools count \--tokenizer_path /Users/allwefantasy/Downloads/tokenizer.json \--file /Users/allwefantasy/data/yum/schema/schema.xlsx

细节点：

1. 单文档最好是在 100-110k token之间， token 和 字符的换算比例 1:1.5 到 1:2，也就是不能超过200k 字符。超过了建议写个程序拆分下，太小，建议做个合并。

2. 文档数目前不要超过千个。