图片来源： https://aiptcomics.com/2024/04/10/transformers-7-2024-review/

摘要： 本文介绍了一种有效的方法，将基于Transformer的大型语言模型（LLMs）扩展到无限长的输入，同时受到内存和计算的限制。我们提出的方法的关键组成部分是一种新的注意力技术，称为Infini-attention。Infini-attention将一种压缩内存集成到了传统的注意力机制中，并在单个Transformer块中构建了掩码局部注意力和长期线性注意力机制。我们通过在长上下文语言建模基准、1M序列长度的口令(keypass)上下文块检索和500K长度的书籍摘要任务中使用1B和8B LLMs，展示了我们方法的有效性。我们的方法引入了最小的有界内存参数，并实现了LLMs的快速流式推理。

注：为解决大模型（LLMs）在处理超长输入序列时遇到的内存限制问题，本文作者提出了一种新型架构：Infini-Transformer，它可以在有限内存条件下，让基于Transformer的大语言模型（LLMs）高效处理无限长的输入序列。实验结果表明：Infini-Transformer在长上下文语言建模任务上超越了基线模型，内存最高可节约114倍。

感觉有种外挂存储库(类似向量数据库)嵌入到模型结构中。比如： Memorizing Transformers + code

在论文《Memorizing Transformers》中，作者提出了一种新的注意力机制，称为kNN-augmented attention layer，它结合了局部上下文的密集自注意力和对外部记忆的近似k-最近邻（kNN）搜索。这个机制的关键部分之一是使用了一个门控机制（gating mechanism）来结合局部注意力和外部记忆的注意力。

想把 HuggingFaceTB/cosmopedia 英文数据中的prompt和text 翻译成 中文， 然后看了下python库 deep_translator的实现， 翻译调用的是三方接口集成库， 于是使用这个库封装的谷歌翻译接口来翻译，但是三方平台接口多会有限流和接口调用频率限制，即使在代码中有容错处理， 比如常规的sleep下再调用，不影响整理处理流程，但是整体处理时间受接口限制，即使用批处理也如此，这个在大规模数据处理中使用三方接口时，经常会遇到的问题，用的三方服务，如果不升级接口服务，在技术上不太好解决； 于是选择另外一种方案，看是否有开源的翻译模型，底层模型结构一般也是Transform架构 Encoder-Decoder model ，也称sequence-to-sequence model； 比如 谷歌的T5模型， 但是推理速度受硬件条件影响，比较慢，而且原始模型不支持英文翻译成中文。

然后看了下meta nllb 模型，专门用来处理翻译的模型，单个 AI 模型中支持 200 种语言，开源地址： https://github.com/facebookresearch/fairseq/tree/nllb 模型相对现在的LLM参数量小一些，也在huggingface的Transforms库中集成 nllb-200-distilled-600M，直接可以load使用， 等等。。。 既然llm推理可以通过想llama.cpp通过加载ggml格式进行量化，在性能有少许折损的情况下降低推理成本，但是ggml gguf格式还不支持nllb模型权重文件(貌似llama.cpp只支持Transform Decoder模型结构)；那就直接用Transforms库来加载facebook/nllb-200-distilled-600M 模型来批量翻译试试看；后续还尝试使用 Helsinki-NLP/opus-mt-en-zh 模型，进行了简单对比。

介绍

随着大型语言模型的不断发展，构建 RAG（检索增强生成）应用程序的热潮与日俱增。谷歌推出了一个开源模型：Gemma。众所周知，RAG 代表了两种基本方法之间的融合: 基于检索的技术和生成模型。基于检索的技术涉及从广泛的知识库或语料库中获取相关信息以响应特定的查询。生成模型擅长利用训练数据中的见解从头开始创建新内容，从而精心制作原始文本或响应。

目的：使用开源模型gemma来构建 RAG 管道并看看它的性能如何。

发现一个有趣玩法，针对rust 编译检查的问题（这个在编写代码逻辑的时候经常会遇到，逻辑是OK，但是通不过rust的安全检查），可以直接发给 chatGPT (其他通过代码库进行PT的模型，或者SFT的模型)， 会给出修改意见，并且可以根据它的提示继续追问怎么解决； 如果直接通过传统的搜索引擎比如google, 也很难找出好的解决方法，而且还要去筛选，去尝试这个方法，如果不是权威网站，可能还被坑。来来回回折腾，效率太低了。像最近的AI程序员 david： introducing-devin ，其实类似思路，也是通过聊天来解决问题，只不过更加的专业，归根结底还是需要专业数据去PT/SFT底层的模型，上层应用通过pipeline对应框架去整体系统调优。(不知是否满足类似这种rust场景的解决方案pipeline，直接给它代码，帮忙修改)

本文主要是讲解一个快速搭建比如RAG pipeline相关应用参考方案，结合云厂商GCP AI服务，以及redis stack | vector index，借助 Google Cloud Platform 上易用的开发SDK, 以及使用redislabs 提供的免费30M内存空间服务；GCP新用户前三个月好像是免费使用一些服务，而且提供 $300 的赠金使用，对于前期学习和使用体验服务还是不错的选择，而且个人感觉学习文档很齐全，不会很零散。但是解决方案相对AWS要少些，毕竟AWS做的很深入，搭建解决方案很方便，集成开发工具比较齐全，特别是serverless lambda服务，可以看下以前写的文章『 用户行为分析方案设计』通过CDK构建解决方案stack(用于前期架构推演，不要YY，要动手，节约成本是干出来的)。

以前注册的，忘记用了。。。

笔记地址：https://github.com/weedge/doraemon-nb/blob/main/Google_BigQuery_Palm_Redis.ipynb

注：这里使用redis作为向量索引数据库，也可以结合其他向量索引库来搭建相应方案。主要目的是熟悉GCP服务和redis cloud服务。

大型语言模型（LLMs）展示了显著的能力，但面临着幻觉、过时知识和不透明、不可追踪的推理过程等挑战。检索增强生成（RAG）已经成为一个有前途的解决方案，通过整合外部数据库的知识。这增强了模型的准确性和可信度，特别适用于知识密集型任务，并允许持续的知识更新和领域特定信息的整合。RAG通过将LLMs的内在知识与庞大、动态的外部数据库资源相结合，产生了协同效应。这篇综述论文详细考察了RAG范式的发展，包括朴素RAG、高级RAG和模块化RAG。它对RAG框架的三方基础进行了细致的了解，其中包括检索、生成和增强技术。该论文强调嵌入(embedding)在每个关键组成部分的最先进技术，并提对RAG系统进展的深入研究了解。此外，该论文介绍了评估RAG模型的指标和基准，以及最新的评估框架。最后，该论文讲了一些研究前景，包括未来挑战、多模态的扩展以及RAG基础设施及其生态系统的进展¹。

论文地址: Retrieval-Augmented Generation for Large Language Models: A Survey | PPT

注： 主要是了解RAG的发展过程(召回率)，以及对相关子模块领域的现阶段了解，如果感兴趣，通过索引到论文引用处进一步了解。(提高看相应论文的准确率)

内存分析简介

在这个系列的原文博客文章中，你将学习如何收集有关程序与内存交互的高层次信息。这个过程通常被称为内存分析。内存分析帮助你理解应用程序随时间变化的内存使用情况，并帮助你构建程序行为的正确心理模型。以下是它可以回答的一些问题：

• 程序的总内存消耗是多少，以及它随时间如何变化？
• 程序何时何地进行堆分配？
• 哪些代码位置分配了最大量的内存？
• 程序每秒访问多少内存？

当开发者谈论内存消耗时，他们通常指的是堆使用情况。实际上，堆是大多数应用程序中最大的内存消费者，因为它容纳了所有动态分配的对象。但堆并不是唯一的内存消费者。为了完整性，让我们提及其他内存消费者：

• 栈：应用程序中帧栈使用的内存。应用程序中的每个线程都有自己的栈内存空间。通常，栈的大小只有几MB，如果超出限制，应用程序将崩溃。总的栈内存消耗与系统中运行的线程数量成正比。
• 代码：用于存储应用程序及其库的代码（指令）的内存。在大多数情况下，它对内存消耗的贡献不大，但也有例外。例如，Clang C++编译器和Chrome浏览器拥有庞大的代码库，它们的二进制文件中有数十MB的代码段。

接下来，我们将介绍内存使用(memory usage)和内存足迹(memory footprint)或者翻译成内存占用这两个术语，并看看如何对它们进行分析。

注： 主要是通过工具分析内存使用情况，尽量利用局部性原理：时间局部性和空间局部性，提高性能。