Automated Grading in Practice: A Local AI Scoring Solution Built with LLMs and Desktop Technology

1. Background: Why Automated Grading Matters

Grading subjective exam questions has long depended on manual effort. Even online grading platforms typically solve only paper distribution and score registration. The actual scoring still requires teachers to read each response, compare it against the rubric, and assign a score. This process is not only time-consuming but also prone to scoring drift caused by fatigue. The same answer may receive inconsistent scores at different times or under different conditions.

As large language models improve rapidly in semantic understanding, logical reasoning, and visual perception, a natural conclusion follows: if a model can understand the question, recognize what the student wrote, and match the response point by point against a given rubric, then automated scoring of subjective questions is theoretically feasible. The key challenge is integrating this capability into existing teaching workflows in a secure, stable, and convenient way, rather than forcing teachers to adapt to a completely new system disconnected from their daily habits.

2. System Design Goals and Overall Architecture

Based on the requirements above, we designed and implemented a desktop grading tool for Windows. Its core purpose is to take over the operational workflow of mainstream web-based grading platforms, perform answer sheet recognition, paper parsing, and AI-assisted scoring locally, and then write the final scores back to the original platform.

The system uses a no-backend architecture. All runtime logic executes locally on the user’s machine. The main modules are:

• Frontend UI layer: Handles user interaction, including paper upload, rubric configuration, grading progress display, and result confirmation.
• Local parsing engine: Includes PDF document parsing, Optical Mark Recognition (OMR) for answer sheets, and math formula rendering.
• AI scoring service layer: Calls large language models through a configurable API endpoint to perform semantic understanding and scoring inference.
• Local storage module: Uses the browser’s embedded local storage mechanism to persist configurations, templates, and grading records.

The primary advantage of this architecture is clear data sovereignty. By default, student paper content never leaves the local device. Only when a specific AI scoring request is executed are the necessary text fragments sent to the model service endpoint chosen by the user. For education scenarios where privacy is highly sensitive, this is a non-negotiable baseline requirement.

3. Key Technical Implementation Details

3.1 Answer Sheet Recognition: An OpenCV-Based OMR Approach

Optical Mark Recognition is the foundation for automatically scoring objective questions. We use a computer vision library that runs in the browser as WebAssembly. It is approximately 10 MB in size, works fully offline, and requires no external services.

The recognition pipeline is as follows:

1. Image preprocessing: Convert scanned or photographed images to grayscale, then apply adaptive thresholding to remove shadows and noise.
2. Registration mark detection: Use the corner anchor squares on the answer sheet to compute a perspective transformation matrix, correcting skew and distortion.
3. Option region segmentation: Locate the filled-region area for each question based on coordinates defined in the template configuration.
4. Fill detection: Calculate the pixel coverage ratio of each region. If it exceeds a preset threshold, the option is marked as selected.

It is worth noting that OMR accuracy depends heavily on template configuration. We allow users to manually annotate question regions through a graphical interface and save the configuration as a JSON template file, enabling quick adaptation to different answer sheet layouts.

3.2 Document Parsing: Dual-Channel Support for PDF and Markdown

Exam papers and answer sheets are usually distributed as PDF files. We use a pure front-end PDF parsing library for local parsing, extracting text content and vector path information. For papers containing many math formulas, directly extracted text is often severely distorted.

The solution is a dual-channel strategy:

• For scanned pages or formula-dense regions, render at high resolution into images and send them to a vision model for understanding.
• For text-based PDFs, extract text directly and render formulas using KaTeX with the mhchem plugin. This approach is fully offline and produces high-quality typesetting for chemical equations and mathematical symbols.

Markdown serves as an alternative input format, primarily for teachers creating custom rubric templates. Teachers can write rubrics directly in Markdown, and the system automatically parses and stores them in a structured format.

3.3 Abstracting the AI Scoring Engine

To avoid locking into any single model provider, the scoring engine is designed as a highly abstract interface layer. The core idea is that all model differences are shielded through a protocol conversion layer. Users only need to fill in three parameters in the settings: API endpoint, authentication key, and model name. This is sufficient to switch between different LLM services.

// Example of a standardized scoring request structure
async function scoreAnswer(question, answer, rubric, modelConfig) {
  const messages = [
    { role: 'system', content: SYSTEM_PROMPT },
    { role: 'user', content: buildUserPrompt(question, answer, rubric) }
  ];
  const response = await fetch(modelConfig.endpoint, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${modelConfig.apiKey}`
    },
    body: JSON.stringify({
      model: modelConfig.modelName,
      messages: messages,
      temperature: 0.2, // Low temperature ensures scoring stability
      response_format: { type: 'json_object' }
    })
  });
  return parseScoreResponse(await response.json());
}

This design delivers two key benefits. First, teachers can choose the model best suited to a given question type. Second, as model capabilities improve over time, users benefit from new model performance without upgrading the software itself. The interface also displays real-time token consumption, helping teachers evaluate usage costs.

3.4 Prompt Engineering for Scoring

The core difficulty in automated grading is not calling the model, but constructing effective scoring prompts. After multiple iterations, we settled on a standardized prompt template structure:

1. Role definition: Establish the model’s identity as a strict grader who follows the scoring rubric.
2. Rubric input: Provide the point value, award conditions, and deduction conditions for each scoring point as a structured list.
3. Reference answer: Supply the standard answer as a baseline for comparison.
4. Student response: Include the actual student answer to be scored.
5. Output constraints: Require the model to output only a JSON object containing the final score and an explanation of which scoring points were hit, so the program can parse it automatically.

By forcing the model to output structured data, we can validate the completeness of the scoring at the program level and avoid cases where the model returns irrelevant content. The temperature parameter is set to 0.2 to reduce the impact of randomness on scoring consistency.

4. Privacy Protection and Data Flow Design

The no-backend architecture provides clear privacy advantages. The system’s data flow follows the principle of minimum necessary disclosure:

• Local retention: All grading records, rubric templates, and model configuration keys are stored in the browser’s local storage on the user’s machine. After the application exits, data remains on the user’s computer.
• On-demand transmission: Only when AI scoring is executed does the system concatenate the question text, student answer text, and rubric, then send them to the user-configured API endpoint. Image content is uploaded only when visual understanding is required.
• No intermediary servers: The entire workflow contains no relay or proxy servers. The connection between the user and the model service provider is direct.

For teachers concerned about data leakage, we also provide a redaction mode. Before sending data to the model, the system automatically identifies and replaces personal information such as student names and IDs with placeholders, further reducing privacy risk.

5. Automatic Updates and Distribution

Distribution and updates are important practical considerations for desktop applications. We use a silent update mechanism based on GitHub Releases. When the application starts, it checks the update source. If a new version is found, it downloads in the background and prompts the user to restart and install when they are idle. The entire process does not interrupt ongoing work.

The key advantages of this strategy are:

• Seamless upgrades: Teachers do not need to manually download installation packages, reducing operational overhead.
• Fast rollback: If a new version has serious issues, it can be removed from the update source, keeping users on the stable version.
• Bandwidth-friendly: The incremental update mechanism downloads only changed components rather than the entire installer.

6. Practical Results and Future Improvements

Testing in real teaching scenarios shows that the system achieves high scoring consistency for subjective questions with clear structure and explicit rubrics, such as step-based scoring in science calculation problems and point-based scoring in humanities short answers. Compared with manual grading, per-paper processing time dropped from an average of 8 minutes to roughly 1 minute.

Of course, human intervention is still necessary in some cases. When a student’s response contains unconventional creative expression, graphical reasoning, or illegible handwriting, AI scoring may produce deviations. Therefore, the system is designed as assisted grading rather than fully automated grading. AI-generated scores are displayed only as suggestions. Teachers can accept or modify them with one click, and every modification record is retained to provide material for future model tuning.

Future improvements include:

• Training subject-specific fine-tuned scoring models for disciplines like mathematics and chemistry to reduce errors in understanding specialized terminology.
• Introducing a multi-model cross-validation mechanism that automatically flags an answer for manual review when multiple models produce significantly different scores.
• Supporting rubric version management so teachers can track scoring scale changes across semesters and classes.

7. Conclusion

This article demonstrates a practical path for building automation tools in education using existing mature technologies. The key takeaway is that unlocking the capabilities of large language models does not require complex infrastructure. Through a well-architected client, carefully designed prompt engineering, and strict privacy protection, an individual developer can build AI applications that were once considered feasible only for large companies. This lightweight, local-first, customizable model may represent an important direction for the future of educational technology.