TriagerX Bug Triaging Framework

• TriagerX is a bug triaging framework that utilizes a dual-transformer architecture to capture both semantic report content and historical developer interactions.
• The system integrates two distinct pretrained language models with CNN classifiers, using adaptive layer fusion and weighted voting to enhance ranking accuracy.
• Empirical results demonstrate significant improvements in developer and component recommendation accuracy, proving its efficacy in industrial deployments.

Searching arXiv for TriagerX and closely related bug triage work to ground the article in the cited literature. TriagerX is a bug triaging framework that combines transformer-based semantic modeling of bug reports with developer interaction history to rank candidate assignees and, in industrial settings, components as proxies for team assignments. It was introduced to address two limitations of prior pretrained LLM approaches: PLMs may still attend to less relevant tokens in a bug report, and recommendations can be sub-optimal when the interaction history of developers around similar bugs is not taken into account. The resulting system uses a dual-transformer architecture for content-based ranking and then refines that ranking with an interaction-based ranking methodology grounded in historical developer activity on similar fixed bugs (Mamun et al., 23 Aug 2025).

1. Problem setting and conceptual position

Bug triage is an essential task in software maintenance: it assigns developers to bug reports to fix them, and in manual settings it is performed by a triager who analyzes developer profiles and submitted bug reports to make suitable assignments. Earlier work has also framed bug triage as a resource allocation problem aimed at minimizing total fix time and normalizing developer workload rather than merely reproducing historical assignments (Mayez et al., 2022).

Within this setting, TriagerX is positioned as a PLM-based triaging system that departs from single-transformer baselines. Its central claim is that transformer encoders are useful because they can better capture token semantics than traditional machine learning models that rely on statistical features such as TF-IDF and bag of words, yet they remain insufficient if they do not explicitly account for less relevant token attention and for the developer-side interaction structure around similar bugs. TriagerX was designed precisely around these two deficiencies, using a content-based ranker to model report semantics and an interaction-based ranker to exploit historical development activity (Mamun et al., 23 Aug 2025).

A common misconception is that bug triage in modern repositories can be reduced to text classification alone. The TriagerX formulation rejects that reduction: the textual content of a report is treated as necessary but not sufficient, and historical interactions are modeled as an additional ranking signal. This suggests a hybrid view of bug triage in which semantic matching and socio-technical activity are complementary rather than competing sources of evidence.

2. System architecture

TriagerX comprises three main components: a Content-Based Ranker (CBR), an Interaction-Based Ranker (IBR), and a Rank Aggregator (RAgg). The CBR uses an ensemble of two pretrained LLMs, with examples given as RoBERTa-base and DeBERTa-base. Rather than relying on a single final-layer representation, it extracts embeddings from the last three layers of each PLM, applies adaptive layer weights, concatenates the resulting representations, and feeds them to multiple CNN classifiers. The classifier outputs are then combined by soft voting with learnable classifier weights (Mamun et al., 23 Aug 2025).

Component	Main function	Key mechanism
Content-Based Ranker	Produce content-based developer ranking	Two PLMs, last three layers, CNN classifiers
Interaction-Based Ranker	Refine ranking with historical activity	Similar-bug retrieval, interaction weighting, time decay
Rank Aggregator	Combine both rankings	Weighted sum of normalized scores

The layer-fusion and voting structure is summarized by the following expressions:

$$H_{concat} = \left( \big\|_{i=1}^{x} \text{PLM}_i(L-j) \times HW_{i, j} \right)_{j=0}^{K-1}$$

$$\hat{y}_{CBR} = \sum_{k=1}^{K} CW_{k} \times F(H^{(k)}_{concat})$$

In this formulation, two design decisions are especially characteristic. First, TriagerX uses two PLMs rather than one, on the premise that distinct pretrained models capture complementary or orthogonal knowledge. Second, it uses CNN classifiers over the fused PLM representations rather than fully connected networks. The model is fine-tuned with Knowledge Preservation Fine-Tuning (KPFT), which freezes earlier layers and trains later layers to preserve general knowledge while adapting to the bug triage domain (Mamun et al., 23 Aug 2025).

This architectural choice distinguishes TriagerX from single-transformer bug triage baselines. It also makes the system explicitly multi-view within the semantic channel itself: representation diversity arises both from multiple PLMs and from multiple late-layer features within each PLM.

3. Interaction-based ranking methodology

The interaction-based stage is intended to correct cases in which content similarity alone is insufficient. For a new bug report, TriagerX first retrieves similar past issues using cosine similarity over SBERT-generated embeddings:

$$\text{Similarity}(i, j) = \frac{\mathbf{e}_i \cdot \mathbf{e}_j}{\|\mathbf{e}_i\| \|\mathbf{e}_j\|}$$

Developers who interacted with those similar bugs are then gathered. The interaction inventory includes commits, pull requests, assignments, discussions, and related forms of historical participation. Each interaction type receives a tunable weight, and more recent contributions are amplified through exponential time decay:

$$IS(d_i) = \sum_{j}^{m} \sum_{k=1}^{n_{ij}} \text{Sim}(I_{new}, I_j) \cdot IP_{ijk} \cdot e^{-\lambda t_{ijk}}$$

Only active developers are considered, using a minimum threshold of 20 contributions. The resulting interaction scores are normalized as

$$NIS(d_i) = \frac{IS(d_i) - \min(IS)}{\max(IS) - \min(IS)}$$

and used for re-ranking (Mamun et al., 23 Aug 2025).

This interaction model differs from simpler historical-frequency formulations because it is contextual, typed, and time-sensitive at once. Similarity is computed on semantically encoded bug reports rather than unigram overlap; interaction types are differentiated rather than collapsed into a single count; and recency is explicitly modeled through the decay factor $e^{-\lambda t_{ijk}}$. A plausible implication is that TriagerX is particularly well suited to repositories in which stable teams repeatedly engage with semantically related bug families.

4. Score aggregation, training choices, and task variants

The final ranking combines the normalized content-based prediction score and the normalized interaction score:

$FS(d_i) = NPS(d_i) + W_f \cdot NIS(d_i)$

where $W_f$ is an optimized weight for the interaction-based ranker. If no interaction data is available for a developer, the system falls back to pure CBR ranking (Mamun et al., 23 Aug 2025).

Parameter selection is performed by grid search, including the interaction weighting parameters, similarity threshold $\tau$, time-decay parameter $\lambda$, and aggregation weight $$\hat{y}_{CBR} = \sum_{k=1}^{K} CW_{k} \times F(H^{(k)}_{concat})$$0. The reported implementation also uses weighted sampling and minimum activity thresholds to improve stability under class imbalance. In the repository settings studied, TriagerX is trained and evaluated on both developer recommendation and component recommendation tasks. The latter is operationally important because components act as proxies for team assignments, particularly useful in cases of developer turnover or team changes (Mamun et al., 23 Aug 2025).

This dual-task framing is significant. It indicates that TriagerX is not restricted to the canonical “which developer should fix this bug?” formulation. In industrial deployment, the same content-based architecture can be retargeted to a component label space, allowing team-level routing when direct individual assignment is undesirable or unstable.

5. Empirical performance and industrial deployment

Across five datasets, TriagerX surpasses all nine transformer-based methods, including SOTA baselines, and often improves Top-1 and Top-3 developer recommendation accuracy by over 10%. On the industrial partner’s dataset, it outperformed SOTA baselines by up to 10% for component recommendations and 54% for developer recommendations. The detailed results reported for representative datasets are as follows (Mamun et al., 23 Aug 2025).

Dataset/task	TriagerX Top-1	Comparative result
OpenJ9 developer recommendation	32.7%	54% better than LBT-P; 58% better than RoBERTa-Large-CNN
TypeScript developer recommendation	35.3%	26% above LBT-P; 10% above best PLM
OpenJ9 component recommendation	78.2%	10.6% above LBT-P on 9 components

On classic open-source datasets such as Google Chromium, Mozilla Core, and Mozilla Firefox, the content-based TriagerX configuration reaches up to 34.5% Top-1 accuracy on Google Chromium, with improvements described as up to 8–22% better than SOTA baselines. The reported ablations further state that moving from a single PLM to a dual-PLM ensemble yields about 10–20% relative gains, that CNNs outperform fully connected alternatives, and that adding the interaction-based stage improves Top-1 by 4.5% in a stable-team repository. The gains are reported as statistically significant with $$\hat{y}_{CBR} = \sum_{k=1}^{K} CW_{k} \times F(H^{(k)}_{concat})$$1 (Mamun et al., 23 Aug 2025).

TriagerX was deployed with a large industry partner in a development environment identified in the detailed summary as IBM/OpenJ9. The deployed system runs as a Dockerized API or bot and delivers recommendations in near real time, with 3–4 seconds per issue on CPU and about 100 ms on GPU. Industrial feedback reports an 82.5% acceptance rate for Top-3 recommendations in usage and 66.7% for issues that led to code contributions. The system also retrains automatically as team composition changes, for example when new developers reach 20 contributions (Mamun et al., 23 Aug 2025).

These results indicate that the interaction-based stage is most valuable in repositories with stable, richly logged collaboration histories. The same evidence also suggests that the content-based stage retains importance as a fallback and as the primary mechanism for cold-start or weak-history cases.

6. Relation to earlier bug triage methods, limitations, and outlook

Earlier automated bug triage work has treated the problem as information retrieval, classification, or resource allocation. One resource-allocation formulation combines matrix factorization, iterative Gale-Shapley matching, and differential evolution to reduce total bug fixing time and normalize developer workload across Linux, Eclipse, and Apache repositories (Mayez et al., 2022). TriagerX operates in a different design space: it prioritizes PLM-based semantic modeling and historically grounded interaction ranking rather than direct optimization of fix-time objectives (Mamun et al., 23 Aug 2025).

The main limitations explicitly noted for TriagerX are difficulty with infrequent or new developers and heavily imbalanced datasets. These issues are mitigated through the active-developer threshold and weighted sampling, but they are not eliminated. The system therefore remains partly dependent on historical participation density, especially for the interaction-based stage. Another practical boundary is that the usefulness of the interaction signal varies across repositories: it is more valuable in stable, well-interacted repositories than in repositories with sporadic contributors (Mamun et al., 23 Aug 2025).

A broader misconception is that larger single PLMs should dominate smaller ensembles. The TriagerX results argue against that generalization within bug triage: the reported dual-base-PLM ensemble is described as smaller but more accurate than large-PLM baselines. This suggests that model diversity and task-specific aggregation may be more important than parameter scale alone in this domain.

Future work identified for TriagerX includes feedback-adaptive models and explainable recommendations using LLMs. In that sense, TriagerX can be understood as a transitional system in bug triage research: it preserves the rank-based structure of earlier assignment systems, but relocates the core scoring machinery to a dual-transformer semantic stack augmented by historically weighted developer interactions (Mamun et al., 23 Aug 2025).