Banxian | 王半仙的 RSS 预览

DeepSeek-OCR 基于视觉模态的长文本压缩与识别

2025-11-05 14:30:00

中文标题：DeepSeek-OCR：上下文光学压缩

英文标题：DeepSeek-OCR: Contexts Optical Compression

发布平台：预印本

发布日期：2025-10-21

引用量（非实时）：

DOI：10.48550/arXiv.2510.18234

作者：Haoran Wei, Yaofeng Sun, Yukun Li

关键字： #DeepSeek-OCR

文章类型：preprint

品读时间：2025-11-05 14:29

1 文章萃取

1.1 核心观点

本文借助 DeepSeek-OCR 的研究，对视觉 token 压缩文本的可行性进行了初步研究；DeepSeek-OCR 模型以 DeepEncoder 作为核心组件，实现了高分辨率输入下的低激活开销，确保视觉 token 的数量保持着合理范围；MoE 解码器将DeepEncoder 编码压缩后的信息进行原始文本表示的还原，验证了视觉 token 相对传统文本 token 的信息优势

最终实验表明，相对于文本 token，视觉 token 在保持 10 倍压缩比的情况下，依然能够实现 97%的解码（OCR）精度；而 DeepSeek-OCR 模型也展现出来较高的实用价值，在多样化文档解析的测试中取得了明显优势，在生产环境中单 GPU（A100-40G）能够每天实现 20w+页面的高质量解析

1.2 综合评价

论文针对视觉 token 的研究值得深入的思考与研究

模型的 OCR 性能出众，使用方式灵活，实用价值高

模型架构设计创新较少，主要沿用已验证成熟方案

1.3 主观评分：⭐⭐⭐⭐⭐

2 精读笔记

2.1 前置知识

前置知识：SAM（2023）

由 Meta 提出的 Segment Anything Model，经典的图像分割模型
SAM 主要包含一个基于 ViT 架构预训练的图像编码器（计算图像嵌入），一个多类型提示编码器（计算提示嵌入，支持点、框和文本等类型），一个带有动态掩码预测头的轻量级掩码解码器（实时预测每个位置的掩码概率）
SAM 是一个具备里程碑意义的图像分割模型，其零样本泛化能力十分惊艳

前置知识：CLIP（2021）

由 Open AI 团队提出的基于对比学习的文本-图像对预训练模型
CLIP 基于海量图像文本（低质量）对进行弱监督训练，实现了较强的zero-shot性能，可以作为预训练模型迁移到图像生成领域

已有的经典视觉编码方案：

以 Vary （左图）为代表的双塔架构：利用并行 SAM（Segment Anything Model）编码器来增加视觉词汇参数，用于高分辨率图像处理；缺点是需要双图像预处理，部署复杂，并行训练困难
以 InternVL2.0 （中间）为代表的图块方法，通过将图像分成小图块进行并行计算来处理图像，从而减少高分辨率下的激活内存；缺点是原始编码器分辨率过低（< 512 × 512），并且过度碎片化的图像导致大量的视觉 token
以 Qwen2-VL （右图）为代表的自适应分辨率编码，它采用 NaViT 范式，基于补丁（patch）的分割直接处理全图像，无需碎片并行化，灵活支持不同的分辨率；缺点是激活内存消耗大，容易导致显存移除，同时不适用于图像较大的情况

端到端 OCR 方案

伴随着 VLM 的发展，端到端 OCR 成为目前 OCR 系统的主流方案
Nougat（2023）首先在 arXiv 学术论文中采用端到端 OCR 框架，展现了模型在专业文档方面的的 OCR 性能潜力（尤其是针对数学公式）
GOT-OCR2.0（2024）是一款综合功能丰富的端到端 OCR 模型，能够处理文本、图表和乐谱等多种类型的输入，并进行丰富格式的输出，模型中各项 OCR 任务中表现出色
Qwen-VL、InternVL 等通用视觉模型也在不断增强文档 OCR 能力，探索视觉感知的边界

2.2 算法架构

DeepSeek-OCR 由一个 DeepEncoder 和一个 DeepSeek-3B-MoE 解码器组成

DeepEncoder 是 DeepSeek-OCR 的核心，包含主要三个组件：

SAM-base 架构，用于以窗口注意力为主的视觉感知特征提取
CLIP-large 架构，用于具有密集全局注意力的视觉知识特征提取；由于输入不再是图像，而是来自压缩管道的输出 token，因此需要剔除原始的嵌入层
一个 16 倍 token 压缩器，用于在 SAM 和 CLIP 之间架起桥梁；主要借鉴了 Vary，采用 2 层卷积模型对输入 token 进行 16 次下采样

DeepEncoder 通过位置编码的动态插值来实现多分辨率模型的同步训练，并确保最终DeepSeek-OCR 模型的多分辨率支持

MoE 解码器

解码器主要使用 DeepSeek-3B-MoE，其包含 64 个路由专家
模型推理时会激活 6 个路由专家和 2 个共享专家（约 570M 参数）
解码器通过 OCR 式的训练有效学习到一种非线性映射，从而根据 DeepEncoder 输出的压缩潜在（视觉） token，重建原始的文本表示

2.3 训练说明

训练数据说明：

文档数据：（a）从互联网上收集了 30M 页的多样化 PDF 数据，涵盖约 100 种语言，其中中文和英文约占 25M，其他语言约占 5M；对其中部分中英文档进行精细标注（高级模型交错验证），对其余文档进行粗略标注（普通模型快速标注）（b）收集 3M 的字体数据，直接提取内容来构建高质量的图像-文本对（c）除此之外，还额外补充了一些开源数据
自然场景数据：中英文各搜集了 10M，并用PaddleOCR 标注
专业类图像数据：使用 pyecharts 和 matplotlib 渲染 10M 图像数据；化学式图像数据 5M，依赖开源数据+渲染工具；平面几何图像 1M，依赖第三方几何图像感知模型生成（Slow Perception）
普通图像数据：字幕生成、物体识别和定位等数据，约占总数据的 20%
纯文本数据：DeepSeek 内部纯文本预训练数据，约占总数据的 10%

两阶段训练+多节点+数据管道并行：

先使用传统 next-token 预测任务独立训练 DeepEncoder
再划分 4 个训练 pipeline 并行训练完整的 DeepSeek-OCR（1）PP0：冻结 SAM 和压缩器，仅作为视觉 token 生成器（2）PP1：训练 CLIP 模型，输出最终的编码 token 给 MoE 解码器（3）PP2 & PP3：共同承担 12 层 MoE 解码器的训练，，每部分各放6层
20 个节点训练并行，每个节点有 8 个 A100-40G GPU
40 个数据管道并行，保持 40 个相同的模型副本同时训练

2.4 实验评价

评估视觉 token 相对于文本 token 的压缩率和还原精度

本篇论文的核心思想点：a picture is worth a thousand words（一图胜千言）

不同尺寸 DeepSeek-OCR 的 OCR 性能均实现 SOTA

OmniDocBench：评估现实场景中多样化文档解析性能的基准测试

其他总结：

视觉 token 的高压缩率和高还原精度，表明该方向非常值得继续研究
当压缩率超过 10 倍后，视觉 token 的还原精度明显下降，存在改善空间
即使压缩率达到了 20 倍，视觉 token 还原精度依然能保持着 60%左右
特定类型的文档，只需要 64 或 100 个视觉 tokne 就能实现较好的 OCR
模型支持灵活的提示方式，对特定专业领域的格式也具备深度解析能力
模型可以处理近 100 种语言，并具备了一定程度的通用图像理解能力

上下文视觉压缩与人类记忆的衰退过程存在相似之处（1）近期记忆：就像近处的物体，是清晰的高分辨率图像，需要较多的视觉 token（2）远期记忆：就像远处的问题，是逐渐模糊缩小的图像，需要更少的视觉 token（3）从近期记忆到远期记忆，视觉 token 能实现信息的自然遗忘和压缩

后记

网络评论摘录：

视觉压缩不仅使上下文更便宜，还使 AI 记忆架构变得可行——Ray Fernando
这种统一视觉与语言的方法，或许是通往AGI的大门之一——叶慧雯
我相当喜欢新的DeepSeek-OCR论文，它是一个很好的OCR模型。对我来说更有趣的部分是像素是否比文本更适合作为LLM的输入——Andrej Karpathy

索引优化

检索粒度 Retrieval Granularity

粗粒度检索单元可以提供更多与问题相关的信息，但可能包含冗余内容
细粒度检索单元会增加检索负担，并且不能保证语义完整性和信息充分性
检索单元粒度从细到粗一般包括词元（Token）、短语（Phrase）、句子（Sentence）、命题（Proposition）、文本块（Chunks）和文档（Document）
检索粒度尽量保持原子性，每个单元应该封装一个相对简洁独立的事实片段
检索粒度需要根据下游任务进行调整，例如在推荐任务中检索物品 ID 或句子对

分块策略 Chunking Strategy

最常用的方法是将文档分割成固定数量的 token（例如 100、256、512）
较大的 token 块上下文信息更多，但噪声也更多，处理时间长，成本高；较小的 token 块上下文信息可能不完整，但噪声更小
分块策略会导致句子内部信息被截断，因此需要优化递归分割和滑动窗口方法，此外还需要额外合并检索信息，建立全局信息实现检索分层
Small2Big：短句（Small）作为检索单元，短句前后（Big）作为上下文提供给 LLM

元数据附加 Metadata Attachments

数据块可以添加元数据，比如页码、文件名、作者、类别和时间戳
元数据可以作为额外的过滤条件，感知信息的时效性，缩小检索范围
元数据可以从原始文档中解析，也可以认为人为构建，比如增加段落摘要或引入假设性问题（基于 LLM 生成文档可以回答的假设性问题，并通过假设性问题与原始问题之间的相似度，对检索过程进行优化）

索引结构优化 Structural Index

为文档建立层级结构的索引，是提高信息检索效率的有效方法
层级结构索引：文件是父节点，数据块是子节点，每个节点都存储摘要信息
知识图谱索引，为不同的概念和实体建立联系，提高知识检索的准确率，确保 LLM 的上下文一致性，改善整个 RAG 系统的效率，降低 LLM 出错的概率
KGP 是一种多文档知识图谱索引的构建方法；节点由文档段落或结构（比如页面或表格），节点之间的边则根据语义相似度来构建

查询优化

查询扩展 Query Expansion

将单个查询扩展为多个查询可以丰富查询的内容，提高最终查询结果的相关性
方法 1：利用 LLM+Prompt 直接生成多次查询，查询可以并行执行
方法 2：对问题进行分析规划和拆解，生成必要的子问题来作为子查询
方法 3：链式验证 Cove，用 LLM 根据初步回答制定验证问题来进行核实

查询转换 Query Transformation

利用转换后的查询，替代用户的原始查询来检索数据块
方法 1：引导 LLM 进行查询重写; 也有专门的小型语言模型（比如 RRR）来进行查询重写；淘宝利用 BEQUE 查询重写方法显著提高了长尾查询的召回率
方法 2：利用 LLM+Prompt 根据原始查询生成后续的检索查询；HyDE 先根据查询虚构答案，再利用答案作为检索的相似度评估方式；后退提示将原始查询，抽象为一个高层次的概念问题，其检索结果会作为上下文补充

查询路由 Query Routing

根据不同的查询类型，将其路由到不同的 RAG 管道，适合多场景 RAG 系统
路由方式 1：根据元数据进行关键字/实体的识别和过滤，缩小搜索范围
路由方式 2：利用查询文本对应的语义信息进行路由；也可以结合元数据

上下文管理

重排序 Reranking

对文档块进行重新排序，确保最相关的信息排在最前面
基于规则的重排序：依赖预定义的指标，比如多样性、相关性和最大重新排序率（MRR）
基于模型的重排序：比如 SpanBERT、Cohere rerank 或通用 LLM

上下文压缩 Context Selection/Compression

避免冗余上下文信息对结果产生干扰，增强 LLM 对关键信息的感知
方法 1：直接利用小型语言模型来检测和移除不重要的词元，实现快速压缩
方法 2：根据“过滤-重排序（Filter-Reranker）”的方式，先引入额外的过滤器（比如小型语言模型）减少文档数量，在用 LLM 进行重排序；或者直接用 LLM 进行检索文档的评估和过滤

检索增强

迭代检索 Iterative Retrieval

根据初始查询和已有结果，反复搜索知识库，进行结果的迭代优化；该方式能提高知识库的覆盖率，增强最终结果的稳定性，但可能存在无关信息积累等问题
典型方法 ITER-RETGEN：实现“检索增强结果”和“结果增强检索”的协同

递归检索 Recursive Retrieval

基于历史检索结果递归优化查询，主要目的是提高搜索结果的深度和相关性
典型方法 IRCoT，利用1_study/DeepLearning/上下文工程/思维链 CoT 技术来指导检索，并用检索结果优化 CoT
典型方法 ToC，创建一个澄清树，系统地优化查询中的模糊部分，逐步明确用户需求；适合信息高度专业或细微的复杂搜索场景
递归检索在特定场景下回结合多跳检索技术，来挖掘图结构数据的深层信息

自适应检索 Adaptive Retrieval

让 LLM 主动确定最佳的检索时机和内容，从而改善 RAG 系统的效率和性能
方法 1：借助 LLM 的主动判断能力，可以额外引入自我反思或少样本提示
方法 2：基于强化学习框架，通过奖励设置来训练模型找到最佳的检索策略
方法 3：实时监控文本生成结果的置信度,来自动控制检索时机，比如 Flare
其他：引入反思预测、自然语言推理（NLO）模型、专家评分来规范模型行为

其他优化

嵌入表示 Embeding，用于语义相关性的评估，对检索效果影响较大；对于检索文档与预训练语料差异比较大的场景（比如医疗/法律），微调 Embeding 能很好地缓解数据层面的领域差异；常用微调方法：LLM-Embedde、REPLUG
混合检索，利用不同方式的相关性特征（比如稀疏向量和 embedding）进行互补，增强检索的性能；比如稀疏向量检索可以增强 Embeding 的零样本检索能力，而 Embeding 也能提高稀有实体的查询鲁棒性
外部适配器 Adapter，用于特定功能的针对性强化；UPRISE 训练了额外的提示检索器用于领样本任务的提示检索；AAR 引入一个通用适配器来适应多个下游任务；PRCA 添加来一个奖励驱动适配器，来增强特定任务的性能

本文内容主要参考自一篇 RAG 综述论文

NAS 体验与经验分享

2025-10-27 21:16:00

整体 NAS 规划：

准主机说明：天钡WTR Pro 5825U + 自行购买的内存、SSD 和磁盘
系统以 PVE 为底层，确保稳定性，并配置 fnOS 等虚拟机
短期目标：搭建家庭影院和相册，实现重要数据的多源备份

1 虚拟机系统 PVE

PVE 是在 Linux/Debian 基础上深度定制化的底层虚拟机系统

优点：开源易用，性能出色
缺点：安装略有些繁琐

一、准备工作：

准备一个 U 盘，在主机上插上键盘、网线和屏幕
下载 PVE 系统镜像，用 Rufus 软件制作启动盘
调整主机的 BIOS，确保 U 盘的启动优先级为第一个

本人使用的PVE 系统版本为 proxmox-ve_9.0-1

二、安装 PVE

一路下一步，设置并保存好账户密码，配置 IP 和域名
安装完成后，修改还原 BIOS 的启动优先级
此时重启后不再需要屏幕和键盘，可以通过 web 访问

PVE 的默认 web 访问方式：https://配置 IP:8006

三、配置 PVE

# 合并硬盘分区，删除local-lvm，扩容local
lvremove pve/data
lvextend -l +100%FREE -r pve/root
# 修改后在web端删除local-lvm，编辑增加local的用途

# 测试网络是否通畅
ping baidu.com

更新软件源：

在 /etc/apt/sources.list 中更新软件源为清华源
在 /etc/apt/sources.list.d/pve-no-subscription.list 中更新 PVE 源为清华源
将 /etc/apt/sources.list.d/ 中的其他文件进行移动与备份

mv pve-enterprise.sources pve-enterprise.sources_back
mv ceph.sources ceph.sources_back

关闭登录提示《无有效订阅》弹窗：

# 参考：https://blog.csdn.net/JingLisen/article/details/143847366
vim /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
# `Ext.Msg.show`修改为`Ext.Msg.noshow`即可

systemctl restart pveproxy.service # 重启服务

更新升级软件：apt update && apt upgrade -y

最后重启系统：reboot

其他 PVE 系统设置：

定期进行虚拟机的备份（创建备份计划并进行每周备份）

2 NAS 系统 fnOS

飞牛 NAS 系统是目前流行的开源 NAS 系统，应用丰富且实用

不确定自己是否需要 NAS 或者希望先尝试一下 NAS 的朋友，可以先在 Windows 系统中利用 Hyper-v 虚拟化安装一个 fnOS，进行体验；具体教程可参考飞牛 wiki-Hyper-V 安装

从飞牛官网下载系统镜像，并上传到 pve 的镜像管理中
在 PVE 界面，点击创建虚拟机，输入虚拟机名称并选择镜像
创建虚拟机配置参考：内存 12G，16 核，cpu 类型为 host

虚拟机配置详情：

增加机械磁盘（直通整个 SATA 控制器）

在 PVE 系统中查看磁盘 ID：ls -l /dev/disk/by-id/
找到新增磁盘对应的 ID，执行命令：qm set 100 -sata1 /dev/disk/by-id/ID
进入飞牛系统，在系统设置-存储空间管理中，用新增磁盘创建存储空间

目的：让 FnOS 虚拟机直接管理物理硬盘，避免通过 PVE 虚拟层，性能更好，支持硬盘休眠等功能

增加 SSD 缓存

先在 PVE 界面添加新的固态硬盘分区，注意构建 SSD 仿真
进入飞牛系统，在系统设置-存储空间管理中，添加 SSD 缓存加速

目的：SSD 的随机读写速度远高于 HDD，作为缓存时可加速频繁访问数据的响应速度

其他 fnOS 配置

开启 ssh 功能，方便远程登录
显卡直通，教程可参考；如果出现 noVNC 报错按照这个教程配置 vbios 文件（最后发现虽然 GPU 直通完成后能查看到核显，但是实际无法调用 GPU，AMD 还是不要乱搞的好，彻底失败了~）
- 对关键数据（比如照片）开启多盘的自动备份
有域名的情况下，可以配置 DDNS（动态域名解析）；前提是能够获取到 IPv6 地址（本人的路由器本身就是桥接模式，支持 IPv6，因此也没怎么折腾），注意测试 IPv6 连通性；完整教程参考

DDNS 碰到了一个问题，需要破解小米路由器来进行防火墙规则的调整；DDNS 会受到不同地区的运营商限制；以北京移动为例，实测基于 IPv6 的 DDNS 只有约 500k/s 的上行速度，和飞牛自带的免费内网穿透差不多

3 应用体验

推荐应用

飞牛相册：飞牛官方应用，自带 AI 引擎用于人物识别和场景自动分类（很好用）
飞牛影视：自动搭建影视墙，支持字幕管理，支持本地文件和网盘挂载（好用）
qBittorrent，常规BT下载器；提速优化技巧（官方自带的下载其实也够用）
Nastool：配合 qBittorrent 实现一键追剧，自动下载和整理影音资源，资料参考
Jackett，BT 资源站管理，配合 Nastool 进行资源自动查找，然后发送给 qBittorrent
Aria2：配合网盘资源，解析直链下载（实测支持主流网盘，能突破非会员限速）
pansou：开源网盘资源搜索工具，资源丰富，更新及时（也可以直接用官方站）
Suwayomi：漫画阅读器/服务器，支持本地文件与在线资源站，安装教程
quark-auto-save：夸克网盘自动签到+指定资源自动转存下载
青龙面板：定时脚本管理与通知（经典应用，官方商店可下载）

其他第三方推荐（个人暂未采纳的应用）

Jellyfin：开源家庭媒体中心；插件丰富（比如 OpenSubtitles 字幕管理），生态成熟
moviepilot：Nastool 的进阶版，但需要养好的 PT 站账号（太麻烦，暂时没捣鼓）
Xiaomuisic：基于小米音箱开放接口实现任意音乐的下载与播放（实测不太稳定，先码住）
Moontv：开源自部署的第三方聚合影视站，枪弹分离（TV 端已有类似的 APP，先码住）
MediaMaster V2：影视自动化订阅管理系统，联动豆瓣“想看”，自动下载（待实验）

目前的影视方案：

感兴趣的资源手动下载 4K 原盘，资源主要来自常见的 BT 站与（开源网盘搜索工具）
常规热门的资源利用 Nastool 实现一键追剧，自动 BT 下载（热门资源一般会有人做种）
非常规临时场景考虑 pansou+网盘挂载，利用飞牛影视进行直链解析播放（可能不稳定）
兜底方案，是利用第三方聚合影视站进行搜索和播放（画质可能不高，且可能有广告）

目前在探索的方案：网盘 VIP+smartstrm 实现网盘资源的订阅播放

该方案的好处：支持追剧+自动更新，不占用本地存储，不占用家庭网络上行带宽该方案的缺点：目前飞牛影视暂不支持 strm 播放，并且飞牛影视本身支持网盘资源的直链播放（与 strm 播放功能类似，只是目前属于新功能，实际体验还不太稳定，并且网盘资源较多时频繁扫盘可能存在风险）

目前的内网穿透方案：

域名动态解析：IPv6+cloudflare dns，实测存在限速问题，此外端口暴露也不安全（暂时舍弃）
飞牛官方内网穿透服务：免费版上行速度大概 5M，临时方案，日常管理够用
其他待尝试的常规方案（服务器流量有限，暂时不考虑）：vpn/局域网，服务器转发

4 其他补充

对 NAS 感兴趣并且有 Windows 系统的朋友，可以先通过 Hpyer-V 体验一下 fnOS 系统；之后再考虑是否要入 NAS 这个坑；本文中提到的大部分服务或应用均可以通过 Docker 安装
PVE下安装飞牛OS核显直通教程
针对SSD缓存池丢失，造成存储空间不可用的恢复方法
部分软件依赖 TMDb 的 API KEY，申请教程（申请信息可以乱写）
部分软件依赖网络加速功能，可能需要额外客户端配合（比如 v2raya）

3+2+1 备份原则：3份数据副本（1份原始文件 + 2份备份），保存在2种不同的存储介质上，其中至少有1份副本存储在异地

第三方 NAS 教程的整理汇总：

其他参考资料：知乎 - All in One 保姆教程⑧（安装飞牛 fnOS）
Proxmox VE 安装 FnOS 完全指南

20251026 RAG 开发面对的12个问题

2025-10-26 22:22:00

前置知识：检索增强 RAG

1 内容缺失

问题现象：知识库中缺少上下文，导致 RAG 给出一个看似合理但错误的答案

解决方案：

Garbage in, garbage out；清理不合理的数据，避免重复或无关信息
通过 Prompt 鼓励鼓励模型承认其局限性，并更透明地表达不确定性

2 排序遗漏

问题现象：不合理的检索排序导致关键文档被遗漏，没有被正确返回给 LLM

解决方案：

调整数据检索相关的超参数，降低计算效率来换取更高质量的检索结果
扩大初次检索结果的排序范围，并进行重新排序，改善 RAG 性能
根据具体情况更换其他检索器，或者对已有的检索器进行针对性微调/优化

3 合并遗漏

问题现象：关键信息被正确检索到，但在大量文档的整合过程中被遗漏

解决方案：和上一个问题的解决方案类似，都是重排序、调整或优化检索策略

4 信息忽略

问题现象：关键信息被正确提供，LLM 未正确提取到

该问题一般发生在 LLM 上下文中存在过多噪声或冲突信息时

解决方案：

数据清洗真的很重要
上下文压缩，减少冗余信息，提高系统运行速度
针对长上下文重排序，上下文首尾的信息更容易被重视

5 格式错误

问题现象：LLM 的输出不遵从指令，不满足要求的特定格式（比如表格或JSON）

解决方案：

Prompt 优化，增加清晰的说明，反复强调，提供示例
集成第三方框架中的输出解析（output parsing）模块
利用 Pydantic 模块将文本转换为结构化的 Pydantic 对象
利用 API 接口的输出约束，比如 OpenAI JSON 模式限制

6 模棱两可

问题现象：LLM 的输出过于模糊或笼统，无法满足用户的需求

解决方案：考虑高级 RAG 技术，比如调整搜索结果的粒度

7 输出残缺

问题现象：输出结果不完整，但相关的信息是存在于上下文中的

解决方案：考虑高级 RAG 技术，比如查询转换/查询重写

8 管道瓶颈

问题现象：RAG 系统难以管理和处理海量数据，导致高延迟、低性能等问题

解决方案：添加数据 pipeline 的并行处理功能，避免查询检索的长期堵塞

9 SQL 难题

问题现象：当 LLM 根据文本转 SQL 方面不太灵活，对结构化数据的检索效果差

解决方案：

利用 ChainOfTablePack 等技术，使用一组受限的操作逐步转换表格类数据
在必要时，调用编程工具直接进行符号推理（比如 Python、SQL 等）

10 OCR 难题

问题描述：简单的检索方法无法获取 PDF 等复杂文档中的数据

解决方案：利用成熟的第三方格式转换工具；或借助高精度 OCR 技术

11 模型故障

问题描述：在使用 LLM 时，出现报错或速率限制等问题

解决方案：利用路由工具，自适应的选择最佳模型；做好备用的模型方案

12 模型越狱

问题描述：LLM 可能面对提示注入、不安全输出和敏感信息泄露等问题

解决方案：利用第三方 LLM 安全工具，进行内容审核或风险拦截

本文内容主要整理自《12 RAG Pain Points and Proposed Solutions》

检索增强 RAG

2025-10-24 00:07:00

上下文学习 ICL 是大模型 RAG 的前提基础

朴素 RAG

RAG（retrieval-augmented-generation）：基于信息检索的提示词增强技术

RAG 的一般流程：

先对文档切分，再借助 Embedding 模型实现知识的向量化存储
通过余弦相似度等度量标准，检索与查询向量最相似的文档（召回）
重新排序检索到的文档，并只保留最相关的文档（提高 RAG 的质量）

推荐参考 MTEB 排行榜，结合个人需求选择合理的 Embedding 模型

RAG 的优点：

通过事实类知识的信息增强，减少LLM幻觉
数据更安全，提示内容对普通用户不可见
不需要微调，即可让模型及时掌握最新的信息

RAG 的缺点：

RAG 的最终效果受到 Embedding 模型和知识检索结果的质量影响
受到 LLMs 本身的模型理解和逻辑能力限制，RAG 只是锦上添花
检索依赖的内容可能存在虚假、过时、非权威、术语混淆等问题

GraphRAG

由微软团队在 2024 年提出的 RAG 技术

GraphRAG 主要依赖 LLM 生成的知识图谱改善问答性能
结构化信息提升 LLM 生成内容的准确性、相关性和可解释性
该方法在处理复杂信息或专业文档时，相比朴素 RAG 优势明显

框架设计与算法细节：

上图左侧为索引阶段（Indexing Time），利用 LLM 来自动化构建知识图谱，并提取出对应的节点/实体、边/实体关系和协变量（比如实体描述或时间约束等）
然后利用社区发现技术（community detection，比如 Leiden 算法）对完整知识图谱进行子图划分，并进行自下而上处理（关系梳理、生成子图摘要）
上图右侧为查询阶段（Query Time），该阶段通过社区摘要的 map-reduce 处理来回答查询（1）map，独立并行地查询根据子图摘要，产生部分答案（2）reduce，部分答案被组合并用于生成最终的全局答案

相关资源：官方博客、原始论文、开源地址

Deep Search

Deep Search 深度搜索

将 Agent 机制纳入 RAG 系统，实现更动态、灵活的检索与生成能力
直观表现为以最优结果为导向的反复搜索（比如切换关键词或数据源）

Deep Search 的典型能力

动态检索：依据中间结果与置信度阈值，决定是否二次检索；支持不同搜索工具的切换
任务分解：将复杂问题拆解为子任务，分别进行检索分析，然后进行证据对齐，进而得出结论
工具调用：支持调用外部工具获取实时信息，比如天气查询或者代码执行，再生成结论
反思与修正：对生成结果自我评估，发现内容缺失或矛盾时重新检索或调整生成策略
交互与偏好对齐：主动追问检索相关的范围、领域与输出格式等偏好，并将用户反馈动态注入检索与排序策略
证据可追溯：为关键结论提供来源锚点，标准可能失效、存疑与冲突的证据，降低幻觉风险
成本与时延：根据问题难度调节检索轮次、Top‑k 与并发批量，平衡质量与延迟

Deep Research

Deep Research 深度研究

引入推理模型，强化检索、查询、分析与研究能力
相比 Deep Search，Deep Research 的推理和思考能力更强，最终产出的内容质量更高，但是 token 消耗与用户等待时间也会更高

关键技术：推理时计算（test-time compute）

推理阶段投入更多的计算资源，例如评估多个潜在答案、进行更深入的规划、以及在给出最终答案前进行自我反思等
推理时计算会显著提高结果的质量和准确率，减少反复验证与修改的成本

更多 RAG 技术的进阶技巧，可参考1_study/DeepLearning/上下文工程/高级 RAG 技术

参考：

聊聊 Deep Search 和 Deep Research

20251023 北京地铁时空分析

2025-10-22 19:48:00

典型车站工作日与周末进站客流量时间分布：

乘客出行时间分布：

参考：北京市地铁客流的时空分布格局及特征
 北京市轨道交通车站客流时空分布特征
 天气因素对北京市地铁客流量的影响

Banxian | 王半仙修改