今天是2024年11月23日，星期六，北京，天气晴。
本文看两个问题，一个是最近模仿openaiAI O1现有路线-long COT蒸馏路线，有些有趣的点。
另一个是还是回归到RAG上，最近同名的RAG框架很多，例如fastRAG(https://github.com/IntelLabs/fastRAG.git，朴素rag的一个模块化)和FastRAG(https://arxiv.org/html/2411.13773)。我们来看看具体后者，其重点是面向半结构化数据做的，也可以再次温习下GraphRAG。
我们可以从中找到一些思路，多思考，多总结，多实践；
一、最近模仿OpenAI O1现有路线-long COT蒸馏路线
最近模仿openAI O1的工作很多，例如DeepSeek-R1-Lite-Preview(techreport还未出，技术细节不明确)、Marco-o1(https://arxiv.org/abs/2411.14405，结合了CoT微调、蒙特卡洛树搜索MCTS、反思机制)。
但很多工作都是基于蒸馏cot（应该叫long-cot） 的方式来做的，例如前几写的文章，其实，回过头来讲，o1这个还是不能盲目模仿，技术这东西还是参透本质后做出来才更扎实。 目前想做o1的比较快的就是合成一些思维链 ，使用更大的模型蒸馏一把。大的，正确率也不高。 或者全靠人工step by step的去标，成本也比较高。
但是，蒸馏这个事情，蒸馏的上限是base，这个提升是怎么来的，这个很其妙。
最近有个工作，https://github.com/GAIR-NLP/O1-Journey#about-the-team，发现，通过简单的知识蒸馏方法，以Qwen2.5-Math-72B作为基础模型，经过精心设计数据筛选和处理流程(从开源数据集NuminaMath-CoT上选取部分奥林匹克级别的问题作为起点，并设计规则移除依赖图像的问题、缺乏明确标注答案的问题以及所有证明题，仅保留答案类型为数值的问题。此外，还利用GPT-4o-mini重写原始解答。重写过程遵循特定的标准，确保解答的步骤是细粒度的、高度详细的，并且篇幅更长，并还规范化输出格式)，使用数万个从o1蒸馏的 长思考链样本(注意，现在有个新名词，叫long-cot) 进行训练。
最后，在美国高中数学邀请赛 (AIME) 等权威测试中，模型表现优于o1-preview，这种复现秀，改工作也抛出来了一个新问题，很赞同，也就是，蒸馏方法成为了一条捷径。
二、FastRAG的半结构化RAG提速实现思路
关注RAG进展，半结构化数据的检索增强生成，《FastRAG: Retrieval Augmented Generation for Semi-structured Data 》(https://arxiv.org/html/2411.13773)，其核心宣传点，就是它的“快”，并且与GraphRAG(“From local to global: A graph rag approach to query-focused summarizatio)进行对比，但其实没有太多可比性，因为目的不同，处理的任务不同，后者做了大量实体抽取、摘要生成、社区生成等，有个对比结果，仅供参考：
在具体表现上，FastRAG在处理日志数据集时总时间为3.9分钟，而GraphRAG为40.0分钟；在处理配置文件数据集时，FastRAG总时间为2.0分钟，而GraphRAG为6.3分钟。
另一个就是，对于Glocalsearch方面，在处理包含具体值（如名称或类型）的查询时表现不佳，因为它难以精确匹配这些值。这导致在某些情况下，GraphRAG无法提供有用的答案。
对于globalsearch方面，GraphRAG在总结和报告任务中表现高效，但在处理复杂的网络数据时，可能会遇到资源消耗和延迟的问题，这可能限制其在更大规模网络数据中的可扩展性。
既然说到快，那么，如何快的？
整体流程如下
核心点在于四个点：
1、样本选择 Samples Selection(包括关键词提取和块选择两个步骤。关键词提取通过K-means聚类算法从源数据中提取关键词，块选择则基于块的信息多样性选择样本块)，这么做是为了减少处理时间和成本，所以选择代表性的块进行学习提示。但其实这块有依赖于样本选择，存在遗漏小部分信息的风险。
2、模式学习Schema learning（使用LLM生成JSON模式，即顶层实体类型和属性的JSON模式），这块其实也有损；
3、脚本学习Script learning（类似于模式学习，脚本学习通过迭代提示LLM生成解析函数，并逐步优化这些函数），如下图所示，使用第一个样本块提示LLM生成解析函数。通过提交新的样本块，迭代优化解析函数的语法和功能正确性。每个部分独立处理，使用相应的解析函数，确保LLM能够集中注意力在每个实体类型上，并进行有针对性的优化，这个点比较重要，其目的是为了让这个模式尽可能覆盖住所有chunk），如下图，Schema learning (top) and script learning (bottom)
4、信息检索Information Retrieval（包括文本搜索Text Search（利用NLP方法进行文本搜索，优点是能够处理模糊查询，缺点是可能无法返回足够详细的信息）；知识图谱查询KG Querying(将提取的实体插入到知识图谱中，并使用图查询语言（GQL）进行信息检索。优点是可以提供结构化且精确的信息检索，缺点是在处理具体值查询时可能不够灵活)；组合查询Combined Querying（同时使用KG查询和文本搜索，通过LLM生成一个结合两种方法的GQL语句，优点是能够提供丰富且详细的答案，缺点是可能需要更多的计算资源）和混合查询Hybrid Querying（合并KG查询和文本搜索的能力，生成一个能够利用任何相关特征的GQL语句。优点是能够提供全面的答案，缺点是对查询的构建要求较高，偶尔可能会出现不准确的情况）。
其实，其中有个很重要的点，就是，它为啥叫"Semi-structured Data"（半结构化数据）？它主打的点是这块。
一般来说，半结构化数据指那些不完全遵循预定义模式或格式的数据，但仍然包含某种程度的组织或结构。与完全无结构的数据（如纯文本或图像）相比，半结构化数据通常包含一些标记、标签或其他元数据，这些元素可以帮助识别和提取有用的信息。
例如，在网络管理中，日志文件和配置文件通常被视为半结构化数据，所以FastRAG也是针对这类数据做的。
总结
本文看两个问题，一个是最近模仿openaiAI O1现有路线-long COT蒸馏路线，有些有趣的点。
另一个是FastRAG(https://arxiv.org/html/2411.13773，其重点是面向半结构化数据做的，也可以再次温习下GraphRAG。
我们越来越认识到，技术在不断变化，但总会有很多阵痛，现在自媒体的内容创作很混乱，有其实技术类的同质化、夸大标题党，翻车的事情层出不穷（这会让很多人产生误导和误判，本身具有判断力的人其实并不占多数，并不好啊），技术是个严谨的事儿，我们需要保持一定专业性和严谨性。
对技术保持崇敬，总是会好的，大家一起共勉。
乐观、长期地看待一些技术点，一些趋势，将会更加美好
