论文阅读:Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID

基本信息 论文标题:Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID 作者单位:Meta 论文链接:https://arxiv.org/pdf/2504.02137 来源:RecSys 2025 Motivation:论文要解决的问题是什么 搜推广的模型严重依赖于item id embedding的表征质量,但在工业场景下,搜推广的id表征存在如下挑战: id量级非常大,常常是数十亿甚至是百亿的规模。因此,通常不可能给每个id一个单独的embedding(即文中的individual embedding, IE),IE的成本太高 id分布非常不均匀,马太效应严重。文中统计:0.1%的头部item占据了25%的曝光量;5.5%的腰部item占据了50%的曝光量;94.4%的尾部item只占据了25%的曝光量 id分布漂移严重:搜推广场景中item的变化非常频繁,无时无刻不在发生着新id的产生和旧id的退出,而且不同id存活的时间周期也不尽相同,所以id的准入准出策略很难完美适配所有item 针对上述问题,常见的做法是对item id采用hash然后查emb的方式(即文中的random hash,RH),将所有id hash到一个固定大小的空间,然后查emb。但是RH方式有如下缺点: 存在hash冲突,把不相关的id hash到一个桶里,导致语义混乱,学习效果不佳 无法解决id分布漂移的问题,比如hash到同一个桶的A、B两个id,如果B出现频率变高,则会带偏A的分布,影响了A的效果 无法进行知识共享,例如新出了商品iphone15,iphone15无法共享到老的iphone14的emb知识,iphone15的id emb必须完全重新学习。针对这种情况,作者做了一个更加极端的AA实验,就是copy一个完全相同的商品,只换item id,如果是IE或者RH策略,则新商品由于id emb是随机初始化的,效果不佳,这是id-based的通病 基于前缀n-gram的semantic id表征方法 针对上述问题,作者沿用了semantic id的思路,首先使用内容理解团队产出的文本、图片等多模态emb,然后基于过去3个月的item多模态emb,训练RQ-VAE模型,并产出所有item的semantic id。 上述过程都是常规操作,重点在于如何基于semantic id得到item emb表征。假设semantic id是L层,每层的codebook size是K: 最常规的做法:每层都初始化一个K*d的emb table,每层sid查各自的emb table,然后把L层的sid emb加起来。但是本文完全没有提这种方法,也没有和这种方法比较,非常奇怪。 为了比较,我个人再详细描述下这种常规做法。比如老item A的sid是(c1,c2,c3);新来一个item B,它的sid是(c1,c2,c4)。用常规方法,A的emb是c1+c2+c3,B的emb是c1+c2+c4。两者c1、c2是可以共享的,所以常规方法也能起到一定的知识共享的效果,共享项有2项:c1、c2。但是因为RQ-VAE的沙漏问题,c2很有可能是沙漏瓶颈,信息量不足。 作者对比了Table 1中的几种方法: Trigram和Fourgram差不多,如果L=3用Trigram、L=4用Fourgram的话,本质上是把L个sid映射成了一个无冲突的int。但是这种方法映射出来的int数量太多了,是\(K^L\)。如果K=1024、L=3,则\(K^L\)就已经超过10亿了,这和直接无冲突的IE方法一样了,而且存在新id无法共享老id学到的知识的问题 All bigrams,就是所有的sid的2-gram。还是上面的例子,A的emb相当于\(c_1c_2+c_2c_3\),B的emb相当于\(c_1c_2+c_2c_4\),两者可共享\(c_1c_2\)项,相比于常规方法,虽然共享项数变少了,但粒度更精细了,孰好孰坏未可知。由Table 2可知,All bigrams的效果至少比Trigram和Fourgram好很多了,而且如果层数L越大,可共享项越多 Prefix-ngram(简称Prefix-SID方法),本文提出的新方法,把所有前缀组合成新id查emb,然后所有emb再求和。还是上面的例子,A的emb相当于\(c_1+c_1c_2+c_1c_2c_3+c_2+c_2c_3+c_3\),B的emb相当于\(c_1+c_1c_2+c_1c_2c_4+c_2+c_2c_4+c_4\),两者可共享\(c_1, c_1c_2, c_2\)三项,比之前的所有方法可共享的信息都多,而且如果层数L越大,可共享项越多,因此这种方法的效果最好,训练也最稳定 实验结果很丰富,做了很多分析,Prefix-SID方法有如下优势: 相比于IE和RH方法,Prefix-SID方法对中长尾item的提升尤其显著,因为新id和老id的表征有了知识共享 对id分布漂移问题更不敏感:由于电商模型训练时消费数据的顺序是和数据的时间一致的,比如一个月的数据,按照1号、2号、…31号这样的时间先后顺序依次训练,理论上4号的模型在4号的测试集上的效果是最好的。作者做了一个实验,分别用20号和4号的模型都在4号的测试集上进行评测,看看20号的模型指标相比4号降低了多少。作者发现,使用Prefix-SID方法和IE方法,两者的指标降低幅度都差不多,都比较小。首先IE方法由于不存在hash冲突,所以20号的模型仍然能比较好地预测4号的数据;其次,Prefix-SID方法虽然有hash冲突,但是因为冲突的item都是语义相似的,可以进行新老item的知识共享,所以这个冲突反而是好事,对模型效果无影响。但是作者发现RH方法的20号的模型在4号数据上评测指标下降比较多,因为有hash冲突,而且冲突是随机的,20号的分布已经变化很大了,导致在4号数据上效果不佳。Table 4的指标越小越好。 基于Prefix-SID方法虽然也有hash冲突,但是冲突到同一个semantic id的item表征更相似,而RH冲突到同一个桶里的item是完全随机的,相似度差。作者以IE为base,把Prefix-SID和RH都各自都冲突到同一个桶的IE emb提取出来,计算类内相似度和类间相似度,发现基于Prefix-SID的类内相似度方差小,类间距离大,说明Prefix-SID确实能把相似item聚到一起。 评论 可借鉴 基于Prefix-SID方法确实能提高新item和老item的信息共享数量,方法值得借鉴 论文实验分析很丰富 可改进 基于Prefix-SID方法居然没有和最常规的加和方法比较,是本文最大的不足

October 9, 2025 · 1 min

论文阅读:Progressive Semantic Residual Quantization for Multimodal-Joint Interest Modeling in Music Recommendation

基本信息 论文标题:Progressive Semantic Residual Quantization for Multimodal-Joint Interest Modeling in Music Recommendation 作者单位:网易云音乐 论文链接:https://arxiv.org/pdf/2508.20359 来源:CIKM 2025 Motivation:论文要解决的问题是什么 多模态emb在搜推的应用方式,通常是先将多模态emb转换成semantic id,然后把semantic id用到搜推模型中,这种方式有如下两个问题: 模态内语义退化:多模态emb转换成semantic id通常使用RQ-VAE或者RQ-KMeans的方法,这种方法在不断残差的过程中,后续残差聚类结果已经不能反映初始emb的聚类效果了。其实就是semantic id的沙漏问题,具体可以看这篇文章,后续有空再分享这个问题。 简单来说,如下图所示,初始有DJ、Rock、Lullaby、Choir四个类,但是对残差emb(即RQ-VAE的第二层)聚类的话,初始的四个类的item就打散了,会聚到不同的簇中,也就是RQ-VAE的后续层的聚类效果已经和初始emb的聚类效果很不一样了,这就是文中说的语义退化问题 模态间建模差异:搜推场景的item通常有多种模态特征,比如文本、图像、音频等,传统方法在多模态融合方面比较简单,不能很好地捕捉多模态之间的关系。 PSRQ生产semantic id 本文是音乐推荐场景,主要用到两种模态:text和audio,分别用百川和MERT提取text和audio的模态emb。 生产semantic id的方法如下图所示: fig2a是传统的RQ-KMeans的方法,每一层都用上一层的残差进行聚类。如上文所述,由于沙漏问题,会导致后续层次的semantic id存在语义退化问题 fig2b是本文新提出的PSRQ量化方法,在RQ-KMeans基础上,每一层除了有上一层的残差向量,还会concat上初始emb减去残差emb后的向量。这样就能区分出残差相似,但初始emb不同的item了,也就避免了RQ方法的沙漏问题,后续semantic id也能保留初始emb的语义信息。fig1d能看出来第二层semantic id仍然能够反映初始emb的分类效果。 Semantic id在下游的应用方法 如下图所示: 每个item有两套多模态emb:text和audio,但是有三套semantic id,除了text和audio各自产一套semantic id之外,还会把text和audio的emb concat起来,再产一套semantic id,相当于多模态融合的semantic id semantic id的emb在排序模型中随机初始化,然后端到端训练 semantic id在用户建模时,使用DIN模型,query用的是多模态融合的semantic id emb,行为流分别用text和audio的semantic id emb。作者说这种方法既能捕捉到单模态细粒度的信息,又能建模跨模态的交互信息 评论 可借鉴 PSRQ的semantic id生产方法确实很有意思,在每一层都用上原始emb,这样不同簇的item在每一层都能分开,不会出现沙漏问题,使得每一层的semantic id都能保留原始emb的语义聚类信息 产了多套semantic id,单模态semantic id是常规操作;多模态emb concat后也产一套semantic id,是个创新点 用户建模时query用多模态semantic id,行为流用单模态semantic id,也是个创新点,虽然论文说这种方法效果最好,但是有点存疑 论文有个实验结果对比了不同semantic id量化方法的效果,结论是:PSRQ > RQ-KMeans = RQ-VAE > VQ > PQ 可改进 pretrain emb和semantic id的生产都没有对齐协同信号 semantic id在下游应用时直接端到端训练,而没有使用codebook初始化,会不会丢失信息比较多? 产semantic id的过程中,模态内语义退化的问题,描述了现象,但是没有用定量的指标来说明问题,感觉可以借鉴【论文阅读:Empowering Large Language Model for Sequential Recommendation via Multimodal Embeddings and Semantic IDs】的方法,定量说明后续层的semantic id的聚类效果或者说区分能力相比初始emb已经相差甚远了 fig2b中,第一层的codebook的dim=d,后续层的codebook的dim=2d,那么后续层的残差dim也是2d,那么初始emb怎么和后续的残差emb相减呢,维度对不上啊?我理解可能是这样的,后续层聚类的时候用的是concat的dim=2d的emb,但是算聚类中心的时候只用了残差本身的emb,这样就能解释得通了,但是文中对这部分的细节没有解释。

October 6, 2025 · 1 min

论文阅读:DAS: Dual-Aligned Semantic IDs Empowered Industrial Recommender System

基本信息 论文标题:DAS: Dual-Aligned Semantic IDs Empowered Industrial Recommender System 作者单位:快手 论文链接:https://arxiv.org/pdf/2508.10584 来源:CIKM 2025 Motivation:论文要解决的问题是什么 Semantic id生产时,要么没有和协同信号对齐(fig2(1)),要么是两阶段对齐方式(fig2(2)): 例如LETTER先生成协同emb,然后和semantic id对齐 或者例如QARM,先协同对齐emb,再生产semantic id 把协同对齐和生产semantic id分成两个阶段,天然有信息损失,不是最优的。本文的目的就是把生产协同emb,以及semantic id的协同对齐放到一个模型中联合训练完成,尽量减少信息损失(fig2(3))。 主模型 主模型如上图所示,中间的ICDM是user和item的双塔模型,用于学习user和item的协同id-based emb;两边分别是生产user和item的semantic id的量化模型。 中间的ICDM就是经典的召回双塔模型,使用点击样本进行训练,唯一不同的是,在user和item塔都有流行度去偏模块,用于学习user和item的无偏emb,后续user和item的semantic id协同对齐用的也是无偏的emb。 两边分别是user和item的semantic id量化模型,两者比较类似,以item为例: 先把item的各种信息,如title、desc、ocr等信息用文本构造成prompt,输入到LLM,借助LLM的summary和reasoning能力,产出item的详细描述 然后把LLM产出的描述再输入到一个预训练的embedding模型PLM,文中用的是bge m3模型,得到item emb 后续就是标准的RQ-VAE过程了 需要注意的是,上述前两步,分别用到了LLM和PLM两个大模型,而且看图上这两个模型都是freeze的,也就是说并不微调这两个大模型。后续协同对齐用的emb是RQ-VAE重构emb的中间层结果,即图中的item quantized emb。 semantic id的协同对齐方面,有三大类对齐任务: U2I对齐:量化user emb和协同item emb对齐、量化item emb和协同user emb对齐 U2U和I2I对齐:量化user emb和协同user emb对齐、量化item emb和协同item emb对齐 U2U和I2I的共现对齐:点击相同item的两个量化user emb对齐、同一个user点击的两个item的量化item emb对齐 由于fig3中的协同模型和semantic id模型是联合训练的,总共有3大类loss: 中间的ICDM的双塔召回模型的loss 两边的产semantic id的loss 三个模块的对齐loss 评论 可借鉴 把semantic id的生产和协同信号对齐统一成一阶段的模式,信息损失更少 中间的ICDM模型生产协同emb时进行了去偏,协同对齐的时候用的是去偏的emb,这是其他论文很少提到的 可改进 太复杂了!3个模块,3大类loss,每类loss又有很多个小loss,总loss数量加起来有十多个。。。 任务太多,各种去偏、对齐loss,真的不会互相影响吗? 中间的ICDM模块有必要吗?我理解ICDM本质是为了训练产出协同emb,但是因为训练样本本身是点击样本,样本本身已经包含了搜推场景的协同信号,也就是ICDM本身没必要存在了,直接用相同的样本训练两边的semantic id量化模型就行了,也能实现在训练semantic id的过程中,完成协同信号的对齐 生产semantic id的emb来自LLM和PLM,但是这两个大模型都是freeze的,如果把这两个模型也sft,效果会不会更好?其实我原本以为的一阶段就是这样的,这也是我在【论文阅读:Empowering Large Language Model for Sequential Recommendation via Multimodal Embeddings and Semantic IDs】中提到的一阶段方法。

October 5, 2025 · 1 min

论文阅读:QARM: Quantitative Alignment Multi-Modal Recommendation at Kuaishou

基本信息 论文标题:QARM: Quantitative Alignment Multi-Modal Recommendation at Kuaishou 作者单位:快手 论文链接:https://arxiv.org/pdf/2411.11739 来源:CIKM 2025 Motivation:论文要解决的问题是什么 多模态emb在搜推场景应用时通常采用如下图的两阶段方式,先预训练多模态emb,然后作为一个冻结特征放到搜推模型中。这种方式存在2个问题: 表征不对齐:多模态emb预训练的任务通常是图片分类或者文本的MLM,和下游搜推任务不对齐 表征不更新:多模态emb在搜推任务中作为冻结特征,没有更新 本文的方法就是想要解决上述2个问题。 对齐搜推任务的多模态emb预训练 为了解决多模态emb表征不对齐的问题,本文提出的多模态emb预训练任务直接对齐搜推场景,使用U2I和I2I召回模型,挖掘出相似item pair,然后通过对比学习微调多模态大模型。 具体来说,通过U2I和I2I模型,能够拿到item emb;然后用每一个target item emb去行为流中检索出最相似的商品,作为trigger item emb。<trigger, target>构成一对正样本,然后进行对比学习训练。 通过召回模型构造的训练样本,和搜推场景的协同信号对齐了,解决了开头提到的第一个问题,即表征不对齐的问题。 Semantic id生产方法 Semantic id的生产方法如上图右半部分所示,有两种方式: VQ:直接圈定一定数量(如N)的item emb作为底池,编号1~N,然后任意来一个item emb,通过对底池emb进行KNN搜索,找出top-k相似商品,假设是(a,b,…,k),则VQ编码的semantic id就是(a,b,…,k)。文中取k=25,感觉挺大的。。。 RQ-Kmeans:对圈定的N个item emb不断进行Kmeans聚类、求残差、残差继续Kmeans聚类的过程。文中取迭代次数为L=6,但是没说每次聚到多少个类。 注意:文中的RQ-Kmeans方法和RQ-VAE还不一样,RQ-Kmeans没有训练过程,也没有重构loss,纯粹是每次进行聚类,然后选聚类中心作为码本的过程。文中也没有对比过为啥不用RQ-VAE。 产出两套semantic id之后,直接在下游排序任务中进行端到端更新,解决开头提到的表征不更新的问题。具体建模方法比较常规,不是本文的重点,略讲。 评论 可借鉴 多模态emb预训练任务是i2i的,直接和下游搜推任务对齐 semantic id有两种产出方式,VQ和RQ-Kmeans,尽可能多地保留原始多模态emb的信息 可改进 多模态emb预训练和下游任务对齐,在2025年不算新鲜事了,常规操作。而且文中i2i的构造过程依赖U2I和I2I召回模型,有外部依赖,不够漂亮 VQ的方法,k=25这也太长了吧,相当于一个小型行为流了,会导致下游任务的特征处理更复杂 为什么用RQ-Kmeans而不是RQ-VAE,没有任何说明与对比 从pretrain emb量化成semantic id的过程中,存在严重的信息丢失,这在Empowering Large Language Model for Sequential Recommendation via Multimodal Embeddings and Semantic IDs论文中有讨论

October 4, 2025 · 1 min

论文阅读:Empowering Large Language Model for Sequential Recommendation via Multimodal Embeddings and Semantic IDs

基本信息 论文标题:Empowering Large Language Model for Sequential Recommendation via Multimodal Embeddings and Semantic IDs 作者单位:香港城市大学&腾讯 论文链接:https://arxiv.org/pdf/2509.02017 来源:CIKM 2025 Motivation:论文要解决的问题是什么 LLM4SR的基本范式如下,即用LLM直接来做搜推的范式(这种方式在学术界常见,但在工业界不常见)。由于LLM的输入词表范围是有限的(通常比较小),因此其token emb dim通常比较大,比如2048或者4096;而搜推场景的item量级很大,而且在不断更新,因此工业界经典的id-based的搜推模型的item emb dim通常比较小,比如64或128。经典的id-based的搜推模型能比较好地学习到搜推场景的协同信号,为了让LLM模型也能感知这种信息,LLM4SR范式通常会先预训练一个id-based的经典搜推模型,然后将其中的item id emb通过下图的Linear Projection的映射层,映射到LLM token emb的空间,让LLM也能感知搜推的协同信号。 上述LLM4SR范式存在两个问题: 维度坍缩:id-based训出来的id emb dim比较小(如64),LLM token emb dim比较大(如4096),在由id emb通过Linear Projection映射到toen emb的过程中,虽然64映射到4096空间了,但扩维后的矩阵存在低秩问题,即还是只利用了4096中的64维的空间。 论文中,作者分两种情况进行了分析,如果Linear Projection只是一个线性层的话,通过公式推导能得出上述结论;如果Linear Projection包含非线性变换,作者通过实验分析也发现了维度坍缩的现象。 灾难遗忘:除了使用id-based模型产出的id emb,LLM4SR也常用多模态模型产出item emb表征,然后转换成semantic id输入到LLM4SR中。在这种情况下,产出的semantic id通过会遗忘多模态item emb的信息,导致下游LLM4SR的效果不佳。 论文中,作者用公式9来衡量semantic id保留pretrain多模态emb的信息量。具体来说,如果行为流中的商品序列是{A,B,C,D},target item是E。使用pretrain多模态emb能计算出E和A~D的相似度,例如相似度<E,A> > <E,B>。如果将pretrain多模态emb转换成semantic id,然后由semantic id恢复出新的A~E的emb之后,再计算E和A~D的相似度,如果仍然有<E,A> > <E,B>,则认为一致(concordant),否则不一致(disconcordant)。这个分析方法挺好的,通过这个指标能估算出转换成semantic id之后,仍然保留原有pretrain多模态emb对搜推场景的序关系的保留程度。 作者发现,转换成semantic id之后,信息只保留了37.14%;进一步,如果semantic id是在下游任务中端到端训练的,则信息只保留了5.5%,也就是说94.5%的pretrain emb的序的信息都丢掉了,也就是灾难遗忘。 Semantic id构建方法 3套emb来源,一套id-based经典搜推模型产出的包含协同信号的emb,另外两套是LLM2CLIP产出的多模态文本和图片emb。作者提到传统CLIP对长文本处理能力较弱,所以升级到LLM2CLIP,能更好地处理长文本。 Semantic id构建方法是经典的RQ-VAE的方法,但有如下两个改进点: 将emb的重构loss由MSE升级成MMD (maximum mean discrepancy),MSE是计算原始emb和重构emb的欧式距离的误差,而MMD是计算两个分布的diff,实验表明能MMD比MSE能保留更多的pretrain多模态emb信息(即上述公式9),保留44.36% 对量化后的emb做了对齐,因为LLM2CLIP本身进行了图文模态的对齐,所以文中只新增了id emb分别和文本、图片模态的对齐 此外,还有一点论文没提但可能和常规RQ-VAE不同之处,就是原始emb在进行RQ-VAE之前,有一个Encoder升维的操作,在重构loss前对应有一个Decoder降维的操作,而semantic id量化恢复emb是Decoder之前的那个。这一升一降,估计也有助于缓解维度坍缩。 ...

October 4, 2025 · 1 min

和我一起构建搜索引擎(五)推荐阅读

虽然主要的检索功能实现了,但是我们还需要一个“推荐阅读”的功能。当用户浏览某条具体新闻时,我们在页面底端给出5条和该新闻相关的新闻,也就是一个最简单的推荐系统。 搜狐新闻“相关新闻”模块 推荐模块的思路是度量两两新闻之间的相似度,取相似度最高的前5篇新闻作为推荐阅读的新闻。 我们前面讲过,一篇文档可以用一个向量表示,向量中的每个值是不同词项t在该文档d中的词频tf。但是一篇较短的文档(如新闻)的关键词并不多,所以我们可以提取每篇新闻的关键词,用这些关键词的tfidf值构成文档的向量表示,这样能够大大减少相似度计算量,同时保持较好的推荐效果。 jieba分词组件自带关键词提取功能,并能返回关键词的tfidf值。所以对每篇新闻,我们先提取tfidf得分最高的前25个关键词,用这25个关键词的tfidf值作为文档的向量表示。由此能够得到一个1000*m的文档词项矩阵M,矩阵每行表示一个文档,每列表示一个词项,m为1000个文档的所有互异的关键词(大概10000个)。矩阵M当然也是稀疏矩阵。 得到文档词项矩阵M之后,我们利用sklearn的pairwise_distances函数计算M中行向量之间的cosine相似度,对每个文档,得到与其最相似的前5篇新闻id,并把结果写入数据库。 推荐阅读模块的代码如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 # -*- coding: utf-8 -*- """ Created on Wed Dec 23 14:06:10 2015 @author: bitjoy.net """ from os import listdir import xml.etree.ElementTree as ET import jieba import jieba.analyse import sqlite3 import configparser from datetime import * import math import pandas as pd import numpy as np from sklearn.metrics import pairwise_distances class RecommendationModule: stop_words = set() k_nearest = [] config_path = '' config_encoding = '' doc_dir_path = '' doc_encoding = '' stop_words_path = '' stop_words_encoding = '' idf_path = '' db_path = '' def __init__(self, config_path, config_encoding): self.config_path = config_path self.config_encoding = config_encoding config = configparser.ConfigParser() config.read(config_path, config_encoding) self.doc_dir_path = config['DEFAULT']['doc_dir_path'] self.doc_encoding = config['DEFAULT']['doc_encoding'] self.stop_words_path = config['DEFAULT']['stop_words_path'] self.stop_words_encoding = config['DEFAULT']['stop_words_encoding'] self.idf_path = config['DEFAULT']['idf_path'] self.db_path = config['DEFAULT']['db_path'] f = open(self.stop_words_path, encoding = self.stop_words_encoding) words = f.read() self.stop_words = set(words.split('\n')) def write_k_nearest_matrix_to_db(self): conn = sqlite3.connect(self.db_path) c = conn.cursor() c.execute("'DROP TABLE IF EXISTS knearest'") c.execute("'CREATE TABLE knearest(id INTEGER PRIMARY KEY, first INTEGER, second INTEGER, third INTEGER, fourth INTEGER, fifth INTEGER)'") for docid, doclist in self.k_nearest: c.execute("INSERT INTO knearest VALUES (?, ?, ?, ?, ?, ?)", tuple([docid] + doclist)) conn.commit() conn.close() def is_number(self, s): try: float(s) return True except ValueError: return False def construct_dt_matrix(self, files, topK = 200): jieba.analyse.set_stop_words(self.stop_words_path) jieba.analyse.set_idf_path(self.idf_path) M = len(files) N = 1 terms = {} dt = [] for i in files: root = ET.parse(self.doc_dir_path + i).getroot() title = root.find('title').text body = root.find('body').text docid = int(root.find('id').text) tags = jieba.analyse.extract_tags(title + '。' + body, topK=topK, withWeight=True) #tags = jieba.analyse.extract_tags(title, topK=topK, withWeight=True) cleaned_dict = {} for word, tfidf in tags: word = word.strip().lower() if word == '' or self.is_number(word): continue cleaned_dict[word] = tfidf if word not in terms: terms[word] = N N += 1 dt.append([docid, cleaned_dict]) dt_matrix = [[0 for i in range(N)] for j in range(M)] i =0 for docid, t_tfidf in dt: dt_matrix[i][0] = docid for term, tfidf in t_tfidf.items(): dt_matrix[i][terms[term]] = tfidf i += 1 dt_matrix = pd.DataFrame(dt_matrix) dt_matrix.index = dt_matrix[0] print('dt_matrix shape:(%d %d)'%(dt_matrix.shape)) return dt_matrix def construct_k_nearest_matrix(self, dt_matrix, k): tmp = np.array(1 – pairwise_distances(dt_matrix[dt_matrix.columns[1:]], metric = "cosine")) similarity_matrix = pd.DataFrame(tmp, index = dt_matrix.index.tolist(), columns = dt_matrix.index.tolist()) for i in similarity_matrix.index: tmp = [int(i),[]] j = 0 while j <= k: max_col = similarity_matrix.loc[i].idxmax(axis = 1) similarity_matrix.loc[i][max_col] = -1 if max_col != i: tmp[1].append(int(max_col)) #max column name j += 1 self.k_nearest.append(tmp) def gen_idf_file(self): files = listdir(self.doc_dir_path) n = float(len(files)) idf = {} for i in files: root = ET.parse(self.doc_dir_path + i).getroot() title = root.find('title').text body = root.find('body').text seg_list = jieba.lcut(title + '。' + body, cut_all=False) seg_list = set(seg_list) – self.stop_words for word in seg_list: word = word.strip().lower() if word == '' or self.is_number(word): continue if word not in idf: idf[word] = 1 else: idf[word] = idf[word] + 1 idf_file = open(self.idf_path, 'w', encoding = 'utf-8') for word, df in idf.items(): idf_file.write('%s %.9f\n'%(word, math.log(n / df))) idf_file.close() def find_k_nearest(self, k, topK): self.gen_idf_file() files = listdir(self.doc_dir_path) dt_matrix = self.construct_dt_matrix(files, topK) self.construct_k_nearest_matrix(dt_matrix, k) self.write_k_nearest_matrix_to_db() if __name__ == "__main__": print('—–start time: %s—–'%(datetime.today())) rm = RecommendationModule('../config.ini', 'utf-8') rm.find_k_nearest(5, 25) print('—–finish time: %s—–'%(datetime.today())) 这个模块的代码量最多,主要原因是需要构建文档词项矩阵,并且计算k邻居矩阵。矩阵数据结构的设计需要特别注意,否则会严重影响系统的效率。我刚开始把任务都扔给了pandas.DataFrame,后来发现当两个文档向量合并时,需要join连接操作,当数据量很大时,非常耗时,所以改成了先用python原始的list存储,最后一次性构造一个完整的pandas.DataFrame,速度比之前快了不少。 ...

January 9, 2016 · 4 min