Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

Repository-level Code Search with Neural Retrieval Methods

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

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

Pith's one-line read This paper claims that a three-stage pipeline—BM25 over commit messages plus two CodeBERT rerankers, trained across repositories—finds files relevant to a bug query far better than BM25 alone, ranking the correct file first for about 30%…

desk verdict The paper introduces a genuinely new task formulation for repository-level code search and backs it with a public dataset, but the headline gains are measured on a closed loop that may not survive contact with real bug reports. read the letter →

arxiv 2502.07067 v1 pith:3P4MGOVK submitted 2025-02-10 cs.IR

Siddharth Gandhi , Luyu Gao , Jamie Callan This is my paper · ORCID
classification cs.IR
keywords repository-levelcodesearchcommithistoryBM25BERTneuralrerankingbugfixingretrieval-augmentedgenerationretrieval
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

The paper tries to establish that a repository's own commit history is enough to point a search system at the files that need to be changed to fix a reported bug. Its proposed multi-stage pipeline first uses BM25 to match a query against past commit messages, aggregates those matches to files, then reranks with two CodeBERT-based models—one on commit messages and one on code patches—trained jointly across multiple repositories. The paper builds a new evaluation set from seven popular open-source repositories by having GPT-4 rewrite commit messages into short bug-issue-style queries, with the files edited in the original commit serving as ground truth. On that set the full pipeline reaches MRR 0.434 and P@1 0.299, roughly doubling BM25's 0.227 MRR and 0.139 P@1, and the code-patch reranker alone nearly matches the full system. A sympathetic reader would care because this is a cheap, self-supervising signal—commit messages already exist in every open-source project—that could give LLM-based coding agents concise, relevant file context.

What carries the argument

The load-bearing object is the file-level score aggregated from per-commit BM25 scores: rather than retrieving files directly, the system searches commit messages, assigns each commit a BM25 score, and gives each file the maximum score among all commits that modified it. That 'maxp' aggregation is used again at both reranking stages—the CommitReranker maxes over every commit touching a file, and the CodeReranker maxes over every patch of that file. Supplementary machinery includes time masking to hide future commits, file-identity (FID) mapping across renames, line-wise splitting of large files into 350-token patches for CodeBERT's 512-token limit, and supervised contrastive finetuning on label triplets where a positive is a commit or patch whose diff overlaps the ground-truth diff. The rerankers are trained on combined data from multiple repositories, which the paper finds helps more than more data from one repository.

What would settle it

Run the identical pipeline on real bug reports with known fixing commits, without rewriting the bug text into commit-message style; if the MRR and P@1 advantages over BM25 shrink to near zero, the gains are an artifact of the paraphrase proxy rather than of commit-history retrieval.

Watch

Extended reading notes

Core claim

The central claim is that repository-level code search can be treated as a matching problem between a user query and historical commit messages, followed by a source-code relevance check. The paper defines the task as retrieving, from the current snapshot of a repository, the files most relevant to a query or bug. Its system works in stages: BM25 retrieves past commits whose messages resemble the query; file scores are aggregated from those commits by taking the maximum score; a finetuned CodeBERT 'CommitReranker' rescores (query, commit-message) pairs; and a second finetuned CodeBERT 'CodeReranker' splits candidate files into line-wise patches, scores each patch against the query, and max-pools to a file score. Time masking prevents future commits from leaking into historical evaluations, and file-identity mapping keeps only files that exist in the current repository state. The paper reports that this pipeline achieves a mean reciprocal rank of 0.434 and precision at one of 0.299 averaged over seven repositories, versus 0.227 and 0.139 for BM25, with the CodeReranker at rerank depth 100 nearly matching the full pipeline.

Load-bearing premise

The evaluation assumes that a GPT-4 paraphrase of a commit message is a realistic stand-in for a user's bug report, and that every file edited in that commit is relevant to the query.

Editorial extensions

If this is right

  • If the central claim holds, a concise file-ranker can be built on commit history alone, shrinking a repository from tens of thousands of files to a handful of candidates for a bug report.
  • The CodeReranker's near-parity with the full three-stage pipeline implies that commit-message reranking adds little once code content is scored, so simpler two-stage systems may be sufficient.
  • Cross-repository training on diverse commit histories improves generalization, so adding more repositories should help rather than overfit.
  • Because recall at depth 100 is the bottleneck, further gains depend on improving first-stage recall rather than better reranking of already-retrieved files.
  • For LLM-based bug-fixing agents, providing the top 5-10 ranked files as context should be more effective than feeding large unfiltered codebases.

Reading between the lines

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

  • Beyond the paper: real bug reports carry stack traces and error output that commit-message paraphrases omit, so the same pipeline should be tested on raw issue text before claiming it serves actual developers.
  • Beyond the paper: because max-pooling across patches is what makes the code reranker work, the aggregation scheme likely transfers to any per-patch neural scorer, including dense retrievers.
  • Beyond the paper: the consistent peak at rerank depth 100 hints that pruning the candidate list before neural scoring could cut query latency by an order of magnitude without losing accuracy.
  • Beyond the paper: commit ground truth includes incidental edits, so evaluating on issue-linked pull requests that isolate the relevant files would likely raise all reported metrics and give a cleaner comparison.
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. This paper proposes a multi-stage retrieval pipeline for repository-level code file search: BM25 over commit messages with maxp file-score aggregation, followed by two CodeBERT-based rerankers (a CommitReranker over commit messages and a CodeReranker over code patches), with cross-repository training. The authors construct a new evaluation dataset from 7 open-source repositories by using GPT-4 to rewrite commit messages into short GitHub-issue-style queries and treating the files edited by each commit as relevant. On this dataset the full pipeline achieves MRR 0.434 and P@1 0.299 averaged over repositories, compared to BM25's 0.227 and 0.139 (Table 7). The paper also reports oracle experiments, reranking-depth analyses, and per-repository results.

Significance. Strengths: the paper is among the first to use commit messages systematically as a retrieval index for repository-level file search; it releases code and data; it evaluates across seven large real-world repositories with careful time masking and FID mapping; and it provides detailed ablations of two reranker designs. If the reported gains transfer to real bug reports, the approach would be practically valuable for LLM-based coding agents. The main weakness is that the headline improvements are measured on a self-created benchmark whose queries are paraphrases of the very commit messages that form the index and training data, and whose labels are the files edited by those commits. External validity therefore rests on the untested assumption that GPT-4-paraphrased commit messages and commit-edit lists approximate real user issues and true file relevance. Additional external validation or a re-scoping of the claims is needed.

major comments (4)
  1. [Section 3.2 and Sections 3.4–3.5] The evaluation is circular in an important sense: Section 3.2 constructs the test set by asking GPT-4 to rewrite each test commit's own commit message into a GitHub-issue-style query, and defines relevance as membership in that commit's edited-file list. Sections 3.4 and 3.5 train the two rerankers on queries generated identically (GPT-modified commit messages) with the same edited-file or diff-overlap supervision. The test distribution is therefore generated from the same source messages that are also the retrieval index, and the model can succeed by matching GPT-4's paraphrase style to the indexed commit messages without demonstrating any transfer to real user bug reports. The paper's own Section 5 observes that GitHub issues are 'much less noisy than commits,' yet no evaluation on real issues is provided. I recommend adding an external test set of genuine issue reports (e.g., from SWE-bench or manually curated issues) with human-verified relevance, or explicitly limiting the paper's claims to commit-message-derived queries.
  2. [Section 4, Tables 7–8, Figures 3–4] The full-pipeline configuration (CommitReranker at depth 1000 and CodeReranker at depth 100) and the statement that '100 is an optimal reranking depth' appear to be based on the test-set results reported in Tables 7 and 8 and Figures 3–4. No validation split, selection criterion, or stability analysis is described. If the reranking depth was chosen after inspecting test metrics, the reported MRR 0.434 and P@1 0.299 are test-set-selected and should be expected to shrink on unseen data. Please clarify how the depth was selected and provide validation-set numbers, or present the depth sweep as exploratory rather than as the configuration used for the headline result.
  3. [Section 3.3 and Table 7] The only baseline considered is BM25 over commit messages, which is also the first stage of the proposed pipeline. This setup does not establish that commit-history modeling is preferable to standard repository-level retrieval over the current code, e.g., BM25 over file contents, BM25 over file paths, or a dense retriever over code chunks. Since the test queries are generated from commit messages, the BM25-over-messages baseline may actually be favored by lexical overlap, and a code-only baseline would provide a crucial reference point for the claim that 'leveraging commit histories is a viable approach.' I request a baseline over current file contents and/or file paths and, if possible, an evaluation on real issue-style queries.
  4. [Section 3.3] The evaluation protocol has a temporal mismatch whose magnitude is not quantified. Queries are derived from historical test commits, but the candidate set is filtered to files present in the repository's current state. The paper masks future commits for BM25, yet the final output must be a current-state file, so a relevant file that was deleted or renamed after the test commit may be unmappable and therefore unretrievable. The paper acknowledges the 'FID issue' in Section 3.3 but does not report how many test files were excluded by this filtering. Please clarify the intended deployment setting (historical state vs current state) and report the fraction of test files that could not be mapped to the current snapshot.
minor comments (4)
  1. [Abstract vs Table 7] The abstract states 'improvements of up to 80% in MAP, MRR and P@1,' but Table 7 indicates full-pipeline improvements of roughly 88% for MAP, 91% for MRR, and 115% for P@1; please make the percentage claims consistent with the reported numbers.
  2. [Section 2.4 and References] The reference for CCFinder (Ding et al., 2023) is titled 'Co-comic: Code completion by jointly modeling in-file and cross-file context,' but the text discusses CCFinder and joint learning of in-file and cross-file context; please correct the reference name/title or clarify the relationship.
  3. [Appendix A.1] The metric appendix mixes notation: the relevant-file set is introduced as Ft and later used as Fa, and the MRR definition '1/(j+1)' should state explicitly that j is zero-based to avoid ambiguity with the standard 1-based reciprocal rank definition.
  4. [Section 4] The text says 'there are approximately 3 files edited per test query,' but Table 4 reports a mean of 3.5 across repositories; please align the wording with the table.

Circularity Check

2 steps flagged · score 6.0 of 10

The claimed retrieval gains are measured on a closed loop: test queries are GPT-4 paraphrases of the same commit messages that form the BM25 index and the training data, and relevance is the edited-file list of that commit, so the benchmark tests fit to the synthetic paraphrase distribution rather than transfer to real bug reports.

  1. self definitional [Section 3.2, 'GPT-Modified (GPT-M) Test Query Set' and 'Relevance matching']
    "To create a realistic evaluation setup, we select 100 commits from each repository as test-commits, which are excluded from the training data for all models. For each test-commit, we feed the commit message to GPT-4 and prompt it to generate the most probable problem description in the style of a GitHub issue... For a test query qt, which is a GPT-Modified version of a test commit ct with a list of actually modified files Ft, we consider a file Fr[i] from our system's retrieved list of files Fr to be relevant if it is present in Ft."

    The test query is generated from the same commit whose message is indexed by BM25 (the test commit is only excluded from reranker training; Section 3.3 keeps all past commits in the index) and whose edited-file list defines relevance. Hence every test query has, by construction, a target commit in the index whose message produced the query and whose edited files are the labels. Retrieval success therefore reduces to recovering that source commit from its GPT-4 paraphrase, and the measured MRR/P@1 quantify paraphrase-to-commit matching, not retrieval for independently collected real user issues.

  2. fitted input called prediction [Section 3.4, 'Supervised Contrastive Finetuning' (and analogous CodeReranker construction in Section 3.5)]
    "Query: A query qtrain from a set of training queries Qtrain, which are GPT-modified versions of a fixed number of train commits (similar to Section 3.2). Each query has a ground truth list of edited files Ftruth."

    The rerankers are finetuned on exactly the same construction used for the test set: GPT-modified commit-message queries paired with the edited-file lists of those commits. The test queries and labels are generated by the identical procedure (Section 3.2), so the reported 'prediction' is the training objective itself. The improvements over BM25 show that the model can fit the GPT-paraphrase-to-edited-files mapping, not that it generalizes to real GitHub issues; the paper itself concedes this limitation in Section 5 ('just narrowing data to Github issues which are much less noisy than commits').

full rationale

The paper's core contribution is an empirical retrieval pipeline, not a mathematical derivation, so the circularity here sits in the benchmark construction rather than in equations. The closed loop is explicit: Section 3.2 creates test queries by asking GPT-4 to paraphrase a commit message and defines relevance as membership in that same commit's edited-file list; Section 3.3 indexes exactly those commit messages; Sections 3.4-3.5 train the rerankers on GPT-modified commit-message queries with edited-file labels. Thus the test distribution is the training distribution, and the index is guaranteed to contain a near-oracle commit for every query. This does not mean the measured numbers are fabricated or that the pipeline could not work, but it does mean the reported MRR 0.434 / P@1 0.299 and the 'up to 80%' improvements support only the claim that the system can map GPT-4-style paraphrases back to the commits they were derived from. The paper acknowledges the label heuristic is imperfect (Section 3.2) and that GitHub issues would be 'much less noisy' (Section 5), but no external validation on real issues or on SWE-bench is provided. Because the central claim is evaluated entirely within this self-generated loop, the score is 6: the prediction reduces, by construction of the benchmark, to the training/evaluation mapping.

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

The central claim rests on a self-built evaluation where the test queries are GPT-4 rewrites of commit messages and the labels are the files modified in those commits. This makes the commit-history signal, the training supervision, and the evaluation metric all derive from the same source, which is the main uncharged assumption. The numeric hyperparameters (depth 100, maxp, patch length) were selected with some post-hoc tuning on the test distribution.

free parameters (6)
  • BM25 k1 = 0.9
    Fixed in Section 3.6 for Pyserini BM25; standard default, not tuned on the test set.
  • BM25 b = 0.4
    Fixed in Section 3.6; standard default.
  • Reranking depth = 100 (optimal)
    Depth 100 is reported as optimal in Section 4 and Figure 4 after observing test-set peaks; this is a post-hoc selection.
  • maxp aggregation = max
    Chosen over sum and average in preliminary experiments for R@1000 (Section 3.3); used in both rerankers.
  • Code patch length = 350 tokens
    Hand-chosen in Section 3.5 to fit CodeBERT's 512-token limit; not justified by ablation.
  • Training triplets per query = 10 positive, 10 negative
    Used to create training data in Sections 3.4 and 3.5; authors note this may bias models to top-100 documents.
assumptions (6)
  • standard math Pyserini's BM25 scoring formula is correctly applied to tokenized commit messages
    Section 3.3 uses Pyserini BM25; assumes the implementation is correct.
  • domain assumption CodeBERT's pretrained representations capture semantic similarity between natural-language queries, commit messages, and code patches
    Sections 3.4 and 3.5 rely on CodeBERT cross-encoder scores after contrastive fine-tuning.
  • ad hoc to paper Files edited in the commit that resolves a bug are the complete and correct set of relevant files for that bug report
    Section 3.2 defines relevance this way and acknowledges not all edited files may be relevant to the query.
  • domain assumption GPT-4-generated issue descriptions do not leak solution details from the commit message
    Section 3.2 relies on prompt engineering; the authors note GPT-3.5 leaked details, so the assumption is not automatically guaranteed for GPT-4.
  • ad hoc to paper Line-by-line diff overlap between the candidate commit and the target commit is a valid supervision signal for code-patch relevance
    Section 3.5 labels code patches as positive when their diffs share lines with the target diff; this is a heuristic.
  • domain assumption Git's rename detection and the FID mapping correctly identify the same file across history
    Section 3.3 notes Git rename heuristics may be inaccurate and can map one FID to two files at the same state.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Repository-level Code Search with Neural Retrieval Methods." pith.science (2026). https://pith.science/paper/3P4MGOVK

@misc{pith2026250207067,
  author       = {Pith},
  title        = {Pith review of: Repository-level Code Search with Neural Retrieval Methods},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3P4MGOVK}},
  note         = {Machine review of arXiv:2502.07067}
}
read the original abstract

This paper presents a multi-stage reranking system for repository-level code search, which leverages the vastly available commit histories of large open-source repositories to aid in bug fixing. We define the task of repository-level code search as retrieving the set of files from the current state of a code repository that are most relevant to addressing a user's question or bug. The proposed approach combines BM25-based retrieval over commit messages with neural reranking using CodeBERT to identify the most pertinent files. By learning patterns from diverse repositories and their commit histories, the system can surface relevant files for the task at hand. The system leverages both commit messages and source code for relevance matching, and is evaluated in both normal and oracle settings. Experiments on a new dataset created from 7 popular open-source repositories demonstrate substantial improvements of up to 80% in MAP, MRR and P@1 over the BM25 baseline, across a diverse set of queries, demonstrating the effectiveness this approach. We hope this work aids LLM agents as a tool for better code search and understanding. Our code and results obtained are publicly available.

Figures

Figures reproduced from arXiv: 2502.07067 by the authors.

Figure 1
Figure 1. An overview of our system 1. A BM25-based system to search over previous commits with similar messages in the repository and identify the files they modified, narrowing down the search scope from the order of 10,000 to approximately 1,000 files. 2. A BERT-based CommitReranker that reranks the list obtained from the BM25 system, taking into account the semantic understanding of the commit messages. This step further … view at source ↗
Figure 2
Figure 2. Histogram of Number of files per FID across [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Visualization of Table [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Visualization of Table 8a. CodeReranker (blue) is significantly better compared to CommitReranker(red) in all settings, however the Full Pipeline is still surprisingly better [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Visualization of Table 8b. Notice how much the grey curve is lifted by both red and blue lines. CodeReranker (blue) improves the same pre-ranking (grey) significantly more than CommitReranker (red). Full Pipeline Performance The full pipeline per￾forms well but does no…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Harness Handbook: Making Evolving Agent Harnesses Readable,Navigable, and Editable

    cs.AI 2026-07 conditional novelty 6.0 of 10

    A behavior-centered handbook generated from agent-harness code helps LLM planners find the right edit sites and produce better edit plans than direct repository exploration.

Reference graph

Works this paper leans on

28 extracted references · 7 canonical work pages · cited by 1 Pith paper

  1. [1]

    Anthropic . 2023. https://www.anthropic.com/index/100k-context-windows Introducing 100k context windows

    work page 2023

  2. [2]

    Anthropic. 2024. https://www.anthropic.com/news/claude-3-family The claude 3 model family: Opus, sonnet, haiku . Accessed: 2024-05-02

    work page 2024

  3. [3]

    Zhuyun Dai and Jamie Callan. 2019. Deeper text understanding for ir with contextual neural language modeling. In Proceedings of the 42nd international ACM SIGIR conference on research and development in information retrieval, pages 985--988

    work page 2019

  4. [4]

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2018. Bert: Pre-training of deep bidirectional transformers for language understanding. arXiv preprint arXiv:1810.04805

    arXiv 2018

  5. [5]

    Yangruibo Ding, Zijian Wang, Wasi Uddin Ahmad, Murali Krishna Ramanathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, and Bing Xiang. 2023. http://arxiv.org/abs/2212.10007 Cocomic: Code completion by jointly modeling in-file and cross-file context

    arXiv 2023

  6. [6]

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, and Ming Zhou. 2020. http://arxiv.org/abs/2002.08155 Codebert: A pre-trained model for programming and natural languages

    arXiv 2020

  7. [7]

    GitHub Next . 2023. https://githubnext.com/projects/copilot-workspace/ Copilot workspace

    work page 2023

  8. [8]

    Xiaodong Gu, Hongyu Zhang, and Sunghun Kim. 2018. https://doi.org/10.1145/3180155.3180167 Deep code search . ICSE '18, page 933–944, New York, NY, USA. Association for Computing Machinery

    arXiv 2018

Show all 28 references
  1. [9]

    Daya Guo, Shuo Ren, Shuai Lu, Zhangyin Feng, Duyu Tang, Shujie LIU, Long Zhou, Nan Duan, Alexey Svyatkovskiy, Shengyu Fu, Michele Tufano, Shao Kun Deng, Colin Clement, Dawn Drain, Neel Sundaresan, Jian Yin, Daxin Jiang, and Ming Zhou. 2021. https://openreview.net/forum?id=jLoC...

    2021

  2. [10]

    Hamel Husain, Ho-Hsiang Wu, Tiferet Gazit, Miltiadis Allamanis, and Marc Brockschmidt. 2020. http://arxiv.org/abs/1909.09436 Codesearchnet challenge: Evaluating the state of semantic code search

    2020 arXiv

  3. [11]

    Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan

    Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2023. http://arxiv.org/abs/2310.06770 Swe-bench: Can language models resolve real-world github issues?

    2023 arXiv

  4. [12]

    Vladimir Karpukhin, Barlas O g uz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih. 2020. Dense passage retrieval for open-domain question answering. arXiv preprint arXiv:2004.04906

    2020 arXiv

  5. [13]

    u ttler, Mike Lewis, Wen-tau Yih, Tim Rockt \

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich K \"u ttler, Mike Lewis, Wen-tau Yih, Tim Rockt \"a schel, et al. 2020. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in Neural Information Proc...

    2020

  6. [14]

    Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, Jenny Chim, Qian Liu, Evgenii Zheltonozhskii, Terry Yue Zhuo, Thomas Wang, Olivier Dehaene, Mishig Davaadorj, Joel Lamy-Poirier, João Monteiro, ...

    2023 arXiv

  7. [15]

    Jimmy Lin, Xueguang Ma, Sheng-Chieh Lin, Jheng-Hong Yang, Ronak Pradeep, and Rodrigo Nogueira. 2021. Pyserini : A Python toolkit for reproducible information retrieval research with sparse and dense representations. In Proceedings of the 44th Annual International ACM SIGIR Con...

    2021

  8. [16]

    Shuai Lu, Daya Guo, Shuo Ren, Junjie Huang, Alexey Svyatkovskiy, Ambrosio Blanco, Colin Clement, Dawn Drain, Daxin Jiang, Duyu Tang, Ge Li, Lidong Zhou, Linjun Shou, Long Zhou, Michele Tufano, Ming Gong, Ming Zhou, Nan Duan, Neel Sundaresan, Shao Kun Deng, Shengyu Fu, and Shuj...

    2021 arXiv

  9. [17]

    Tsendsuren Munkhdalai, Manaal Faruqui, and Siddharth Gopal. 2024. Leave no context behind: Efficient infinite context transformers with infini-attention. arXiv preprint arXiv:2404.07143

    2024 arXiv

  10. [18]

    OpenAI. 2023. http://arxiv.org/abs/2303.08774 Gpt-4 technical report

    2023 arXiv

  11. [19]

    OpenAI . 2023. https://github.com/openai/tiktoken Tiktoken github

    2023

  12. [20]

    Pinecone . 2023. https://www.pinecone.io/blog/why-use-retrieval-instead-of-larger-context Less is more: Why use retrieval instead of larger context windows

    2023

  13. [21]

    Stephen Robertson, Hugo Zaragoza, et al. 2009. The probabilistic relevance framework: Bm25 and beyond. Foundations and Trends in Information Retrieval , 3(4):333--389

    2009

  14. [22]

    Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, Artyom Kozhevnikov, Ivan Evtimov, Joanna Bitton, Manish Bhatt, Cristian Canton Ferrer, Aaron Grattafiori, Wenhan Xiong, Alexandre Défoss...

    2023 arXiv

  15. [23]

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven C. H. Hoi. 2021. http://arxiv.org/abs/2109.00859 Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation

    2021 arXiv

  16. [24]

    Peng Xu, Wei Ping, Xianchao Wu, Lawrence McAfee, Chen Zhu, Zihan Liu, Sandeep Subramanian, Evelina Bakhturina, Mohammad Shoeybi, and Bryan Catanzaro. 2023. http://arxiv.org/abs/2310.03025 Retrieval meets long context large language models

    2023 arXiv

  17. [25]

    Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press

    John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent computer interfaces enable software engineering language models

    2024

  18. [26]

    Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. 2023. http://arxiv.org/abs/2303.12570 Repocoder: Repository-level code completion through iterative retrieval and generation

    2023 arXiv

  19. [27]

    URL: " 'urlintro :=

    ENTRY address author booktitle chapter edition editor howpublished institution journal key month note number organization pages publisher school series title type volume year eprint doi pubmed url lastchecked label extra.label sort.label short.list INTEGERS output.state before...

  20. [28]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 gl...

Pith tools

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