使用MALLET的最佳主題建模工作流程是什么？

Question

介紹

我想知道其他主題建模師認為是從預處理到維護的最佳主題建模工作流程。 雖然這個問題包含了許多子問題（我將在下面指出），但我相信這個帖子對我自己和其他有興趣了解端到端流程最佳實踐的人有用。

提出的解決方案規范

我希望建議的解決方案最好依賴於R進行文本處理（但Python也可以），主題建模本身也可以在MALLET中完成（盡管如果您認為其他解決方案效果更好，請告訴我們）。 我傾向於使用R的topicmodels包，但是我想切換到MALLET因為它提供了超過topicmodels許多好處。 它可以處理大量數據，它不依賴於特定的文本預處理工具，它似乎被廣泛用於此目的。 但是，下面列出的一些問題也與topicmodels有關。 我想知道其他人如何處理主題建模以及可以改進以下哪些步驟。 任何有用的建議都是受歡迎的。

大綱

以下是它的工作方式：我將完成工作流程，在我看來工作得相當好，我將在每一步都概述問題。

建議的工作流程

1.清理文字

這涉及刪除標點符號，數字，停用詞，詞干和其他文本處理任務。 其中許多可以通過函數（例如來自R的包tm TermDocumentMatrix作為術語 - 文檔矩陣分解的一部分來完成。

問題：然而，可能需要使用諸如gsub函數直接對文本字符串執行此操作，以便MALLET使用這些字符串。 直接執行字符串並不像重復那樣有效（例如，同一個單詞必須多次被刪除）

2.構建功能

在這一步中，我們構建一個術語 - 文檔矩陣（TDM），然后根據頻率和TF-IDF值過濾術語。 最好將你的包的功能限制在1000左右。 接下來查看條款並確定需要（1）刪除 （一些停用詞將通過）， （2）重命名或（3）與現有條目合並 。 雖然我熟悉干完成的概念，但我發現它很少有效。

問題： （1）不幸的是MALLET不能與TDM結構一起使用並且要使用你的TDM，你需要找到原始TDM（沒有刪除任何功能）和你滿意的TDM之間的區別。 這種差異將成為MALLET的停止詞。 （2）關於這一點，我還想指出，功能選擇確實需要大量的手工工作，如果有人對如何最小化它有任何想法，請分享您的想法。

旁注：如果您決定單獨使用R ，那么我可以推薦具有函數dfm的quanteda包，該函數接受thesaurus作為參數之一。 這個詞庫允許捕獲模式 （通常是正則表達式）而不是單詞本身，所以例如你可以有一個模式\\\\bsign\\\\w*.?ups? 這會匹配sign-up ， signed up等等。

3.找到最佳參數

這很難。 我傾向於將數據分解為測試序列集並運行交叉驗證，擬合k主題的模型並使用保持數據測試擬合。 記錄對數可能性並針對不同主題分辨率進行比較。

問題：對數似然確實有助於理解擬合的好壞，但（1）它往往表明我需要更多的主題而不是實際上合理的; （2）考慮到擬合模型通常需要多長時間，它是幾乎不可能找到或測試最佳值的網格，例如迭代，alpha，老化等。

旁注：在選擇最佳主題數時，我通常會選擇一個主題范圍遞增5左右，因為將范圍遞增1通常需要很長時間來計算。

4.維護

可以輕松地將新數據分類為一組現有主題。 但是，如果您隨着時間的推移運行它，您自然會期望某些主題可能不再相關，而新主題可能會出現。 此外，研究主題的生命周期可能是有意義的。 這很難解釋，因為您正在處理需要無監督解決方案的問題，而且隨着時間的推移需要跟蹤它，您需要以受監督的方式處理它。

問題：要克服上述問題，您需要（1）將新數據擬合到一組舊主題中， （2）根據新數據構建新主題模型（3）監控日志可能性值隨時間變化並設計閾值什么時候從舊換成新的; （4）以某種方式合並新舊解決方案，以便主題觀察者能夠發現主題的演變。

回顧問題

• MALLET消耗數據的字符串清理效率低下。
• 功能選擇需要手動工作。
• 基於LL的最佳主題選擇數量不能解釋實際上合理的問題
• 計算復雜性沒有機會找到最佳參數網格（主題數量除外）
• 隨着時間的推移維護主題會帶來挑戰性問題，因為您必須保留歷史記錄，但也要反映當前相關的內容

如果你已經讀到那么遠了，我想感謝你，這是一個相當長的帖子。 如果您對該建議感興趣，請隨意在您認為相關的評論中添加更多問題，或者就如何克服某些問題提出您的想法。

干杯

Answer 1

感謝您的全面總結！

作為topicmodels的替代方案，嘗試使用R中的包mallet 。它直接從R在JVM中運行Mallet，並允許您將結果作為R表提取。 我希望盡快發布新版本，並且與其他人要求的tm構造的兼容性。

為了澄清， 文檔最多約為1000個令牌（ 不是詞匯表）是一個好主意。 更多，你開始失去有用的信息。 模型的假設是給定文檔中令牌的位置不會告訴您有關該令牌主題的任何信息。 對於較長的文檔而言，這種情況很少發生，因此有助於將其分解。

我要補充的另一點是，太短的文檔也可能是個問題。 例如，推文似乎沒有提供關於單詞共現的足夠的上下文信息，因此該模型通常會轉換為每個主題一個主題的聚類算法。 結合多個相關的短文檔可以產生很大的不同。

詞匯策划在實踐中是主題建模工作流程中最具挑戰性的部分。 在標記化之前用單個標記替換選定的多字詞（例如通過交換下划線的空格）是一個非常好的主意。 詞干幾乎從來沒用過，至少對英語來說是這樣。 自動化方法可以幫助詞匯策划，但這一步驟對結果產生了深遠的影響（遠遠超過主題數量），我不願意鼓勵人們完全信任任何系統。

參數：我不相信有正確數量的主題。 我建議使用一些主題，這些主題提供適合您應用程序的粒度。 可能性通常可以檢測到您的主題太少，但在閾值之后它不會提供太多有用的信息。 使用超參數優化會使模型對此設置的敏感性降低，這可能會減少搜索所需的參數數量。

主題漂移：這不是一個很好理解的問題。 更多真實世界語料庫變化的例子會很有用。 尋找詞匯量的變化（例如，詞匯外單詞的比例）是模型適合程度的快速代表。