Pith. sign in

REVIEW 4 major objections 4 minor 21 references

MLAR: Multi-layer Large Language Model-based Robotic Process Automation Applicant Tracking

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that MLAR, a three-layer LLM-based RPA pipeline, screens 2,400 resumes in 12,414 seconds (5.25 seconds per resume), about 23% faster than UiPath and Automation Anywhere, while reporting 63.45% matching accuracy.

desk verdict The speed headline is an artifact of comparing direct Python against the same Python wrapped in UiPath/AA; the architecture itself is a straightforward, honestly-cited LLM pipeline. read the letter →

arxiv 2507.10472 v1 pith:BPU2MLOO submitted 2025-07-14 cs.CL

Mohamed T. Younes , Omar Walid , Mai Hassan , Ali Hamdi This is my paper
classification cs.CL
keywords ApplicantTrackingSystemRoboticProcessAutomationLargeLanguageModelsresumeparsingsemanticmatchingrecruitmentGeminicandidateranking
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

MLAR is a custom applicant-tracking pipeline that combines robotic process automation with a large language model in three layers: job-description feature extraction, resume parsing, and similarity-based ranking. The paper reports that on a public dataset of 2,400 resumes spanning 24 professions, MLAR completed the whole workflow—posting, parsing, matching, and notification—in 12,414 seconds, or 5.25 seconds per resume, while UiPath took 15,258 seconds and Automation Anywhere 15,350 seconds. The paper attributes the roughly 23 percent speed advantage to MLAR running the same Python scripts directly instead of paying the orchestration overhead of the commercial RPA platforms. It also reports 63.45 percent accuracy and 74.24 percent precision and frames these as the starting point for fine-tuned LLMs. This matters because fast, semantic screening of this kind could replace keyword filters and manual shortlisting in high-volume hiring.

What carries the argument

The load-bearing mechanism is the three-layer LLM pipeline executing directly in Python. Layer one uses the Gemini LLM to turn a job description into a structured feature set $F_J(j)$; layer two turns each resume into a feature set $F_R(r)$ stored in a parsed-resume database grouped by predicted department; layer three computes a 0–100 similarity score $S(j,r)=L(F_J(j),F_R(r))$, ranks resumes in descending order, and triggers personalized emails for the top three. The speed argument rests on the claim that commercial RPA platforms add an orchestration layer—environment initialization, dependency management, inter-process communication, cloud-based script execution—that MLAR does not incur because it runs the Python scripts directly.

What would settle it

Rerun the three systems on one machine with the same 2,400 resumes and the same scripts over multiple trials, fixing CPU and network conditions. If UiPath or Automation Anywhere ever matches MLAR's total time within run-to-run noise, the claimed 22.8–23.6 percent speed advantage is not established; the paper reports a single run with no error bars.

Watch

Extended reading notes

Core claim

The paper's central claim is that the bottleneck in RPA-based resume screening is not the underlying parsing or matching logic but the orchestration layer that platforms wrap around it. MLAR keeps the same Python scripts and the same Gemini-based extraction and scoring, yet bypasses UiPath's environment initialization, dependency management, and inter-process communication, and avoids Automation Anywhere's cloud-based script execution latency. It extracts fields such as contact information, skills, work experience, education, and predicted department from each resume, scores the match between a resume $r$ and a job description $j$ as $S(j,r)=L(F_J(j),F_R(r))$, ranks all resumes, and selects the top three for automated notification. In a single reported run on 2,400 resumes, this design took 12,414 seconds total versus 15,258 seconds for UiPath and 15,350 seconds for Automation Anywhere, with accuracy and precision reported as 63.45 percent and 74.24 percent.

Load-bearing premise

The speed advantage rests on the assumption that UiPath and Automation Anywhere were configured fairly and equivalently to MLAR—same scripts, same hardware, same network conditions—so the entire measured gap is orchestration overhead; the accuracy and precision figures, reported in the Future Work section without methodology, are not load-bearing for that speed claim.

Editorial extensions

If this is right

  • A batch of 2,400 resumes can be screened, ranked, and notified in about 3.5 hours without manual review or keyword filtering.
  • On the reported workload, MLAR saves roughly 47–49 minutes compared with each commercial platform, and the gap grows with batch size.
  • Because the claimed gain comes from removing orchestration overhead, the design suggests that high-volume LLM text pipelines should execute scripts directly rather than wrapping them in RPA workflow engines.
  • The reported accuracy and precision, though modest, indicate the system can already rank candidates and is explicitly staged for improvement by fine-tuning LLMs on recruitment data.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper does not compare MLAR against a plain Python script without any RPA layer; if the speed gap is entirely orchestration overhead, such a control should achieve nearly the same total time, and its absence leaves the explanation untested.
  • The accuracy and precision values are stated without evaluation methodology, so an independent test against human recruiter judgments on a labeled resume subset would be needed before treating the matching quality as established.
  • Because only the top three resumes per job are selected and notified, small calibration errors in the similarity score can change who gets shortlisted; with reported accuracy near 63 percent, selection quality is likely the practical bottleneck even if the speed claim holds.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper proposes MLAR, a three-layer LLM-based RPA applicant tracking system built on the Gemini API, which extracts features from job descriptions and resumes and computes semantic similarity scores to rank and notify top candidates. The authors claim that, on a benchmark of 2,400 resumes from a public Kaggle dataset, MLAR processes resumes in an average of 5.4 seconds per resume (abstract) or 5.25 seconds (Table I), outperforming UiPath and Automation Anywhere by roughly 17% to 24% depending on which reported numbers are used. The manuscript describes the system architecture, the workflow design, and a performance comparison table, and it reports an accuracy and precision figure in the Future Work section.

Significance. If the performance advantage were established by a fair and reproducible benchmark, the paper would offer a modest but useful integration insight: that a direct-Python LLM pipeline avoids the orchestration overhead of general-purpose RPA platforms. However, the experimental design makes the speed ordering an expected artifact of comparing direct Python execution against Python scripts wrapped inside UiPath and Automation Anywhere, rather than a discovery about RPA platform capabilities. The accuracy component of the central claim is unsupported by any described methodology. The paper does provide a clear architectural diagram and makes use of a public dataset, and the authors are explicit about the components of their pipeline, but the empirical contribution as presented is not reliable enough to support the stated claims.

major comments (4)
  1. [Abstract vs. Section V, Table I] The headline numbers are inconsistent: the abstract reports an average of 5.4 seconds per resume and reductions of approximately 16.9% (Automation Anywhere) and 17.1% (UiPath), whereas Table I reports 5.25 seconds per resume and reductions of 23.6% (Automation Anywhere) and 22.8% (UiPath), and the conclusion repeats the Table I values. The authors must correct this discrepancy and state which result is intended; this inconsistency undermines confidence in the quantitative claims.
  2. [Section V, Table I] The benchmark design does not provide a fair test of the stated claim that MLAR outperforms leading RPA platforms. The text states that "the same Python scripts were used for all three systems" and then attributes the time difference to orchestration overhead, because MLAR runs scripts directly in Python while UiPath and Automation Anywhere add environment initialization, dependency management, and inter-process communication. This measures wrapper overhead, not the native capability of UiPath or Automation Anywhere to perform resume parsing, matching, and notification workflows, since no native UiPath or Automation Anywhere implementation of these tasks is described. No configuration details, hardware specifications, network conditions, repeated runs, or error bars are provided. The measured ordering is therefore expected from the design and cannot support the abstract's claim that MLAR outperforms leading RPA platforms.
  3. [Section V-A, Future Work] The only accuracy evidence in the paper is the sentence "The MLAR system achieved an accuracy of 63.45% and a precision of 74.24% in matching candidates with job requirements," which appears in a Future Work subsection. No methodology is given for how accuracy and precision were computed, no ground-truth labels or evaluation dataset are described, and no baseline comparison is provided. Since the abstract describes MLAR as an "efficient, accurate, and scalable solution," this unsupported accuracy figure is load-bearing for the paper's overall claim and must be substantiated or removed.
  4. [Sections IV and V] The experiments are not reproducible from the manuscript: no code is released, no Gemini API version or configuration is given, no details about the computing environment (CPU, memory, network) are provided, and the protocol for pairing the 24 job descriptions with the 2,400 resumes is not described. These omissions make it impossible for a reader to verify the central performance results or to compare them with future work; the authors should either release the code and detailed setup or substantially expand the experimental description.
minor comments (4)
  1. [Section I] Several typographical errors interrupt readability, including "introducesMLAR" (should be "introduces MLAR"), "handle2,400" (should be "handle 2,400"), "within3.5hours" (should be "within 3.5 hours"), and "averaging5.4seconds" (should be "averaging 5.4 seconds").
  2. [Section IV, Figures 1 and 2] Figure 2 is referenced in the opening sentence of Section IV ("The flow diagram in Figure 2") before Figure 1, and the textual description of the system architecture is separated from the figure to which it refers; please reorder or renumber the figures for clarity.
  3. [Section III-C] The Kaggle Resume Dataset is cited as reference [16], but the manuscript does not specify the dataset version, license, or any preprocessing steps applied (e.g., how PDFs were converted or cleaned before being fed to Gemini); please add this information for reproducibility.
  4. [Section V, Table I] The table header uses inconsistent decimal places (6.45, 6.50, 5.25) and the column "Time Per Resume (seconds)" would benefit from an explicit statement of whether these are mean times over a single run or averaged over multiple runs; currently no repetition is mentioned.

Circularity Check

1 steps flagged · score 6.0 of 10

The headline speed win is prescribed by the experimental design: the same Python scripts run directly in MLAR and wrapped in UiPath/Automation Anywhere, so the reported speedup is the orchestration overhead removed by definition rather than a measured system property.

  1. self definitional [Section V (Results and Discussion), discussion following Table I; Eq. (6)]
    "Although the same Python scripts were used for all three systems, differences in execution speed can be attributed to how each platform manages external scripts and orchestrates processes... MLAR bypasses these orchestration layers by running scripts directly in Python, resulting in faster initialization and execution."

    The headline claim that MLAR is 16.9-23.6% faster than UiPath and Automation Anywhere (abstract; Table I) is entailed by the construction described in Section V: 'the same Python scripts were used for all three systems,' and MLAR's advantage is attributed to bypassing orchestration by 'running scripts directly in Python.' Consequently, Eq. (6), Delta-T = T_Benchmark - T_MLAR, equals exactly the wrapper overhead that the setup removed by definition. The performance ordering is known before any run, because direct execution without an orchestrator cannot be slower than the same scripts wrapped in an orchestrator. The paper's central empirical result is therefore a property of the benchmark design, not a measured emergent capability of the MLAR architecture.

full rationale

The paper's central quantitative claim, that MLAR outperforms UiPath and Automation Anywhere in high-volume resume processing, reduces by construction. Section V states that 'the same Python scripts were used for all three systems' and attributes the difference to orchestration overhead, since MLAR 'bypasses these orchestration layers by running scripts directly in Python.' Under this setup, the delta computed in Eq. (6) is simply the wrapper overhead of the RPA platforms, so the speed ordering is predetermined by the experimental definition and tests no emergent property of the MLAR architecture. No self-citation is involved: none of the twenty-one references are authored by the present authors, and no uniqueness theorem is invoked. The accuracy figures (63.45% accuracy, 74.24% precision, stated only in Future Work with no methodology, ground-truth definition, or baseline) are unsupported, which is a correctness risk rather than circularity. The abstract-versus-Table I numeric inconsistency (5.4 s/resume and ~17% versus 5.25 s/resume and 22.8%/23.6%) is a reporting inconsistency, not circularity. Because the headline speed result is forced by the comparison construction, the score is 6: one prediction reduces by construction, while the remainder of the paper retains independent content.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The system's behavior depends on the Gemini LLM reliably extracting features and computing similarity scores, an assumption validated only by the unsupported accuracy numbers in Future Work. It also assumes the Kaggle dataset and the 24 locally stored job descriptions are representative of real hiring workloads. No free parameters are fitted in the presented equations beyond the hand-chosen top-3 selection threshold.

free parameters (1)
  • Top-k selection threshold = 3
    The system notifies only the top 3 candidates (Eq. 4). This is a hand-chosen design constant, not fitted to data, and it does not materially affect the speed benchmark, but it is a free choice in the pipeline.
assumptions (3)
  • domain assumption Gemini LLM accurately extracts structured features from resumes and job descriptions and computes meaningful similarity scores.
    Section III-B and IV treat the LLM's output as ground truth; the only evaluation is the unsupported accuracy claim in Section V-A.
  • domain assumption The Kaggle Resume Dataset and the 24 locally stored job descriptions are representative of real recruitment workloads.
    Section III-C selects this dataset; no diversity or bias analysis is provided.
  • domain assumption UiPath and Automation Anywhere were configured equivalently to MLAR, so timing differences isolate orchestration overhead.
    Section V asserts the same Python scripts were used, but does not report configurations, hardware, or network conditions.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MLAR: Multi-layer Large Language Model-based Robotic Process Automation Applicant Tracking." pith.science (2026). https://pith.science/paper/BPU2MLOO

@misc{pith2026250710472,
  author       = {Pith},
  title        = {Pith review of: MLAR: Multi-layer Large Language Model-based Robotic Process Automation Applicant Tracking},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BPU2MLOO}},
  note         = {Machine review of arXiv:2507.10472}
}
read the original abstract

This paper introduces an innovative Applicant Tracking System (ATS) enhanced by a novel Robotic process automation (RPA) framework or as further referred to as MLAR. Traditional recruitment processes often encounter bottlenecks in resume screening and candidate shortlisting due to time and resource constraints. MLAR addresses these challenges employing Large Language Models (LLMs) in three distinct layers: extracting key characteristics from job postings in the first layer, parsing applicant resume to identify education, experience, skills in the second layer, and similarity matching in the third layer. These features are then matched through advanced semantic algorithms to identify the best candidates efficiently. Our approach integrates seamlessly into existing RPA pipelines, automating resume parsing, job matching, and candidate notifications. Extensive performance benchmarking shows that MLAR outperforms the leading RPA platforms, including UiPath and Automation Anywhere, in high-volume resume-processing tasks. When processing 2,400 resumes, MLAR achieved an average processing time of 5.4 seconds per resume, reducing processing time by approximately 16.9% compared to Automation Anywhere and 17.1% compared to UiPath. These results highlight the potential of MLAR to transform recruitment workflows by providing an efficient, accurate, and scalable solution tailored to modern hiring needs.

Figures

Figures reproduced from arXiv: 2507.10472 by the authors.

Figure 1
Figure 1. System architecture of the MLAR model. The diagram demonstrates the integration of Large Language Models (LLMs) [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. The MLAR flow diagram ground and predicted department classification. The parsed resumes are stored in a structured manner within the Parsed resumes Database (shown as part (e) in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

21 extracted references · 16 canonical work pages

  1. [1]

    The impact of business process management and applicant tracking systems on recruiting process per- formance: an empirical study,

    S. Laumer, C. Maier, and A. Eckhardt, “The impact of business process management and applicant tracking systems on recruiting process per- formance: an empirical study,”Journal of Business Economics, vol. 85, pp. 421–453, 2015

    work page 2015

  2. [2]

    A structured approach to implementing robotic process automation in hr,

    S. Balasundaram and S. Venkatagiri, “A structured approach to implementing robotic process automation in hr,”Journal of Physics: Conference Series, vol. 1427, no. 1, p. 012008, jan 2020. [Online]. Available: https://dx.doi.org/10.1088/1742-6596/1427/1/012008

    work page doi:10.1088/1742-6596/1427/1/012008 2020

  3. [3]

    Robotic process automation for recruitment process,

    N. Nawaz, “Robotic process automation for recruitment process,”Inter- national Journal of Advanced Research in Engineering and Technology (IJARET), vol. 10, no. 2, pp. 608–611, March-April 2019

    2019

  4. [4]

    A survey on hr process automation: Trends, technologies, and future directions,

    S. Wang, P. Patel, A. Dubey, and A. Jakubik, “A survey on hr process automation: Trends, technologies, and future directions,”IEEE Trans- actions on Automation Science and Engineering, vol. 20, no. 2, pp. 689–701, 2023

    2023

  5. [5]

    Robotic process automation for resume processing system,

    N. Roopesh and C. N. Babu, “Robotic process automation for resume processing system,” in2021 International Conference on Recent Trends on Electronics, Information, Communication and Technology (RTEICT), 2021, pp. 180–184

    work page 2021

  6. [6]

    A deep learning bert- based approach to person-job fit in talent recruitment,

    E. Abdollahnejad, M. Kalman, and B. H. Far, “A deep learning bert- based approach to person-job fit in talent recruitment,” in2021 In- ternational Conference on Computational Science and Computational Intelligence (CSCI), 2021, pp. 98–104

    2021

  7. [7]

    Prospectcv: Llm-based advanced cv-jd evaluation platform,

    G. Vagale, S. Y . Bhat, P. P. P. Dharishini, and P. GK, “Prospectcv: Llm-based advanced cv-jd evaluation platform,” in2024 IEEE Students Conference on Engineering and Systems (SCES), 2024, pp. 1–6

    work page 2024

  8. [8]

    Integration of artificial intelligence and robotic process automation: Literature review and proposal for a sustainable model,

    L. Patr ´ıcio, L. Varela, and Z. Silveira, “Integration of artificial intelligence and robotic process automation: Literature review and proposal for a sustainable model,”Applied Sciences, vol. 14, no. 21, 2024. [Online]. Available: https://www.mdpi.com/2076- 3417/14/21/9648

    work page 2024

Show all 21 references
  1. [9]

    Combining robotic process automation with artificial intelligence: Applications, terminology, benefits, and chal- lenges,

    L. Schaudt and D. Schlegel, “Combining robotic process automation with artificial intelligence: Applications, terminology, benefits, and chal- lenges,” inEurasian Business and Economics Perspectives, M. Bilgin, H. Danis, E. Demir, L. Wincenciak, and S. T. Er, Eds. Cham: Spring...

    2023

  2. [10]

    Automated applicant ranking using hybrid nlp and machine learning techniques,

    P. Mishra, R. Kumar, and Y . Chen, “Automated applicant ranking using hybrid nlp and machine learning techniques,” in2021 IEEE 15th International Conference on Semantic Computing (ICSC), 2021, pp. 145–152

    2021

  3. [11]

    Bajzikova and T

    L. Bajzikova and T. Smerdova,Improving the Recruitment Process in Multinational Organizations Using Robotic Process Automation and Artificial Intelligence. Cham: Springer Nature Switzerland, 2024, pp. 29–60

    2024

  4. [12]

    Facilitating multi-role and multi-behavior collaboration of large language models for online job seeking and recruiting,

    H. Sun, H. Lin, H. Yan, C. Zhu, Y . Song, X. Gao, S. Shang, and R. Yan, “Facilitating multi-role and multi-behavior collaboration of large language models for online job seeking and recruiting,” 2024. [Online]. Available: https://arxiv.org/abs/2405.18113

    2024 arXiv

  5. [13]

    Explainable rpa in hr: Integrating xai methods to enhance transparency in automated talent acquisition,

    Y . Lin, J. Bose, and R. Narkhede, “Explainable rpa in hr: Integrating xai methods to enhance transparency in automated talent acquisition,” Expert Systems with Applications, vol. 216, p. 119451, 2023

    2023

  6. [14]

    Ats 2.0: Leveraging large language models for bias mitigation in automated hiring,

    J. Zhang, C. Martin, and D. Ray, “Ats 2.0: Leveraging large language models for bias mitigation in automated hiring,” in2024 IEEE Inter- national Conference on Computational Intelligence in Data Science (CIDS), 2024, pp. 233–240

    2024

  7. [15]

    Robotic process automation: Contemporary themes and challenges,

    R. Syed, S. Suriadi, M. Adams, W. Bandara, S. J. Leemans, C. Ouyang, A. H. ter Hofstede, I. van de Weerd, M. T. Wynn, and H. A. Reijers, “Robotic process automation: Contemporary themes and challenges,” Computers in Industry, vol. 115, p. 103162, 2020. [Online]. Available: htt...

    2020

  8. [16]

    Resume dataset,

    S. Anbhawal, “Resume dataset,” 2021, ac- cessed: November 30, 2024. [Online]. Available: https://www.kaggle.com/datasets/snehaanbhawal/resume-dataset

    2021

  9. [17]

    Application of llm agents in recruitment: A novel framework for resume screening,

    C. Gan, Q. Zhang, and T. Mori, “Application of llm agents in recruitment: A novel framework for resume screening,” 2024. [Online]. Available: https://arxiv.org/abs/2401.08315

    2024 arXiv

  10. [18]

    Semantic matching of resumes and job descriptions using large-scale generative pre-trained transformers,

    C. Almada and O. Jerez, “Semantic matching of resumes and job descriptions using large-scale generative pre-trained transformers,”IEEE Access, vol. 11, pp. 114 567–114 581, 2023

    2023

  11. [19]

    Uipath - automation platform for rpa,

    UiPath, “Uipath - automation platform for rpa,” 2024, accessed: 2024-11-30. [Online]. Available: https://www.uipath.com/

    2024

  12. [20]

    Automation anywhere - rpa software used for ats,

    A. Anywhere, “Automation anywhere - rpa software used for ats,” 2024, accessed: 2024-11-30. [Online]. Available: https://www.automationanywhere.com/

    2024

  13. [21]

    Identifying candidate tasks for robotic process automation in textual process descriptions,

    H. Leopold, H. van der Aa, and H. A. Reijers, “Identifying candidate tasks for robotic process automation in textual process descriptions,” inEnterprise, Business-Process and Information Systems Modeling, J. Gulden, I. Reinhartz-Berger, R. Schmidt, S. Guerreiro, W. Gu ´edria, ...

    2018

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.