今天是2025年11月07日，星期五，北京，天气雨
继续看技术进展，回到信息抽取，看SmartResume简历解析的一个简易系统，是一个典型的pipeline思路，看看具体怎么做的。
另一个是还是RAG的问题，看看RAG在加速目标上，做的上下文复用思路。
已经立冬了，2025年进入冬天了。
多总结，多归纳，多从底层实现分析逻辑，会有收获。
一、SmartResume简历解析的一个简易系统
来看一个文档信息抽取实验性系统，SmartResume，简历解析系统，《Layout-Aware Parsing Meets Efficient LLMs: A Unified, Scalable Framework for Resume Information Extraction and Evaluation》，https://arxiv.org/pdf/2510.09722，https://huggingface.co/Alibaba-EI/SmartResume，支持PDF、图片及常见Office文档格式，融合OCR与PDF元数据提取文本，通过版面检测重建阅读顺序，再经LLM转化为基本信息、教育经历等结构化字段。
思路很简单，在这里的介绍的目的是再次重复下流程，目前的工作很多都是流水线。
核心依赖两个模型，Qwen3-0.6B，负责简历文本信息提取与结构化处理，YOLOv10版面检测模型（权重文件best.onnx，约265.81MB）用于简历版面布局检测与区域分割。
看几个核心的步骤：
1、混合pdf提取，这个其实就是加速用，不是所有的pdf都需要一定走ocr方式。
步骤如下：
step1-将所有简历格式（Word等）统一转为PDF，提取PDF元数据（含结构化文本与边界框坐标）->step2-将PDF页面渲染为图像，通过元数据边界框掩码排除已知文本区域，剩余区域用OCR提取文本。->step3-内容融合，生成含文本与边界框坐标的元组（text,x_min,y_min,x_max,y_max）。
2、布局重构，对于非线性多列布局，需转为线性阅读顺序
处理步骤是：step1-布局区块识别：微调YOLOv10目标检测模型（基于500份简历标注数据集），识别内部可线性阅读的“大区块”。->ste2-区块间排序：按左上角坐标“从上到下、从左到右”确定整体阅读流。**->step3**-区块内排序：对区块内文本块同样按上述规则排序，生成带唯一行号索引的线性文本流（为后续提取优化奠定基础）。
3、大模型抽取部分
将提取任务拆分为“基础信息（姓名、邮箱等）”“工作经历（公司、职位等）”“教育背景（学校、学位等）”3个独立子任务，并行调用LLM。
其中有个机制，索引指针机制：不要求LLM生成完整长文本（如工作描述），而是返回对应文本的行号范围（如[15,25]），后续从原始文本中提取，既降低token消耗（减少延迟与成本）
另外，模型方面，基于15500份简历构建的SFT数据集微调Qwen3-0.6B模型。
然后抽取之后，再做个后处理，如
领域归一化：统一日期格式（如“2020.07”转“2020-07”）、清理机构名称后缀噪声；
上下文去重：通过行号范围对比，删除重复实体（如工作经历中重复提及的项目）；
源文本验证：丢弃关键字段（如公司名、职位）在原始文本中无匹配的实体。
二、RAG处理长文本中的复用问题
继续看RAG进展，讲是RAG加速的问题，立意在RAG中的上下文复用，做一个“高效看文档的插件”，在 “必须看参考文档” 的前提下，依靠找重复【不用重新看已经看过的内容】+调顺序【方便复用之前的记忆，不记错重点】+删重复【少看没用的，省时间】实现。
所以，这个思路下，看一个工作《RAGBoost: Efficient Retrieval-Augmented Generation with Accuracy-Preserving Context Reuse》，https://arxiv.org/pdf/2511.03475。
核心看几个点：
1、看存在的问题
对长上下文（数百文档、完整文档处理），目前存在一些问题。
一个是预填充（生成KV缓存）成为性能瓶颈，精确前缀匹配（如RadixCache、LMCache、RAGCache）需新提示与历史前缀完全一致，准确率保留但缓存命中率极低（MultihopRAGQwen3-32B仅4.6%，NarrativeQALlama3.3-70B仅5.5%），上次看文档的顺序是“文档1→文档2→文档3”，这次顺序变成“文档2→文档1→文档3”，就认不出来了，得重新把3篇文档全看一遍，白忙活；
一个是近似KV缓存匹配（如CacheBlend、PromptCache）问题：通过浮点相似度匹配复用缓存，虽提升复用率，但准确率下降9–11%（如MultihopRAG准确率从60%→50%），且多轮交互误差累积，不管顺序对不对，只要文档看着差不多，就直接用上次记的内容，虽然快了，但容易把关键信息记混（比如把文档2的内容当成文档1的），答题出错率增加；
所以，这么一来，就存在上下文可复用的机会。
2）看技术
核心思路步骤三步走：
step1）上下文索引（追踪多会话/多轮交互中的缓存上下文，支持快速查找），建个“重复文档快速查找库”，树状组织，根节点为空上下文，子节点对应前缀缓存，每个节点含4个属性：文档ID集合、根到节点的搜索路径、序列长度、多轮标记；
—>step-2）上下文排序（重排检索文档以最大化KV缓存命中率，辅以排序提示恢复原始相关性排序，基于上下文索引查找最佳匹配前缀+按“匹配前缀+剩余文档原始顺序”重排（如原始{2,1,4}→重排{1,2,4}，匹配历史前缀{1,2}）），也就是给文档“调顺序”，并提醒原始顺序（对应“上下文排序”）；
—>step3）上下文去重（移除多轮交互中的重复文档，通过位置提示指引模型访问历史内容），掉重复文档，并告知“重复的在哪找”。
