Add LiftWing model visualization feature

[zache-fi]

Add a new web page to PendingChangesBot that allows users to visualize how LiftWing machine learning models evaluate Wikipedia articles over their revision history.

User Story

As a user, I want to select a Wikipedia article and visualize how different LiftWing model scores have changed across its revision history, so that I can better understand how these models work and how article quality evolves over time.

Links

• https://meta.wikimedia.org/wiki/Machine_learning_models
• https://meta.wikimedia.org/wiki/Machine_learning_models/Production/Language-agnostic_Wikipedia_article_quality

Example code

import json
from pywikibot.comms import http

url = 'https://api.wikimedia.org/service/lw/inference/v1/models/revertrisk-multilingual:predict'
headers = {
    'Content-Type': 'application/json',
    'User-Agent': 'PendingChangesBot/1.0 (https://fi.wikipedia.org/wiki/User:SeulojaBot)'
}
payload = json.dumps({'rev_id': 23599483, 'lang':'fi'})  # your rev ID
resp = http.fetch(url, method='POST', headers=headers, data=payload)
print(resp.text)

Feature Requirements

1. Wiki and Article Selection

• Add new web page to PendingChangesBot interface
• Implement wiki selection using existing main wiki selection interface
• Add text search field for article selection within the selected wiki (see https://pageviews.wmcloud.org as example)
• Validate article exists before proceeding

2. Revision History Fetching

• Fetch complete revision history for selected article starting from first revision
• Store revision data in local database using existing PendingChangesBot database model
• Handle pagination for articles with large revision histories
• Implement error handling for API failures

3. LiftWing Model Selection

• Create configuration file defining available models per Wikipedia language version
• Implement model selection interface (dropdown or checkboxes for multiple selection)
• Filter available models based on selected wiki's language
• Start with a subset of commonly used models (specify which in implementation)

4. Model Data Fetching and Caching

• Fetch LiftWing model predictions for each revision of the selected article
• Cache model values in local database to avoid redundant API calls
• Implement background/async loading for large revision sets
• Add loading indicators during data fetching
• Handle cases where model data is unavailable for certain revisions

5. Visualization - Line Graph

• Implement interactive line graph with:
  • X-axis: Revision number/sequence
  • Y-axis: Model prediction values
• Support multiple lines when:
  • Multiple models are selected
  • Single model returns multiple values per revision
• Use different colors for each data series
• Add legend identifying each line/model/value
• Make graph responsive and interactive (zoom, hover for values, etc.)
• If it easy to implement make graph clickable so

6. Revision List Table

• Display revision list below the graph with columns:
  • Timestamp
  • Username
  • Edit comment
  • Model value(s)
• Make timestamp clickable, linking to diff view on the specific Wikipedia
• Synchronize table with graph (e.g., highlight row when hovering over corresponding point)
• If user clicks the graph then show diff below of the graph. See the Show human readable reviews when you run autoreview #42 for as example.

Technical Considerations

• Extend existing PendingChangesBot database model to store:
  • Complete revision history (not just pending changes)
  • Cached LiftWing model predictions per revision
  • Model metadata and timestamps

[Nirmeet-kamble]

Taking this up @zache-fi Can you please assign?

[Teja-Sri-Surya]

Hi @zache-fi , I'd like to work on the issue, can we collab.

[Nirmeet-kamble]

Hey, I am about to finish it up. Can you do the review part or any extra changes which required?

[Teja-Sri-Surya]

Hi @Nirmeet-kamble , that sounds great! 😊
I’d be happy to help with the review, testing, or making any additional improvements once your implementation is up.
Please let me know when you open the PR — I can test the new visualization page locally and share detailed feedback or work on any enhancements if needed.

Thanks for the update! Excited to collaborate on this feature.

[Nirmeet-kamble]

Yes sure, I will raise an pr eod

[zache-fi]

Yeah go for it :)

[Teja-Sri-Surya]

Hey, once you push the PR, I’ll review and test it locally

[sergyDwhiz]

Hi @Teja-Sri-Surya!
Really great work here from you guys.

However, In the fetch_liftwing_predictions view, the code currently makes a separate API call for every single revision ID. If the frontend requests scores for 50 revisions, it will result in 50 sequential network requests, which might be quite slow.

for rev_id in revisions:
# This makes a new request inside the loop for every revision
resp = requests.post(url, json={"rev_id": rev_id}, timeout=10)

the LeftWing api supports batch request, so we could send all revision IDs in a single API call, which is much more efficient. Please let me know what you think about this.

[Teja-Sri-Surya]

Hi @Teja-Sri-Surya! Really great work here from you guys.

However, In the fetch_liftwing_predictions view, the code currently makes a separate API call for every single revision ID. If the frontend requests scores for 50 revisions, it will result in 50 sequential network requests, which might be quite slow.

for rev_id in revisions: # This makes a new request inside the loop for every revision resp = requests.post(url, json={"rev_id": rev_id}, timeout=10)

the LeftWing api supports batch request, so we could send all revision IDs in a single API call, which is much more efficient. Please let me know what you think about this.

Hi @sergyDwhiz! 👋
Thank you so much for the valuable feedback and for taking the time to review our PR 🙏

You're absolutely right — the current implementation does make sequential API calls for each revision, which could indeed slow things down when handling many revisions. Implementing batch requests would definitely make the process more efficient.

Before proceeding, I’d like to confirm whether the LiftWing API officially supports batch requests. I’ve been reviewing the all things but haven’t found a clear example of sending multiple rev_id values in a single request yet.

If it does support batching, I can refactor the current implementation to send all revision IDs in a single API call — this would significantly improve performance and reduce latency.

Could you please confirm or share a reference on the batch request format supported by LiftWing? Once confirmed, I’ll proceed with optimizing this part.

[sergyDwhiz]

Hi @Teja-Sri-Surya, yes it does please.
Sorry for my late response.

[Teja-Sri-Surya]

Hi! @sergyDwhiz Thank you for the confirmation and excellent feedback on the performance issue! 🙏
✅ Optimization Implemented

I've refactored the LiftWing prediction fetching to use parallel requests instead of sequential ones, significantly improving performance.

What Changed:

Before (Sequential - Slow):

for rev_id in revisions:
 resp = requests.post(url, json={"rev_id": rev_id}, timeout=10)

• 50 revisions = 50 sequential requests = ~100 seconds ⏱️

After (Parallel - Fast):

with ThreadPoolExecutor(max_workers=10) as executor:
Makes up to 10 concurrent requests simultaneously
future_to_rev = {executor.submit(fetch_single_prediction, rev_id): rev_id
for rev_id in revisions}

• 50 revisions = 5 groups of 10 parallel requests = ~10 second