我注意到 doc2vec 模型在相似性计算过程中存在潜在的冗余。看来,在选择推荐菜谱时,重新计算所有向量,并且随着菜谱数量的增长,相似度呈指数级增长。我正在寻求解决这个问题,并想了解如何最大限度地减少 doc2vec 模型中操作的冗余。
我正在寻找有关 doc2vec 模型中应用的潜在技术或优化策略的信息,以最大限度地减少相似性计算和向量计算期间的冗余操作。有人可以建议如何识别 doc2vec 模型中的这种冗余吗?是否有特定部分导致冗余计算?
如果可能的话,提供代码中的示例或似乎发生冗余的特定部分将不胜感激。我恳求。请帮助我
谢谢你。
我想知道 GitHub 上的 doc2vec 模型中相似度计算中出现操作冗余的地方
GitHub 网址:https://github.com/piskvorky/gensim/blob/develop/gensim/similarities/docsim.py
当您执行 Gensim
.most_similar()
模型的 Doc2Vec
文档向量集合的默认 .dv
操作时,它会执行两件事:
第一步将主导所花费的时间,并且与模型存储的文档向量数量呈线性关系,并且由单个批量点积主导,作为对底层优化 BLAS 库的单次调用完成。
(第二步可能不仅仅是线性的,但考虑到它是简单的标量比较,并且仅对前 10 个结果进行精确分辨率,相对较快。)
如果您提供的非默认
topn
超过 10
,也许达到已知文档向量的完整计数,则该平衡可能会稍微改变 - 但在任何情况下,它都不应该以以下方式变慢:模型大小呈“指数”增长。
(您还可以提供
topn=0
来选择性地获取所有相似性的数组,按照文档向量的存储顺序,无需按大小进行任何排序 - 从而在时间上获得与候选文档向量的数量严格线性的结果比较。)
您指向 Gensim 项目中的不同源代码 URL – 对于
docsim.py
文件 – 其中包括一些用于其他类型批量查找和排序的实用程序,但也不要说明您是该模块的哪一部分使用或显示任何代码。因此,很难猜测您可能会遇到什么。
但请注意:一些
docsim.py
主要是为 other 文本向量模型(例如稀疏的“词袋”文档表示)开发的,包括那些需要分片到磁盘的模型,因为它们溢出了 main内存。
如果您的主要方法是
Doc2Vec
类 – 在正常操作中只有当您的全套密集文档向量可以同时位于 RAM 模型中时才实用 – 您可能不需要在 docsim.py
文件中使用任何代码.
如果您出于某种原因需要坚持当前的方法,那么您需要理解代码的所有内容都应该位于您已经链接到的完整源代码中。
寻找潜在的性能优化通常需要使用额外的工具进行分析代码,特别是您的数据/用例,这可以准确地突出显示哪些代码范围占用了最多的时间。然后,您可以将额外的注意力集中到那些关键的、造成延迟的区域,作为调整算法、缓存可重用结果等的地方。
即使没有看到您的代码,或者暗示一些有关性能问题的测试结果,其他人也不可能仅仅指出问题或潜在的改进。
虽然它是可能,但是其他人都忽略了一些简单的低效率问题,但更常见的是,事情就这么简单,代码本来就更好了。
因此,如果您想获得帮助以深入挖掘:
代码中的错误或低效选择可能会造成影响,因此正确的修复将在 Gensim 类之外。 (例如:您是否要求重复相同的昂贵计算,以便您的代码可以缓存以供重用?)
如果您为此问题添加更多详细信息(您可以对其进行编辑以展开),或者当您有更清晰的目标时发布新的更详细的问题,我将很乐意进行审核/评论。 (或者,如果在任何时候您有足够的证据来确定和证明 Gensim 代码存在可修复的不良性能问题,您也可以将其作为错误/功能请求提交到 Github 的 Gensim 问题跟踪器 中。)