INCOMING TRANSMISSION

生成器 什么是生成器？ 通过列表生成式，我们可以直接创建一个列表，但是，受到内存限制，列表容量肯定是有限的，而且创建一个包含100万个元素的列表，不仅占用很大的存储空间，如果我们仅仅需要访问前面几个元素，那后面绝大多数元素占用的空间都白白浪费了。 所以，如果列表元素可以按照某种算法推算出来，那我们是否可以在循环的过程中不断推算出后续的元素呢？这样就不必创建完整的list，从而节省大量的空间，在Python中， 这种一边循环一边计算的机制，称为生成器：generator 生成器是一个特殊的程序，可以被用作控制循环的迭代行为，python中生成器是迭代器的一种，使用 yield 返回值函数，每次调用 yield 会暂停，而可以使用 next() 函数和 send() 函数恢复生成器。 生成器类似于返回值为数组的一个函数，这个函数可以接受参数，可以被调用，但是，不同于一般的函数会一次性返回包括了所有数值的数组，生成器一次只能产生一个值，这样消耗的内存数量将大大减小，而且允许调用函数可以很快的处理前几个返回值，因此生成器看起来像是一个函数，但是表现得却像是迭代器 python中的生成器...

概述 python采用的是 引用计数 机制为主， 标记-清除 和 分代收集 两种机制为辅的策略。 引用计数 Python语言默认采用的垃圾收集机制是『引用计数法 Reference Counting 』，该算法最早George E. Collins在1960的时候首次提出，50年后的今天，该算法依然被很多编程语言使用。 『引用计数法』的原理是：每个对象维护一个 ob_ref 字段，用来记录该对象当前被引用的次数，每当新的引用指向该对象时，它的引用计数 ob_ref 加 1 ，每当该对象的引用失效时计数 ob_ref 减 1 ，一旦对象的引用计数为 0 ，该对象立即被回收，对象占用的内存空间将被释放。 它的缺点是需要额外的空间维护引用计数，这个问题是其次的，不过最主要的问题是它不能解决对象的“循环引用”，因此，也有很多语言比如Java并没有采用该算法做来垃圾的收集机制。 引用计数案例 import sys class A(): def __init__(self): '''初始化对象''' print('object born id:%s'...

列表和元组总结 列表和元组都是 一个可以放置任意数据类型的有序集合 ，他们有以下共同点 列表和元组中的元素可以任意，并且都可以嵌套。 列表和元组都支持索引，且都支持负数索引，-1表示最后一个元素，-2表示倒数第二个元素 列表和元组都支持切片操作 都支持in关键词 都可以使用 .index() 、 .count() 、 sorted() 和 enumerate() 等方法 两者之间的相互转换，list()和tuple() 但是他们也是有区别 列表是动态的，长度大小不固定，可以随意地增加、删减或者改变元素（mutable） 元组是静态的，长度大小不固定，无法增删改，想要对已有的元组做任何“改变”，就只能开辟一块内存，创建新的元组 列表和元组存储方式的差异 由于列表是动态的；元组是静态的，不可变的。这样的差异，势必会影响两者存储方式。我们可以来看下面的例子： >>> l = [1, 2, 3] >>> l.__sizeof__() 64 >>> tup = (1, 2, 3) >>> tup.__sizeof__() 48...

这篇文章主要去“复盘”一下主流的长度外推结果，并试图从中发现免训练长度外推的关键之处。 问题定义 顾名思义，免训练长度外推，就是不需要用长序列数据进行额外的训练，只用短序列语料对模型进行训练，就可以得到一个能够处理和预测长序列的模型，即“Train Short, Test Long”。那么如何判断一个模型能否用于长序列呢？最基本的指标就是模型的长序列Loss或者PPL不会爆炸，更加符合实践的评测则是输入足够长的Context，让模型去预测答案，然后跟真实答案做对比，算BLEU、ROUGE等， LongBench 就是就属于这类榜单。 但要注意的是，长度外推应当不以牺牲远程依赖为代价——否则考虑长度外推就没有意义了，倒不如直接截断文本——这意味着通过显式地截断远程依赖的方案都需要谨慎选择，比如ALIBI，还有带显式Decay的 线性RNN ，这些方案当序列长度足够大时都表现为局部注意力，即便有可能实现长度外推，也会有远程依赖不足的风险，需要根据自己的场景斟酌使用。 如何判断在长度外推的同时有没有损失远程依赖呢？比较严谨的是像 ReRoPE...

简介 论文： 《REVISITING MULTIMODAL POSITIONAL ENCODING IN VISION–LANGUAGE MODELS》 通过对多模态旋转位置嵌入（RoPE）的两个核心组件——位置设计和频率分配进行综合分析。通过实验，确定了三个关键指南：位置一致性、频率全利用和保留文本先验。基于这些见解，提出了多头RoPE（MHRoPE）和MRoPE-Interleave（MRoPE-I），这两种简单且即插即用的变体不需要任何架构更改。 为了构建更稳健的多模态位置编码，作者在MRoPE的基础上，系统地探索了三个未充分研究的方案： 位置设计——如何为文本和视觉标记分配无歧义、分离良好的坐标； 频率分配——如何将旋转频率分配到每个位置轴的嵌入维度； 与纯文本RoPE的兼容性——确保设计默认为标准RoPE，以便进行有效的迁移学习。 Vanilla RoPE RoPE与加性位置嵌入不同，RoPE对query和key向量应用旋转变换，从而将相对位置依赖直接纳入自注意力机制。给定位置 \(m\) 的查询向量 \(q\) 和位置 \(n\) 的键向量 \(k\) ，注意力分数...

不同于RNN、CNN等模型，对于Transformer模型来说，位置编码的加入是必不可少的，因为纯粹的Attention模块是无法捕捉输入顺序的，即无法区分不同位置的Token。为此我们大体有两个选择： 想办法将位置信息融入到输入中，这构成了绝对位置编码的一般做法； 想办法微调一下Attention结构，使得它有能力分辨不同位置的Token，这构成了相对位置编码的一般做法。 虽然说起来主要就是绝对位置编码和相对位置编码两大类，但每一类其实又能衍生出各种各样的变种，为此研究人员可算是煞费苦心、绞尽脑汁了，此外还有一些不按套路出牌的位置编码。本文就让我们来欣赏一下研究人员为了更好地表达位置信息所构建出来的“八仙过海，各显神通”般的编码方案。 绝对位置编码 形式上来看，绝对位置编码是相对简单的一种方案，但即便如此，也不妨碍各路研究人员的奇思妙想，也有不少的变种。一般来说，绝对位置编码会加到输入中：在输入的第 𝑘 个向量 \(𝑥_𝑘\) 中加入位置向量 \(𝑝_𝑘\) 变为 \(\boldsymbol{x}_k + \boldsymbol{p}_k\) ，其中 \(...

简短总结 混合专家模型 (MoEs): 与稠密模型相比， 预训练速度更快 与具有相同参数数量的模型相比，具有更快的 推理速度 需要 大量显存 ，因为所有专家系统都需要加载到内存中 在 微调方面存在诸多挑战 ，但 近期的研究 表明，对混合专家模型进行 指令调优具有很大的潜力 。 什么是混合专家模型？ 模型规模是提升模型性能的关键因素之一。在有限的计算资源预算下，用更少的训练步数训练一个更大的模型，往往比用更多的步数训练一个较小的模型效果更佳。 混合专家模型 (MoE) 的一个显著优势是它们能够在远少于稠密模型所需的计算资源下进行有效的预训练。这意味着在相同的计算预算条件下，您可以显著扩大模型或数据集的规模。特别是在预训练阶段，与稠密模型相比，混合专家模型通常能够更快地达到相同的质量水平。 那么，究竟什么是一个混合专家模型 (MoE) 呢？作为一种基于 Transformer 架构的模型，混合专家模型主要由两个关键部分组成: 稀疏 MoE 层 : 这些层代替了传统 Transformer 模型中的前馈网络 (FFN) 层。MoE 层包含若干“专家”(例如 8...

旋转式位置编码（ROPE） 原始的Sinusoidal位置编码总的感觉是一种“想要成为相对位置编码的绝对位置编码”。一般来说，绝对位置编码具有实现简单、计算速度快等优点，而相对位置编码则直接地体现了相对位置信号，跟我们的直观理解吻合，实际性能往往也更好。由此可见，如果可以通过绝对位置编码的方式实现相对位置编码，那么就是“集各家之所长”、“鱼与熊掌兼得”了。Sinusoidal位置编码隐约做到了这一点，但并不够好。 本文将会介绍我们自研的Rotary Transformer（RoFormer）模型，它的主要改动是应用了笔者构思的“旋转式位置编码（Rotary Position Embedding，RoPE）”，这是一种配合Attention机制能达到“绝对位置编码的方式实现相对位置编码”的设计。而也正因为这种设计，它还是目前唯一一种可用于线性Attention的相对位置编码。 RoFormer：https://github.com/ZhuiyiTechnology/roformer 基本思路 这里简要介绍过RoPE： Transformer位置编码...

在电商搜索中，query推荐有很多种产品形态，不同的产品形态也扮演着不同的角色，常见的有query suggestion（SUG）、猜你想搜（搜索发现、大家都在搜）、细选（锦囊）、搜索底纹、搜索PUSH、搜索“风向标”（点击回退query推荐）等。以淘宝当前版本的产品形态为例，有： 上述每个方向都值得单独介绍，而本文则先整体从query推荐角度，放在一起介绍，方便横向对比各个场景的目标和方法上的异同之处。而以经典的分类方式展开，可以将query 推荐策略放在用户搜索前、搜索中、浏览中、搜索后（本章不涉及讨论）等各个状态阶段来进行比较： 目标 以上引出了搜索query推荐的两大目标： 搜索增长，目标提升提升渗透率，将用户引导到成交效率更高的搜索场景，提升搜索活跃度，常见的产品形态有：底纹、qu...

1. 搜索引擎概述 1.1 推荐和搜索比较 推荐系统和搜索应该是机器学习乃至深度学习在工业界落地应用最多也最容易变现的场景。而无论是搜索还是推荐，本质其实都是匹配，搜索的本质是给定query，匹配doc；推荐的本质是给定user，推荐item。 对于搜索来说，搜索引擎的本质是对于用户给定query，搜索引擎通过querydoc的match匹配，返回用户最可能点击的文档的过程。从某种意义上来说，query代表的是一类用户，就是对于给定的query，搜索引擎要解决的就是query和doc的match，如图1.1所示。 对于推荐来说，推荐系统就是系统根据用户的属性（如性别、年龄、学历等），用户在系统里过去的行为（例如浏览、点击、搜索、收藏等），以及当前上下文环境（如网络、手机设备等），从而给用户推...

精排是用pointwise方式对商品的CTR/CVR进行预估，旨在建模s=f(user, query, item, context) ，对候选商品进行打分。但有些情况下仅有精排还存在不足之处，如： 1、即使对单个商品进行打分，资源效率限制下，上千候选的精排有时也无法落地更加复杂的模型； 2、pointwise模式的打分无法从候选列表整体或上下文实时反馈角度出发进行排序； 3、直接使用精排分排序无法满足特殊整体性排序需求，如常见的搜索结果的多样性（如价格、地域、品牌、风格等属性的打散）、发现性、异质内容的混排调控（如商品、内容、广告等物料的混排）、流量调控等。 相应地，从以上三点出发，本文从“更加精准打分”、“关注序和上下文”、“特殊需求重排”三方面梳理重排的一般方法： 更加精准打分 重排的第...

讨论一下推荐系统三板斧：数据、特征和模型，因为搜索的排序套路和推荐十分类似，除了多了query维度特征，对相关性有一定的要求，其他很大程度上思想一致。 这里先行引用一个比较形象的推荐系统优化流程： 1. 明确业务目标 1. 将业务目标转化为机器学习可优化目标 1. 样本收集 1. 特征工程 1. 模型选择和训练 1. 离线评测验证 1. 在线AB验证 1. 通过离线验证和在线AB的结果反馈到2，形成一个增强回路慢慢起飞。 而在一般情况下，各个环节的贡献占比：样本特征工程模型。另外如果离线验证集85分，线上很多时候也会略低，各种原因也不胜枚举：特征延迟、特征不一致、甚至在样本落盘时的数据丢失等等。 本篇先行介绍上述过程特征工程的一般方法，包括特征设计、清洗、变换以及特征选择，并在最后讨论深度学...