Pith. sign in

REVIEW 3 major objections 5 minor 38 references

Secret Breach Detection in Source Code with Large Language Models

T0 review · 3 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read Fine-tuned small LLMs detect hardcoded secrets at 0.985 F1, outperforming regex-only scanning.

desk verdict Fine-tuned open LLMs on SecretBench is a solid empirical exercise, but the headline F1 is inflated by candidate-level train/test leakage. read the letter →

arxiv 2504.18784 v2 pith:6QZSYGDF submitted 2025-04-26 cs.SE

Md Nafiu Rahman , Sadif Ahmed , Zahin Wahab , S M Sohan , Rifat Shahriyar This is my paper · ORCID
classification cs.SE
keywords secretdetectionlargelanguagemodelssourcecodesecurityfine-tuningregexfalsepositivesmulticlassclassificationlocaldeployment
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

This paper claims that a hybrid pipeline—regex-based candidate extraction followed by large-language-model classification—can find hardcoded secrets in source code with far fewer false alarms than regex or entropy tools alone. On a balanced test set drawn from 818 public code repositories, fine-tuning an 8-billion-parameter open model for binary secret detection reaches an F1-score of 0.9852, and a 7-billion-parameter model reaches a weighted F1 of 0.982 for classifying secret types. The paper also argues that these small open models are accurate enough to replace commercial API calls, running in under 13 GB of inference memory on local hardware. If true, secret scanning could be embedded in development workflows without shipping code to third parties.

What carries the argument

The load-bearing mechanism is the context window: each regex-extracted candidate is paired with 200 characters of surrounding source code, and the pair is rendered into a structured prompt asking for 'Secret' or 'Non-sensitive', or for the secret type. This context lets the model treat a string like 'sk_test_...' as sensitive when it appears in a live API call but ignore 'xxxxxxxxxx' as a placeholder. Fine-tuning is done with quantized low-rank adapters (QLoRA-style parameter-efficient tuning) on the small open models, training attention layers on the balanced candidate set; that is what lifts raw zero-shot F1 scores from roughly 0.3–0.5 to above 0.94 across all five models tested. The comparison point is a regex-only tool, which would call every extracted candidate a secret and therefore score at most 50% precision on the balanced test set.

What would settle it

Split the dataset by repository instead of by individual candidate: train on a random 80% of repositories and test on the remaining 20%. If the fine-tuned model's F1 drops materially below 0.9852 on repositories it never saw, the claim of generalization to unseen codebases is not supported; an even cleaner check is to run the same model on freshly generated secrets that postdate the benchmark.

Watch

Extended reading notes

Core claim

The central discovery is that contextual language understanding, not better pattern matching, is what removes false positives in secret detection. A regex pass first proposes candidate strings; then a model reads a 200-character window of surrounding code and decides whether the candidate is a real secret. After parameter-efficient fine-tuning, the best small model correctly labels 1,496 of 1,500 non-secrets and 1,463 of 1,500 secrets, yielding the reported F1 of 0.9852, while raw prompted models stay well below that. For multiclass labeling, a fine-tuned 7-billion-parameter model reaches a weighted F1 of 0.982, with near-perfect scores on private keys, API keys, and authentication tokens, and weaker but strong scores on rare categories. The authors interpret this as evidence that fine-tuned open models are a practical middle path: more accurate than regex, cheaper and more private than commercial APIs.

Load-bearing premise

The reported near-perfect scores assume the test candidates have not been effectively seen during training: the train/test split is random at the candidate level, so strings from the same repository or file can appear on both sides, and the benchmark itself is drawn from public code that the models may have seen during pretraining.

Editorial extensions

If this is right

  • Secret scanning can run on a local workstation: training stayed under 17 GB of GPU memory and inference under 13 GB, so CI/CD pipelines and IDEs could scan without sending code to commercial APIs.
  • Multiclass labels give security teams the secret type (private key, API key, token, password), so a leak can be routed directly to the right revocation action.
  • Because fine-tuning improves every tested model and context windows of 200 characters already suffice, the approach is practical on modest hardware rather than requiring frontier models.
  • A balanced training set and a skewed, realistic training set produced nearly the same scores, suggesting the method survives the imbalanced conditions of real codebases.

Reading between the lines

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

  • Editorial inference: A repository-level train/test split would be the natural stress test; if performance drops sharply when no file from the test repository appears in training, the reported F1 is partly a memorization effect rather than generalization to unseen codebases.
  • Editorial inference: The same hybrid could be extended beyond code to configuration files, CI logs, and issue trackers, since the model only needs a candidate string plus local context.
  • Editorial inference: If deployed, a model that rejects low-confidence candidates could cut the paper's 37 false negatives at some false-positive cost, trading alert noise against missed secrets in either direction.
  • Editorial inference: The near-perfect multiclass scores on rare categories suggest the benchmark's label boundaries, not the model, may be the main source of residual errors; a cleaned relabeling study would show how much headroom remains.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes a hybrid secret-detection pipeline that first extracts candidate strings with regular expressions and then classifies them with large language models (LLMs). Using the SecretBench dataset (97,479 candidates from 818 GitHub repositories), the authors curate a balanced subset, evaluate pretrained GPT-4o and DeepSeek-V3 under zero-, one-, and few-shot prompting, and fine-tune LLaMA-3.1-8B, Mistral-7B, CodeLLaMA-7B, Gemma-7B, and DeepSeek-7B with QLoRA. They report that fine-tuned LLaMA-3.1-8B reaches an F1-score of 0.9852 in binary classification and that Mistral-7B reaches a weighted F1-score of 0.9820 in multiclass classification, arguing that small open models are accurate enough for local deployment.

Significance. If the reported results generalize beyond the specific benchmark split, the work would be a practically useful demonstration that small, locally deployable LLMs can filter regex-extracted secret candidates with high precision. The paper has several strengths: it provides a replication package, describes hyperparameters and resource usage in detail, evaluates multiple models and prompting strategies, and reports both binary and multiclass results with F1 and F2 metrics. The main caveat is that the headline numbers rest on a candidate-level random split, which does not yet establish performance on unseen codebases.

major comments (3)
  1. [Section III-C3, Tables V and VI] The random candidate-level split does not provide a valid estimate of generalization to unseen code. SecretBench contains 97,479 candidates from only 818 repositories, and the paper forms 24,000 training, 3,000 validation, and 3,000 test samples by randomly partitioning the curated 45,000-item pool without grouping by repository or file. Since each input includes a 200-character context window around the candidate, test candidates sharing a file or repository with training candidates are near-duplicates, and the model can memorize file-level or repository-level cues rather than learning transferable signals. The Section VI internal-validity discussion addresses LLM pretraining contamination but does not mention this split leakage. Please re-run the evaluation with a repository-level or file-level split and report the resulting cross-repo F1; if a full re-run is infeasible, at minimum quantify how many test candidates share a file or repository with training candidates and report metrics on the non-overlapping subset.
  2. [Section V-B and abstract] The claim of outperforming regex-only baselines is supported only by a theoretical 'flag all candidates' model, which by construction has 50% precision on the balanced 3,000-sample test set and was not actually run. Real tools such as Gitleaks and TruffleHog apply their own candidate-filtering rules and would not necessarily flag every candidate, so the stated comparison is not an empirical tool benchmark. Please run Gitleaks, TruffleHog, or the SecretBench regex set on the same test candidates and report their precision, recall, and F1, or alternatively qualify the claim as an improvement over an all-candidates baseline.
  3. [Section III-A2] The data curation description leaves the exact relationship among subsets unclear. The paper lists a balanced train set, an imbalanced train set, a validation set, and a test set drawn from the same 45,000-candidate pool, and later states that the test set is the same as the one used in Section III-B. The reader cannot determine whether the imbalanced and balanced training sets overlap with each other or with the validation/test sets, nor whether multiclass training and test samples are disjoint by repository or file. Please state the exact composition and overlap of all subsets used in each experiment.
minor comments (5)
  1. [Abstract] The abstract says 'Mistral-7B reached 0.982 accuracy,' but Table VI reports a weighted F1-score, not accuracy; please use the correct term for consistency.
  2. [Section III-B2] There is a garbled sentence: 'we evaluated GPT-4o [28] and Deepseek-V3 [29] on detecting secrets as and experimented' and an earlier phrase 'have shown remarkable performance have demonstrated'; these need copyediting.
  3. [Table I] The per-class counts in Table I sum to 15,075, not the 15,084 true secrets stated in Section III-A1; please reconcile the totals.
  4. [Table X] Table X should state explicitly whether inference time is per candidate, per file, or per batch, and on which hardware it was measured.
  5. [Section III-C4] The paper says multiclass models are evaluated on the same 3,000-sample test set used for the pretrained models, but Section III-A2 indicates that only positive samples are used for multiclass classification; please clarify whether this test set contains only positive samples or also includes negatives.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the reported F1 scores are empirical measurements on a held-out test set, not results derived from the paper's own definitions or self-citations.

full rationale

This is an empirical supervised-learning evaluation rather than a derivation, so the standard circularity failure modes do not apply. The paper's central claims (fine-tuned LLaMA-3.1-8B F1 of 0.9852 in binary classification and Mistral-7B weighted F1 of 0.982 in multiclass classification) are measurements obtained by training models on SecretBench labels and evaluating on a separate 3,000-sample balanced test set. The regex-based candidate extraction is an input pipeline inherited from the external SecretBench dataset, and the LLM classifiers are learned functions; the output metric is not defined in terms of the input candidates or the training labels by construction. The one self-citation (Wahab et al. [21]) appears only in related work and is not load-bearing for any claimed result. The only circularity-adjacent concern is that the random sample-level split in Section III-C3 may allow same-repository or same-file candidates to appear in both training and test sets, which is a potential validity threat to generalization claims but is not a circular-reasoning reduction of the reported F1 to its inputs. Accordingly, no specific circular step can be quoted, and the honest finding is no significant circularity.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claim rests on SecretBench labels, the completeness of its regex candidate set, the sufficiency of a 200-character context window, and a sample-level split assumption. These are reasonable starting points but should be tested with repository-level splits and external validation.

free parameters (6)
  • LoRA rank = 64
    Chosen for PEFT fine-tuning; not swept, affects model capacity and performance.
  • LoRA alpha = 16
    Scaling factor for LoRA; chosen, not tuned.
  • Learning rate = 2e-4
    Paged AdamW learning rate; chosen for QLoRA.
  • Training epochs = 7
    Fine-tuning duration; chosen without exhaustive search.
  • Context window size = 200 characters (300 variant)
    Context around each candidate; impact analyzed, but primary results use 200.
  • Balanced training composition = 12,000 secrets / 12,000 non-secrets (balanced); 3,750/20,250 (imbalanced)
    Training subset ratios chosen from SecretBench; affects precision and recall trade-off.
assumptions (5)
  • domain assumption SecretBench labels are correct ground truth for whether a candidate string is a secret.
    The evaluation and training use SecretBench's manual labels as ground truth; errors in labels propagate to reported F1. The paper notes inconsistencies with its own annotation framework in Section V-C.
  • domain assumption The 761 regex patterns in SecretBench capture all relevant secret candidates; detection is bounded by this candidate set.
    The hybrid approach cannot detect secrets not matched by the regexes, so reported recall only applies within the regex-extracted candidate pool.
  • domain assumption LLM pretraining contamination on GitHub code does not materially inflate the results.
    The paper acknowledges this risk in Section VI but assumes the models were not explicitly optimized for secret detection. This is plausible but unverified.
  • domain assumption A 200-character context window around the candidate is sufficient for classification.
    Used for all primary results; the paper tests 300 characters and finds small gains, so the 200-character choice is a modeling assumption.
  • ad hoc to paper Randomly splitting candidate samples yields train and test sets with no information leakage.
    Data splits in Section III-C3 are by sample, not by repository/file; this assumption is load-bearing for generalization claims.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Secret Breach Detection in Source Code with Large Language Models." pith.science (2026). https://pith.science/paper/6QZSYGDF

@misc{pith2026250418784,
  author       = {Pith},
  title        = {Pith review of: Secret Breach Detection in Source Code with Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6QZSYGDF}},
  note         = {Machine review of arXiv:2504.18784}
}
read the original abstract

Background: Leaking sensitive information - such as API keys, tokens, and credentials - in source code remains a persistent security threat. Traditional regex and entropy-based tools often generate high false positives due to limited contextual understanding. Aims: This work aims to enhance secret detection in source code using large language models (LLMs), reducing false positives while maintaining high recall. We also evaluate the feasibility of using fine-tuned, smaller models for local deployment. Method: We propose a hybrid approach combining regex-based candidate extraction with LLM-based classification. We evaluate pre-trained and fine-tuned variants of various Large Language Models on a benchmark dataset from 818 GitHub repositories. Various prompting strategies and efficient fine-tuning methods are employed for both binary and multiclass classification. Results: The fine-tuned LLaMA-3.1 8B model achieved an F1-score of 0.9852 in binary classification, outperforming regex-only baselines. For multiclass classification, Mistral-7B reached 0.982 accuracy. Fine-tuning significantly improved performance across all models. Conclusions: Fine-tuned LLMs offer an effective and scalable solution for secret detection, greatly reducing false positives. Open-source models provide a practical alternative to commercial APIs, enabling secure and cost-efficient deployment in development workflows.

Figures

Figures reproduced from arXiv: 2504.18784 by the authors.

Figure 1
Figure 1. Example of a secret breach in source code: An API [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Workflow for secret detection in source code. Potential [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Prompt for classifying a candidate string as ”Secret” or [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Confusion Matrix for Zero-Shot prompting on fine [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Confusion Matrix for Mistral-7B fine-tuned for multi [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 21 canonical work pages

  1. [1]

    What are secrets?

    GitGuardian, “What are secrets?” https://www.gitguardian.com/videos/ what-are-secrets, 2025, accessed: 2025-04-18

    work page 2025

  2. [2]

    Kreichman

    I. Kreichman. (2021) The secrets about exposed secrets in code. https:// apiiro.com/blog/the-secrets-about-secrets-in-code/. Accessed: 2024-02- 02

    work page 2021

  3. [3]

    (2024) State of secrets sprawl report 2023

    GitGuardian. (2024) State of secrets sprawl report 2023. [Online]. Avail- able: https://www.gitguardian.com/state-of-secrets-sprawl-report-2023

    work page 2024

  4. [4]

    C. Jones. (2023) Cryptojackers steal aws credentials from github in 5 minutes. https://www.theregister.com/2023/10/30/cryptojackers \ protect\penalty\z@ steal\protect\penalty\z@ aws\protect\penalty\ z@ credentials\protect\penalty\z@ github/. Accessed: 2024-02-02

    work page 2023

  5. [5]

    (2023) Sophos 2023 threat report

    Sophos. (2023) Sophos 2023 threat report. https://www.sophos.com/ en-us/content/security-threat-report. Accessed: 2024-03-21

    work page 2023

  6. [6]

    (2024) The state of secrets sprawl report 2024

    GitGuardian. (2024) The state of secrets sprawl report 2024. https: //www.gitguardian.com/state-of-secrets-sprawl-report-2024. Accessed: 2025-04-16

    work page 2024

  7. [7]

    Kandasamy

    R. Kandasamy. (2020) Secret detection tools for source codes. https: //github.com/rmkanda/tools. Accessed: 2024-02-02

    work page 2020

  8. [8]

    (2016) Trufflehog

    TruffleSecurity. (2016) Trufflehog. https://github.com/trufflesecurity/ trufflehog. Accessed: 2024-02-02

    work page 2016

Show all 38 references
  1. [9]

    (2014) gitrob

    Michenriksen. (2014) gitrob. [Online]. Available: https://github.com/ michenriksen/gitrob

    2014

  2. [10]

    (2017) ggshield

    GitGuardian. (2017) ggshield. https://www.gitguardian.com/ggshield. Accessed: 2024-02-02

    2017

  3. [11]

    (2018) Gitleaks

    Gitleaks. (2018) Gitleaks. https://github.com/gitleaks/gitleaks. Accessed: 2024-02-02

    2018

  4. [12]

    Security

    T. Security. (2016) Regular expressions used in trufflehog. https://github. com/trufflesecurity/trufflehog/tree/main/pkg/detectors. Accessed: 2024- 03-27

    2016

  5. [13]

    A mathematical theory of communication,

    C. E. Shannon, “A mathematical theory of communication,” The Bell system technical journal , vol. 27, no. 3, pp. 379–423, 1948

    1948

  6. [14]

    A comparative study of software secrets reporting by secret detection tools,

    S. K. Basak, J. Cox, B. Reaves, and L. Williams, “A comparative study of software secrets reporting by secret detection tools,” in 2023 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) . IEEE, 2023, pp. 1–12

    2023

  7. [15]

    How bad can it git? characterizing secret leakage in public github repositories

    M. Meli, M. R. McNiece, and B. Reaves, “How bad can it git? characterizing secret leakage in public github repositories.” in NDSS, 2019

    2019

  8. [16]

    Detecting and mitigating secret-key leaks in source code repositories,

    V . S. Sinha, D. Saha, P. Dhoolia, R. Padhye, and S. Mani, “Detecting and mitigating secret-key leaks in source code repositories,” in 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories . IEEE, 2015, pp. 396–400

    2015

  9. [17]

    Secrets in source code: Reducing false positives using machine learning,

    A. Saha, T. Denning, V . Srikumar, and S. K. Kasera, “Secrets in source code: Reducing false positives using machine learning,” in 2020 International Conference on COMmunication Systems & NETworkS (COMSNETS). IEEE, 2020, pp. 168–175

    2020

  10. [18]

    (2024) Getting started with the rest api

    GitHub. (2024) Getting started with the rest api. [On- line]. Available: https://docs.github.com/en/rest/using-the-rest-api/ getting-started-with-the-rest-api?apiVersion=2022-11-28

    2024

  11. [19]

    Automated detection of password leakage from public github repositories,

    R. Feng, Z. Yan, S. Peng, and Y . Zhang, “Automated detection of password leakage from public github repositories,” in Proceedings of the 44th International Conference on Software Engineering , 2022, pp. 175–186

    2022

  12. [20]

    (2012) git-crypt

    AGW A. (2012) git-crypt. https://github.com/AGW A/git-crypt. Accessed: 2024-03-26

    2012

  13. [21]

    Secret breach prevention in software issue reports,

    Z. Wahab, S. Ahmed, M. N. Rahman, R. Shahriyar, and G. Uddin, “Secret breach prevention in software issue reports,” 2024. [Online]. Available: https://arxiv.org/abs/2410.23657

    2024 arXiv

  14. [22]

    Bert: Pre- training of deep bidirectional transformers for language understanding,

    J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “Bert: Pre- training of deep bidirectional transformers for language understanding,” arXiv preprint arXiv:1810.04805 , 2019. [Online]. Available: https: //arxiv.org/abs/1810.04805

    2019 arXiv

  15. [23]

    Secretbench: A dataset of software secrets,

    S. K. Basak, L. Neil, B. Reaves, and L. Williams, “Secretbench: A dataset of software secrets,” arXiv preprint arXiv:2303.06729 , 2023

    2023 arXiv

  16. [24]

    (2023) Regular expressions used in secretbench dataset

    ——. (2023) Regular expressions used in secretbench dataset. https: //zenodo.org/records/7571266. Accessed: 2024-03-27

    2023

  17. [25]

    Large language models for text classification: Case study and comprehensive review,

    A. Kostina, M. D. Dikaiakos, D. Stefanidis, and G. Pallis, “Large language models for text classification: Case study and comprehensive review,” 2025. [Online]. Available: https://arxiv.org/abs/2501.08457

    2025 arXiv

  18. [26]

    Can large language models understand context?

    Y . Zhu, J. R. A. Moniz, S. Bhargava, J. Lu, D. Piraviperumal, S. Li, Y . Zhang, H. Yu, and B.-H. Tseng, “Can large language models understand context?” 2024. [Online]. Available: https://arxiv.org/abs/ 2402.00858

    2024 arXiv

  19. [27]

    An empirical study on capability of large language models in understanding code semantics,

    T.-T. Nguyen, T. T. Vu, H. D. V o, and S. Nguyen, “An empirical study on capability of large language models in understanding code semantics,” 2024. [Online]. Available: https://arxiv.org/abs/2407.03611

    2024 arXiv

  20. [28]

    Gpt-4 technical report,

    J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat et al. , “Gpt-4 technical report,” arXiv preprint arXiv:2303.08774 , 2023

    2023 arXiv

  21. [29]

    Deepseek-v3 technical report,

    A. Liu, B. Feng, B. Xue, B. Wang, B. Wu, C. Lu, C. Zhao, C. Deng, C. Zhang, C. Ruan et al., “Deepseek-v3 technical report,” arXiv preprint arXiv:2412.19437, 2024

    2024 arXiv

  22. [30]

    V . Kohli. (2023) Context window. https://www.techtarget.com/whatis/ definition/context-window. Accessed: 2024-04-13

    2023

  23. [31]

    Determination of context window size,

    K. Hung, R. Luk, D. Yeung, F.-L. Chung, and W. Shu, “Determination of context window size,” Int. J. Comput. Proc. Oriental Lang. , vol. 14, pp. 71–80, 03 2001

    2001

  24. [32]

    Language mod- els are few-shot learners,

    T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell et al., “Language mod- els are few-shot learners,” Advances in neural information processing systems, vol. 33, pp. 1877–1901, 2020

    1901

  25. [33]

    Llama: Open and efficient foundation language models,

    H. Touvron, T. Lavril, G. Izacard, X. Martinet, M.-A. Lachaux, T. Lacroix, B. Rozi `ere, N. Goyal, E. Hambro, F. Azhar, A. Rodriguez, A. Joulin, E. Grave, and G. Lample, “Llama: Open and efficient foundation language models,” 2023. [Online]. Available: https: //arxiv.org/abs/2...

    2023 arXiv

  26. [34]

    Gemma: Open models based on gemini research and technology,

    G. Team, T. Mesnard, C. Hardin, R. Dadashi, S. Bhupatiraju, S. Pathak, L. Sifre, M. Rivi `ere, M. S. Kale, J. Love et al. , “Gemma: Open models based on gemini research and technology,” arXiv preprint arXiv:2403.08295, 2024

    2024 arXiv

  27. [35]

    Code llama: Open foundation models for code,

    B. Rozi `ere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remez, J. Rapin, A. Kozhevnikov, I. Evtimov, J. Bitton, M. Bhatt, C. C. Ferrer, A. Grattafiori, W. Xiong, A. D ´efossez, J. Copet, F. Azhar, H. Touvron, L. Martin, N. Usunier...

    2024 arXiv

  28. [36]

    Finetuned language models are zero-shot learners,

    J. Wei, M. Bosma, V . Y . Zhao, K. Guu, A. W. Yu, B. Lester, N. Du, A. M. Dai, and Q. V . Le, “Finetuned language models are zero-shot learners,” 2022. [Online]. Available: https://arxiv.org/abs/2109.01652

    2022 arXiv

  29. [37]

    Qlora: Efficient finetuning of quantized llms,

    T. Dettmers, A. Pagnoni, A. Holtzman, and L. Zettlemoyer, “Qlora: Efficient finetuning of quantized llms,” 2023. [Online]. Available: https://arxiv.org/abs/2305.14314

    2023 arXiv

  30. [38]

    Parameter- efficient fine-tuning methods for pretrained language models: A critical review and assessment,

    L. Xu, H. Xie, S.-Z. J. Qin, X. Tao, and F. L. Wang, “Parameter- efficient fine-tuning methods for pretrained language models: A critical review and assessment,” 2023. [Online]. Available: https: //arxiv.org/abs/2312.12148

    2023 arXiv

Pith tools

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