tf-idf算法_TF-IDF算法在实践中的应用

tf-idf算法

在这篇文章中，我将分享我对URL中的非结构化数据进行分类的经验。 我最终使用TF-IDF算法解决了手头的问题，并认为分享这些经验会很有趣。

这篇文章仅专注于解决问题，但是由于所使用的上下文与Plumbr有关，因此首先为不熟悉Plumbr的读者提供一些背景知识：

• Plumbr监视最终用户与应用程序的交互 。 每个这样的交互称为交易
• 事务 按消耗的实际端点分组在一起 。 例如，如果用户单击Web应用程序中的“添加到购物车”按钮，则从此类URL提取的端点可能是“ / cart / add / {item}”。 这些端点称为 服务 。

对于使用特定服务的事务失败或速度慢于预期的情况，Plumbr还在源代码中公开了根本原因。 作为Plumbr用户的主要利益，该产品的这一部分与本文内容无关。 因此，请不要忘记此功能。

作为完整的披露：该职位是对我最近毕业的硕士论文的总结。 科学 塔尔图大学研究所 。 除了在大学里攻读学位外，我还是Plumbr工程团队的一员，所以我将自己的工作和研究联系起来在这两个方面都受益是很自然的。

问题

我解决的问题与使交易与实际服务匹配有关。 为了理解当前的问题，让我们看一个例子。

让我们拥有一个Web应用程序，最终用户可以通过http://www.example.com上的传统HTTP GET / POST方法访问该应用程序。 达到此应用程序的实际交易可能如下所示：

• http://www.example.com/invoices/12345?action=pay
• http://www.example.com/invoices/98765?action=pay
• http://www.example.com/invoices/search?from=01-01-2015
• http://www.example.com/invoices/search?from=01-01-2015&to=31-01-2015

对于人类读者来说，很明显，上述四个事务正在访问两个不同的服务。 前两个交易是对发票“ 12345”和“ 98765”的付款尝试，后两个交易是在特定时间范围内搜索发票。

现在眼前的问题正盯着我们。 由于URL中特定资源或参数的标识符趋于更改，因此仅应用字符串比较的简单方法会使我们无法使用最简单的应用程序。

为了确定是否确实如此，我确实对Plumbr的实际生产部署中的数据集进行了测试。 该测试通过受监视的应用程序将事务的幼稚分组应用于服务。

由于39.5％的应用程序最终检测到5,000多个服务，因此明确证实了我的假设。 在11.6％的应用程序中，服务数量超过50,000。

这证实了我们的期望。 在他们的头脑中，没有人会考虑将500个不同的功能耦合到一个应用程序中，更不用说将5,000或50,000耦合在一起了。

解决方案

确认问题存在后，我现在必须确保只要事务在URL中具有动态部分（例如参数或资源标识符），我们就能够从URL中识别动态部分并将事务正确分组。

因此，即将进行的数据分析的需求可以汇总为：

• 区分URL中的“动态”和“静态”部分。
• 通过从URL中删除动态部分来规范化URL。
• 从规范化的URL生成服务名称，