DeltaShield: Information Theory for Human- Trafficking Detection

We use the notation \({\left\lt n\right\gt }\) for the coding cost of integer n, using the universal code length [47]—that is, \({\left\lt n\right\gt } = \log ^{*}{n} \approx 2 \times \lg {n} + 1\).

We also assume that we have V vocabulary words total and that each is encoded as an index, requiring \(\lceil \lg {V} \rceil\) bits. For a length-l document, we need \({\left\lt l\right\gt }\) bits to encode the number of words and \(\lg {V}\) for each word, resulting in the total cost \({\left\lt l\right\gt } + l * \lg {V}\).

Let us describe every term of the preceding definition:

Given a template and a document that it describes, what is the best way to encode the document? The intuition is to encode insertions, deletions, and substitutions in the template and the tokens in slots. For the templates, we need only encode the word location of a mismatch; its type; and, for insertion/substitution, we encode the relevant word.

where \(D_{i}\) denotes the data encoded by template \(T_{i}\). We describe this definition in more detail. Let \(D_{U}\) denote the documents that do not match any template. The encoding cost for data \(d \in D_{U}\) that is not encoded by template is simply computed by \(l_d \times \lg {V}\). For the rest, the reasoning is as follows: given a template \(T_i\) and a document \(d \in D_{i}\), the alignment coding cost is

Notice that we ignored the cost of encoding the vocabulary, since it would be the same for all sets of templates, and roughly the number of bytes to spell out all the vocabulary words, separated by a word delimiter, such as a newline character. More accurately, this would be \({\left\lt V\right\gt } + V \times (l + 1) \times 8,\) where l is the average word length, 8 bits per character, and 1 bit for the delimiter between words.

How do we generate a meaningful document embedding? We wish to capture similarity between documents that contain similar phrasing, but may have small variations (insertions, deletions, misspellings, etc.). To this end, we first calculate the tf-idf weights for each phrase (n-gram)-document pair in the corpus. When calculating tf-idf, we consider phrases up to n-grams, with \(n=5\).¹

Then, for each document, we extract the top phrases with the highest tf-idf scores. By using tf-idf and limiting the number of phrases used, we only keep the most important phrases in the document that are unique to only a few advertisements while ignoring commonly used phrases. By making the number of phrases selected a function of input size, we reduce the risk of our results being heavily impacted by document length. Since some documents have a maximum length (i.e., tweets) but many do not, this helps prevent InfoShield-coarse from being domain specific.

Now, how do we quickly create meaningful candidate clusters? We construct a bi-partite graph of documents and phrases. For any document i and phrase j, we construct an edge \(i, j\) if j is a top phrase in i. Once all documents are processed, we consider all connected components in G to be our coarse-grained clusters.

In the case that these clusters end up too large (due to an “unimportant” phrase that combined documents that ideally should not be combined), we rely on InfoShield-fine to refine these clusters and split them if necessary. This is why InfoShield-coarse is very permissive, only requiring ads to share one important phrase to be connected.

Algorithm 1 shows more formally how to construct a document graph using InfoShield-coarse.

Given data D from one cluster generated by InfoShield-coarse, containing multiple documents at iteration i, the candidate set for the template needs to be identified first. We first align all the documents \(d \in D\) with the first document \(d_{1}\) individually and then compute the cost \(C(d | d_{1})\) and \(C(d)\) for every \(d \in D\); if \(C(d | d_{1})\) is smaller than \(C(d)\), meaning that d and \(d_{1}\) have high similarity and can possibly be encoded by the same template, we add d into the set \(D_{i}\) containing all similar documents found in iteration i. Finally, we generate the alignment \(A_{i}\) by the POA method with all documents in \(D_{i}\).

After generating alignment \(A_{i}\), how do we decide which tokens are part of the template, and which are insertions/deletions/substitutions? Keeping too many words in the template causes more unmatched operations (insertion/deletion/substitution), whereas keeping too few words hurts interpretability.

To solve this problem automatically, we turn it into an optimization problem by MDL. Function \(Sel(A_{i}, h)\) is used to select the sub-alignment from the POA graph, where we only keep edges between words that occur more than h times in \(A_i\). We aim to search for the best threshold \(h_{i}^{*}\) to generate the consensus of alignment with the lowest cost. The optimization problem can then be formed as follows:Although our cost function is not convex, the optimization problem is only one-dimensional, being relatively easy to solve. Hence, we employ the Dichotomous Search algorithm [10] as our optimization method, where it returns the optimal solutions in most cases. The optimization algorithm is shown in Algorithm 2, where we iteratively shrink the search space to half. The consensus document \(T_{i}^{^{\prime }}\) only contains one sequence and no slot.

Once we have a template, how do we find slots? Slots contain parts of documents that we expect to differ, either in length or content, in the same location of each document. Slots inherently differ from unmatched words; instead of storing the location of each unmatched word per document as we would for unmatched words, we only store the location once, as part of the template.

Algorithm 3 shows how we do slot detection. We first recognize the operation types of words by each alignment \(a \in A_i\), which are either insertions or substitutions. We identify which words each potential slot p contains in the given consensus document \(T_{i}^{^{\prime }}\). With this information, the computation of total cost with or without the slot p can easily be done. We only keep slots that decrease the total cost and store them in \(T_i\).

To study the quality of compression by InfoShield-fine, we use relative length:When relative length is close to 1, it means that the quality of compression is low; when it is close to lower bound, it means that the quality of compression is high, and the compressed documents are near-duplicate. For that reason, we derive the lower bound encoding cost of a cluster to study whether it is close to near-duplicate or not.

The overall algorithm of InfoShield-fine is shown in Algorithm 4. Given data D containing multiple documents from one cluster by InfoShield-coarse, we first initialize the template set \(\mathcal {T}\) and the number of detected template i. At iteration i, we initialize alignment by the first document \(d_0 \in D\). We compare with all other documents \(d \in D\) to identify whether they should be encoded by the same template. After generating the alignment \(A_{i}\) and the data \(D_{i}\) that it encodes, we search for the best consensus sequence \(T_{i}^{^{\prime }}\) by optimizing the cost function. Then, we detect the slots on the consensus sequence \(T_{i}^{^{\prime }}\) to generate template \(T_{i}\). We include the \(T_{i}\) into our template set \(\mathcal {T}\), and compute the total cost for both templates and data encoded by templates. If the total cost decreases by including \(T_{i}\), we include it into \(\mathcal {T}\) and update the total cost; otherwise, we treat \(D_{i}\) as noise. We run InfoShield-fine on every cluster generated by InfoShield-coarse, thus our final model M is \(\mathcal {T}_1 \cup \mathcal {T}_2 \cup \dots \cup \mathcal {T}_m\), where m is the number of coarse clusters. It is worth noting again that InfoShield-fine is parameter-free, needing no human-defined parameters and optimizing for each template automatically.

We propose Algorithm 5 as a preprocessing step before trying to generate a new template in Algorithm 4. If we were able to process all documents at once, the intuitive solution is to go through all the documents and generate templates. However, in an online setting, we often see documents from any one template span over multiple batches. To this end, the preprocessing step tries to encode an incoming document by all existing templates in its coarse cluster and select the template with the lowest encoding cost. If the cost by the selected template is lower than the encoding cost of the document itself, we consider that the document belongs to that template.

Unfortunately, the time complexity of examining all the existing templates is \(O(k_{max}l^{2})\). If a coarse cluster has a large number of templates, we will incur a large overhead. To address this, we adopt an Early-Stopping (ES) mechanism in Algorithm 6. Instead of sequentially investigating all templates in a coarse cluster, we order the templates by the lengths of intersection between unigrams in the incoming document and each template. Then, we select the first template that lowers the encoding cost of the document.

Later in Section 6.6.2, we will demonstrate that the ES mechanism largely improves the efficiency while achieving comparable effectiveness.

Once the new documents are added into a template, its representation will be slightly changed. It is also important to update the template to represent new documents. Hence, we perform an updating step, Algorithm 7, right after Algorithm 4. It is worth noting that we only update templates that now represent any new documents. Furthermore, since changes in templates tend to be gradual over time, it is not necessary to process the updating step in every batch. We can set either a threshold (e.g., 200 more documents) or an interval (e.g., 1 month) to trigger this step to improve the efficiency. We will demonstrate the tradeoff between effectiveness and scalability using interval and threshold setting in Section 6.6.2.

We use data from [11] (Table 7). This data includes the tweet text and user id. The data is split into the following categories.

To create each test set, Cresci et al. [11] sampled all tweets from 50% genuine accounts, and 50% from either social spambots #1 or social spambots #3. We use the provided test sets, which focus on social spambots only, so we can easily compare results to the best-performing methods in their work [11].

This data not only contains binary labels as to whether particular tweets were posted from bots or legitimate users but also inherent clusters—that is, user ids that correspond to legitimate users or bots.

We expect InfoShield to cluster most tweets from bots in clusters, ideally in one cluster per bot, and to have few clusters with legitimate users in them. With this intuition, we can create ground truth cluster labels in Twitter data as follows: (1) all legitimate users get labeled –1, since we assume their tweets are different enough that they should not be clustered together; (2) all bots get labeled with their user id.

The Trafficking10k dataset is created in the work of Tong et al. [52], where expert annotators manually labeled 10,265 ads from 0 to 6; 0 represents “Not Trafficking,” 3 represents “Unsure,” and 6 represents “Trafficking.” There are 6,551 ads labeled as not HT, 354 labeled as “Unsure,” and 3,360 labeled as HT.

Since the likelihood of an ad being HT is subjective, labeling is a difficult task. In fact, our analysis shows that 40% of exact duplicate ads (without any preprocessing) had label disagreement (i.e., multiple labels for the same exact text). Ads that are exact duplicates account for 12% of the dataset. We expect this labeling issue to occur for near duplicates as well. Therefore, we argue that looking at ads individually, whether manually or algorithmically, is a non-ideal way to find or to label HT cases.

Despite the noisy labels, this is the only HT dataset to our knowledge with labeled data by human investigators. Thus, we use this dataset in our experiments while being aware that noisy labels may impact results.

This data does not have ground truth clusters. However, to create binary labels, we can call scores from 0 to 3 as not HT and those from 4 to 6 as HT.

Cluster Trafficking is a new dataset provided by Marinus Analytics. This data contains cluster labels, provided by domain experts, for both HT and for a strange behavior, which we will call escort spam.

We are given six spam clusters as well as ads from 96 massage parlors around the United States. Cluster Trafficking consists of 157,258 ads, with 6,283 spam ads, 50,985 HT ads, and 99,990 normal ads.

Most state-of-the-art methods for HT detection are not open sourced. Instead, we compare against HTDN [52], which uses the same Trafficking10k dataset, and develop three baselines using state-of-the art text embedding methods Word2Vec [40], FastText[6], and Doc2Vec [31]. We train all models using 1 million escort advertisements from the web. Then, we cluster using HDBSCAN [38] with a minimum cluster size of 3. We call these methods Word2Vec-cl, Doc2Vec-cl, and FastText-cl.

On Twitter data, we compare to three supervised methods [1, 13, 53] and one unsupervised method [12]. These methods all use Twitter-specific features that our domain-independent InfoShield does not use, such as number of mentions, favorites, retweets, and posting time. The unsupervised method is also not fully automatic, as a manually set threshold discerns spam from legitimate tweets, which they change for each dataset. Regardless, InfoShield provides comparable results to these baselines.

For Twitter data, we have both binary labels and ground truth cluster labels. To compare binary labels, we can report precision, recall, and F1 score. For cluster labels, we use the Adjusted Rand Index (ARI) [24].

We calculate precision, recall, and F1 by calling all documents that ended up in templates to be suspicious and all other documents as not suspicious.

As shown in Table 9, we find that 23 Spanish tweets are encoded by the given template. The first 22 tweets are exact duplicates, but the last one contains three different words. InfoShield-fine automatically determines that representing those different terms as unmatched results, rather than as a slot, gives a smaller total cost. We can easily spot anomalies within clusters by using the template; the last tweet will have a lower compression rate than all other tweets.

In Table 10, we find that all the tweets are talking about the most popular weekly stories. Although the first half of all tweets are almost identical, with minor syntax differences, the second half describes the particular stories, which all differ. InfoShield-fine then detects the second half of each sentence as a slot, which we expect to have different content in each tweet. This will help researchers pay attention to the parts most worthy of studying.

In Table 11, we show an example template from the HT domain. Unfortunately, we must censor the text to protect potential HT victims, so we only provide the highlighting from the template. For the slots, we give a description of the type of text they represent.

Notice that slots tend to include consistent user-specific information. For example, the second slot, if not empty, always discusses time. With a quick glance, a domain expert can easily find this data rather than looking at a longer wall of text. For the HT domain, interpretability is key: law enforcement will only have to read one template, rather than each cluster member individually, to determine if this cluster is suspicious.

The slots also contain messy data—that is, although each slot has a specific purpose in Table 11, the text can be in multiple formats, such as “until 9pm” versus “9 P.M.” Work could be done to automatically extract and process the information within each slot, but this is beyond the scope of this work.

Next, we consider the relative length to further investigate the clusters detected by InfoShield. How does the relative length of a micro-cluster change as a function of the number of documents? Do we notice any differences between the relative lengths of spam clusters versus HT clusters? Using the Cluster Trafficking dataset, we illustrate the lower bound of relative length versus the number of documents per cluster in Figure 5(a), where the black lines from left to right denote the lower bound of clusters with one to four templates. For example, the clusters with two templates (orange dots) cannot be on the left side of the second black line. As shown in Figure 5(b), most clusters are concentrated by the lower bound, meaning that they do not have high numbers of documents. Further analysis surprisingly finds that spam and HT clusters follow patterns in this space. As shown in Figure 5(c), most spam clusters (red stars) have small relative length with a high number of documents; in Figure 5(d), there are two patterns of HT clusters (blue stars): (1) the near-duplicate clusters with a high number of documents (but slightly lower than spam clusters) and (2) the outlier clusters that lie far from the lower bounds.

How do the document-term graphs generated by DeltaShield-coarse compare to the ones generated by InfoShield-coarse? The main difference between these algorithms is the approximation of tf-idf scores in DeltaShield-coarse. To measure the impact of this approximation, we compute the ARI and Homogeneity (HOM) scores [48] between the cluster labels produced by DeltaShield-coarse and InfoShield-coarse. A high score signifies that the coarse clusters generated by DeltaShield-coarse are very close to the original coarse clusters generated by InfoShield-coarse. We run this experiment for both HT and both Twitter datasets, as shown in Table 12.

We see that all metrics are high, meaning that we do not lose much information by using DeltaShield-coarse and processing ads incrementally.

Here, we compare the effectiveness and efficiency of DeltaShield-fine. We first compare Algorithm 5 (Naive) and Algorithm 6 (ES) to demonstrate that the ES method not only outperforms Naive but also dramatically decreases the running time. We then study the choice of update frequency, which results in a tradeoff between effectiveness and efficiency.

In this experiment, we test an extreme case with the Cluster Trafficking dataset to truly reflect the difference between methods. The dataset is considered as a one big cluster and separated into 18 batches where each batch contains about 2,000 advertisements. Note that InfoShield-coarse is not used in this experiment so that we can stress test DeltaShield-fine with a large number of templates. Since our goal of incremental version is to output as close to the non-incremental one, the ARI score is used as the effectiveness metric here, where the ground truth is clustering labels generated by InfoShield-fine. It is worth noting that this extreme case will not happen if InfoShield-coarse is still implemented, meaning the ARI score is expected to be low. Our empirical result shows that the average number of templates in one cluster generated by InfoShield-coarse is about 3, which is largely smaller than the number in our experiment (as shown in Figure 7(b), it is already more than 200 after batch number 4).

ES versus Naive. The ARI scores over time are shown in Figure 7(a), where we can see that the ARI score of the ES method is always higher than the Naive method after the second batch. As depicted in Figure 7(b), as the number of templates (green line) grows over time, the running time of fitting the templates increases linearly as well. If we compute the slope by the number of templates and running time, the slope of the Naive method is 18, whereas the one of the ES method is 3, which is six times smaller than the Naive method. In Figure 7(c), the ES method achieves a result with only 10% difference comparing to the Naive method, which is more or less a tie. In Figure 7(d), we find that the ES method always outperforms the Naive method more clearly in terms of runtime.

Update Frequency. Next, we study the tradeoff between effectiveness and efficiency. We mainly compare DeltaShield-fine with update frequency every batch and every three batches. In Figure 8(a), we see that as the number of incoming batches increases, the gap between two methods increases as well. Nevertheless, the running time of updating every three batches shown in Figure 8(b) is 1.4 times and 2.8 times faster than the one of updating every batch and InfoShield-fine, respectively. It will substantially mitigate the expensive overhead when the number of clusters and templates are large, which is especially important to the law enforcement where every second counts for them.

We notice that the low update frequency will slightly hurt the performance. However, we keep in mind that this experiment stress tests DeltaShield-fine, since the number of templates in one coarse cluster is much larger than it will be if we first use DeltaShield-coarse. Alternatively, an end user can consider doing the recomputation of all data periodically, depending on their idle time.