PaperlayerView exact revision on arXiv

Source-linked AI summary

Beyond Retrieval: A Multitask Benchmark and Model for Code Search

Siqiao Xue, Zihan Liao, Jin Qin, Ziyin Zhang, Yixiang Mu, Fan Zhou, Hang Yu

arXiv:2605.04615v2cs.SEcs.AI

TL;DR

Existing code-search benchmarks do not fully evaluate reranking and face contamination concerns, while developer-style short queries remain difficult. CoREB addresses this with a contamination-limited multitask benchmark and fine-tuned reranker, finding consistent gains across text-to-code, code-to-text, and code-to-code tasks.

  • Problem

    Existing code-search benchmarks omit reranking support and face contamination and benchmark-overfitting concerns, limiting evaluation of the full pipeline.

  • Method

    CoREB combines a contamination-limited multitask benchmark with a fine-tuned code reranker covering retrieval and reranking across three tasks.

  • Results

    No single model wins all three tasks; off-the-shelf rerankers show a 12-point code-to-code swing, while COREB-RERANKER achieves consistent gains across all three.

  • Takeaways & Limitations

    Code-specialised training matters more than scale, while short keyword queries remain unsolved and reranker choice is high-stakes.

  • Takeaways & Limitations

    Short-query retrieval remains an open problem: keyword-style queries achieve near-zero performance, and scaling or reranking does not close the gap.

Abstract

from arXiv · show

Code search has usually been evaluated as first-stage retrieval, even though production systems rely on broader pipelines with reranking and developer-style queries. Existing benchmarks also suffer from data contamination, label noise, and degenerate binary relevance. In this paper, we introduce \textsc{CoREB}, a contamination-limited, multitask \underline{co}de \underline{r}etrieval and r\underline{e}ranking \underline{b}enchmark, together with a fine-tuned code reranker, that goes beyond retrieval to cover the full code search pipeline. \textsc{CoREB} is built from counterfactually rewritten LiveCodeBench problems in five programming languages and delivered as timed releases with graded relevance judgments. We benchmark eleven embedding models and five rerankers across three tasks: text-to-code, code-to-text, and code-to-code. Our experiments reveal that: \circone code-specialised embeddings dominate code-to-code retrieval (${\sim}2{\times}$ over general encoders), yet no single model wins all three tasks; \circtwo short keyword queries, the format closest to real developer search, collapse every model to near-zero nDCG@10; \circthree off-the-shelf rerankers are task-asymmetric, with a 12-point swing on code-to-code and no baseline net-positive across all tasks; \circfour our fine-tuned \textsc{CoREB-Reranker} is the first to achieve consistent gains across all three tasks. The data and model are released.

1 Introduction

CoREB addresses gaps in evaluating modern code-search pipelines by combining contamination-limited multitask retrieval with reranking, programmatic relevance labels, and graded judgments. Across three tasks, experiments show strong task asymmetry, severe keyword-query failure, and consistent gains from the fine-tuned CoREB-Reranker.

  • Motivation: Existing code-retrieval benchmarks omit reranking, forcing practitioners to assemble pipelines with generic encoders that may hurt code-specific retrieval.This limitation leaves the full production-style code-search pipeline unevaluated.
  • Benchmark design: CoREB uses counterfactually rewritten LiveCodeBench problems and regenerated artifacts to limit contamination while preserving functional semantics.The benchmark automatically constructs text-to-code, code-to-text, and code-to-code tasks across five programming languages.
  • Benchmark design: Programmatic execution outcomes replace noisy human labels, addressing the ∼51% mislabeling reported for CosQA.Candidate relevance is determined by pass/fail status against test oracles.
  • Benchmark design: 68% of text-to-code queries have two or more correct solutions, motivating graded judgments with multiple positives and explicit hard negatives.The relevance scheme assigns relevance=2 to true positives, relevance=1 to same-problem hard negatives, and treats unjudged items as easy negatives.
  • Empirical findings: ∼2× code-to-code gains favor code-specialised embeddings, while short keyword queries collapse every model to near-zero nDCG@10 and reranker baselines vary by 12 points.No single model wins every task, no off-the-shelf reranker is net-positive across all tasks, and CoREB-Reranker achieves consistent gains across all three tasks.

2 Related Work

Related work traces code LLMs from specialized systems such as Codex to frontier and open models with integrated coding and general reasoning. It also situates evaluation within broad text-retrieval benchmarks including BEIR and MTEB.

  • Code LLMs: Code LLMs span specialized systems, frontier models, and open families that combine coding capability with general reasoning.Examples include Codex; GPT-4.1, Claude 3.5, and Gemini 3 Pro; and StarCoder2 and Qwen2.5-Coder.
  • Retrieval Evaluation: BEIR and MTEB provide broad benchmarks for evaluating text retrieval.

3 Benchmark Construction

COREB is constructed as a contamination-resistant, realism-oriented benchmark through timed LiveCodeBench releases, counterfactual rewriting, human-reviewed query generation, and task-specific graded retrieval instances. Its relevance formulation distinguishes verified solutions from plausible but incorrect items and makes ranking metrics stricter than CoIR.

  • Seed problem sourcing: COREB uses timed releases from temporally filtered LiveCodeBench snapshots to limit contamination.The releases cover contest problems from September 2024–January 2025 and January–April 2025.
  • Counterfactual rewriting: Counterfactual rewriting changes names, framing, and I/O examples while preserving each problem’s formal specification and algorithmic structure.This controlled intervention is intended to reduce memorization effects without changing intrinsic task difficulty.
  • Query generation: COREB generates multiple task-level query variants with LLM assistance and human review for faithfulness and leakage avoidance.Representative instances, schemas, and per-subtask examples are provided in Appendix A.5.
  • Retrieval instance formulation: Each retrieval instance pairs a task-specific query and corpus with a three-level graded relevance label.Relevance 2 denotes verified positives, while relevance 1 denotes same-problem items that are superficially plausible but incorrect.
  • Evaluation labels: Relevance level=2 makes binary metrics count only true positives and gives nDCG zero gain for hard negatives that still displace positives.This is deliberately stricter than CoIR because retrieving an incorrect same-problem item is not treated as success.

4 Experiments

COREB evaluates retrieval and reranking as a production-style two-stage code-search pipeline across three retrieval directions. Results show strong task asymmetry: specialized embeddings excel on code-heavy tasks, short keyword queries remain unsolved, and only in-domain fine-tuning improves all three tasks.

  • Embedding retrieval: No single embedding model dominates all three tasks: GemEmb-2 leads overall nDCG@10 and code-to-text/code-to-code, while C2LLM-7B leads text-to-code.Code-specialized open models outperform comparable or larger general-purpose encoders.
  • Task difficulty: Code-to-text is easiest at model-averaged nDCG@10 0.73, text-to-code hardest at 0.39, and code-to-code intermediate at 0.52 but most discriminative.Code-to-code has twice code-to-text’s cross-model spread.
  • Embedding retrieval: 0.5 B specialized models can outperform much larger general-purpose models: C2LLM-0.5B beats Qwen3-Emb-8B by over 12 points overall.Jina-code-emb-0.5b also ranks second on code-to-code nDCG@10 among open checkpoints, despite being 14× smaller than C2LLM-7B.
  • Query difficulty: Every model falls to near-zero nDCG@10 on 19-token keyword Search queries, two orders of magnitude below long-query Canonical queries.This short-query regime is closest to real developer search and remains unsolved; neither embedding scaling nor reranking closes the gap.
  • Evaluation signal: Hard-negative intrusion exceeds 55% for every text-to-code model, meaning failed solutions outrank correct ones in more than half of qualifying queries.GemEmb-2 reaches 64% intrusion, showing that stronger models can also exhibit higher intrusion.
  • Reranking: Only COREB-RERANKER is net-positive across all three tasks; no off-the-shelf baseline achieves that consistency.The reranker is fine-tuned from Qwen3-Reranker-4B via LoRA on a 3.1M-sample corpus, completing a retrieval-plus-in-domain-reranking pipeline.

5 Conclusion

CoREB covers both retrieval and reranking across three code-search tasks and five languages, while identifying specialization, short queries, low-resource languages, and reranker choice as central challenges.

  • Contributions: CoREB is a contamination-limited benchmark and reranker spanning both code-search pipeline stages, three tasks, and five languages.The benchmark and model jointly address retrieval and reranking rather than retrieval alone.
  • Findings: Code-specialised training matters more than scale, while short keyword queries and low-resource languages remain unsolved failure modes.These findings identify limitations that persist across the evaluated code-search setting.
  • Findings: Reranker selection is high-stakes for code-search performance.The conclusion highlights reranker choice as an important practical factor in the pipeline.

Appendices … A.4 Dataset Format and Naming Convention

The appendices specify how CoREB constructs contamination-limited problems, hard negatives, multitask subtasks, and structured query, text, and code records. They preserve algorithmic equivalence while enabling controlled retrieval evaluation across task directions, query styles, languages, and cross-language settings.

  • A.1 Annotation Details: Counterfactual rewriting changes superficial problem details while preserving the underlying algorithmic challenge, output, difficulty, and solution requirements.Transformations include named-entity, domain, noun-phrase, synonym, and variable/function-name changes; numerical test cases remain unchanged, while non-numerical cases receive minimal changes.
  • A.1 Annotation Details: Rewritten problems also receive retrieval-optimized 50–150-word abbreviations retaining core goals, constraints, distinctive terminology, and essential algorithmic information.The abbreviation format removes redundancy and emphasizes clear developer-search language, specific numerical limits, input/output formats, unique requirements, and central algorithmic hints.
  • A.2 Hard Negative Generation: 1,368 hard negatives are added across releases, consisting of four LLM-generated perturbations per problem that resemble positives lexically or structurally but differ algorithmically.The releases contain 668 hard negatives in v202602 and 700 in v202603; Qwen-32B generates them using varied perturbation strategies and temperatures.
  • A.2 Hard Negative Generation: Graded judgments assign relevance=2 to true positives and relevance=1 to hard negatives, penalizing plausible-but-incorrect documents ranked above positives.Unjudged corpus items act as easy negatives, while code hard negatives include failed same-problem solutions and otherwise correct solutions excluded by subtask constraints.
  • A.3 Main Tasks and Subtasks: CoREB organizes retrieval into text-to-code, code-to-code, and code-to-text main tasks, with subtasks varying query style, matching regime, language constraint, and invariance setting.The hierarchy supports both overall benchmarking and diagnostic analysis by isolating linguistic variability, verbosity, keyword-style queries, and cross-language generalization.
  • A.3 Main Tasks and Subtasks: Text-to-code and code-to-text include canonical retro, full retro, and search or match variants, distinguishing abbreviated, full-description, developer-style, and paired-retrieval settings.Search further separates description, algorithm, and language-agnostic query types; match uses the same ranked-retrieval protocol despite binary query labels.
  • A.3 Main Tasks and Subtasks: Cross-language code-to-code retrieval uses a solution in one language as the anchor and seeks an equivalent solution in a different target language.The current cross-lang variant uses Python, Java, C++, or Go anchors generated by Claude Sonnet 4.5, with target languages recorded per query.
  • A.4 Dataset Format and Naming Convention: Query identifiers encode task, subtask type, language constraint, and a zero-padded index, while corpus records align source-problem metadata with full or abbreviated text and candidate-code execution fields.Text records store both full and condensed views; code records include language, model, code length, source problem ID, pass status, pass rate, and test outcomes.

A.5 Task Instance Examples · A.6 Evaluation Protocol and Metrics

The benchmark illustrates three retrieval tasks through representative queries and relevance judgments, while evaluating every subtask with a uniform ranked-retrieval protocol. Evaluation uses graded relevance, broad ranking metrics, and anchor exclusion for code-to-code queries to avoid trivial self-retrieval.

  • A.5 Task Instance Examples: Representative CoREB examples cover text-to-code, code-to-code, and code-to-text queries with accompanying relevance judgments.The examples are drawn directly from the dataset, with code snippets truncated for readability.
  • A.5 Task Instance Examples: Text-to-code instances include abbreviated natural-language problem descriptions and short developer-style queries, with optional language constraints such as Python.The examples include a language-agnostic canonical query and a Python-restricted search query.
  • A.5 Task Instance Examples: Code-to-code retrieval targets semantically equivalent implementations and, in the current release, uses cross-language queries such as a Java anchor with a Python target.The representative anchor was produced by Claude Sonnet 4.5.
  • A.5 Task Instance Examples: Code-to-text retrieval uses code snippets to retrieve natural-language problem descriptions, including full-retro and pair-match instances.Pair-match examples are pre-paired with a binary label, but evaluation still ranks the full text corpus.
  • A.6 Evaluation Protocol and Metrics: All subtasks use one ranked-retrieval protocol: models rank every corpus item by cosine similarity and are scored with nDCG@k, MAP@k, Recall@k, MRR@k, and Precision@k.The reported cutoffs are nDCG@1, 3, 5, 10; MAP@10, 100; Recall@1, 3, 5, 10, 100; MRR@10; and Precision@1, 3, 5, 10.
  • A.6 Evaluation Protocol and Metrics: Code-to-code metrics exclude the exact anchor code from each ranked list because its near-perfect similarity would otherwise produce trivial rank-1 retrieval.This exclusion is intended to measure cross-language retrieval ability rather than self-retrieval.

A.7 Experimental Validation: Effect of Annotation … B.2 Inference and Evaluation Details

Controlled annotation materially changes benchmark evaluation in model- and release-dependent ways, demonstrating that original problem statements introduce unpredictable leakage bias. The benchmark also specifies regenerated multilingual solution corpora, task-specific relevance labels, licensed evaluation tooling, and inference-only embedding evaluation.

  • A.7 Experimental Validation: Effect of Annotation: −12.3 points: Claude Sonnet 4.5’s Pass@1 drops from 35% to 22% on v202602, but changes only +2.0 points on v202603.Gemini 3 Flash drops by −8.6 points on v202602 and −6.5 points on v202603, across all five languages.
  • A.7 Experimental Validation: Effect of Annotation: Annotation is necessary because leakage varies unpredictably by model and release, making original statements an uncontrolled source of performance bias.Gemini leaks on both releases, whereas Claude leaks strongly only on v202602.
  • A.8 Code Solution Generation: 1,744 candidate solutions are generated for v202603 across five languages from Gemini 3 Flash and Claude Sonnet 4.5, with all candidates retained.The nominal 1,750 candidates are reduced by six missing model–language combinations.
  • A.8 Code Solution Generation: 31.6% of v202602 candidates and 30.8% of v202603 candidates are verified correct, totaling 1,065 solutions across releases.Verified-correct solutions pass every test; code-to-code positives are restricted to them, while text-to-code treats all solutions for the queried problem as relevant.
  • B Experiment Details: The two generation models provide complementary language strengths, ensuring broad language coverage and few problems without a correct solution.This supports the verified-correct subset used for code-to-code relevance labeling.
  • B.1 Implementation Details: The analysis and data-processing framework uses the public Doraemon repository under the GNU General Public License.The cited repository is github.com/wuji3/Doraemon (Du et al., 2025).
  • B Experiment Details: Evaluation uses public BEIR, Look-Bench, and DB-GPT-Hub codebases under Apache and MIT licenses.These repositories provide the cited evaluation framework components.
  • B.2 Inference and Evaluation Details: Embedding models are evaluated inference-only on CoREB, using default pooling and model-recommended dot-product or cosine similarity configurations.All corpus documents and queries are encoded without fine-tuning or adaptation on CoREB data.

B.3 Fine-Tuned COREB-RERANKER Training Protocol · B.4 Evaluation Metrics

The COREB-RERANKER is fine-tuned as a generative yes/no causal-LM reranker on mixed code-search data, then evaluated out-of-sample by reranking retrieved candidates. Evaluation uses Recall@k for top-k coverage, nDCG@k for graded ordering quality, and MRR for the first relevant result’s position.

  • B.3 Fine-Tuned COREB-RERANKER Training Protocol: COREB-RERANKER is initialized from Qwen3-Reranker-4B and represents relevance through the probability of the verbal answer yes.It retains the released tokenizer, chat template, instruction format, and causal-LM reranking setup.
  • B.3 Fine-Tuned COREB-RERANKER Training Protocol: Training combines CoREB v202602 with CodeSearchNet, APPS, CosQA, and single- and multi-turn CodeFeedback examples.The corpus includes code-to-code, code-to-text, and text-to-code retrieval data.
  • B.3 Fine-Tuned COREB-RERANKER Training Protocol: Each source record yields binary examples with positives duplicated twice and one easy plus one hard negative sampled when available.Positives receive yes labels; both negative types receive no labels, and examples are shuffled across tasks with a held-out validation split.
  • B.3 Fine-Tuned COREB-RERANKER Training Protocol: Hard and easy negatives contribute as independent no-labeled pairwise examples rather than competing in a shared listwise denominator.The causal-language-model cross-entropy is masked to the assistant answer region, excluding system and user prompt tokens.
  • B.3 Fine-Tuned COREB-RERANKER Training Protocol: The released checkpoint averages the LoRA adapter weights of two independently fine-tuned variants with equal coefficients before merging them into the base model.The variants differ only in random seed and data-shuffle order; selection used validation nDCG@10 on a held-out split.
  • B.3 Fine-Tuned COREB-RERANKER Training Protocol: At test time, C2LLM-7B supplies the top-128 candidates, which the reranker scores and re-sorts before nDCG@10 and Recall@10 are computed against graded qrels.The reranker does not see v202603 problems, queries, or qrels during training, making evaluation out-of-sample at the problem level.
  • B.4 Evaluation Metrics: Recall@k measures the proportion of relevant items retrieved within the top k, evaluates coverage rather than ordering, and increases monotonically with k.Recall@k ranges from 0 to 1.
  • B.4 Evaluation Metrics: nDCG@k measures ranked-list quality through discounted cumulative gain, while MRR measures the position of the first relevant result and is sensitive to early retrieval.Both metrics are normalized or bounded between 0 and 1; MRR is 0 when no relevant item is retrieved.

B.5 Per-Release Retrieval Results

The section reports v202602 retrieval results and compares them with v202603. Rankings remain largely stable across releases, while task-level score shifts are small and likely reflect differences in problem distributions.

  • v202602 results: Table 14 reports per-task nDCG@10 and Recall@10 for eleven models on COREB v202602.The results cover text-to-code, code-to-text, and code-to-code retrieval tasks.
  • Cross-release comparison: C2LLM-7B leads on both releases, and the top five models contain the same members.This comparison covers the nine models evaluated on both releases.
  • Cross-release comparison: 0.02 is the median absolute per-task nDCG@10 difference across releases, and no model changes by more than 0.08 on any single task.These figures apply to the nine models evaluated on both releases.
  • Cross-release comparison: Text-to-code scores are slightly higher on v202603 for most models, whereas code-to-text scores are slightly lower.The passage suggests these shifts likely reflect differences in the underlying problem distributions rather than systematization.

B.6 Subtask and Language Analysis · B.7 Per-Subtask and Per-Language Detailed Results · B.8 Full Parameter Efficiency Figure

The analysis shows that short developer-style queries and language-specific constraints sharply reduce text-to-code performance, while detailed breakdowns and efficiency figures extend the aggregate evaluation across subtasks, languages, and model sizes.

  • B.6 Subtask and Language Analysis: Figure 12 reports code-to-text nDCG@10 by subtask type on v202603.It provides a subtask-level view complementary to the text-to-code findings.
  • B.6 Subtask and Language Analysis: Near-zero nDCG@10 on short Search queries is two orders of magnitude below the Canonical subtask, despite sharing the same 1,744-item corpus.Search queries average 19 tokens, while Full queries contain 448 tokens and yield at most a marginal delta.
  • B.6 Subtask and Language Analysis: 0.714 nDCG@10 is achieved by language-agnostic queries, compared with 0.649 for Python, 0.514 for Java, 0.465 for C++, and 0.383–0.387 for Ruby and Go.These averages cover models and non-search subtasks; language-specific constraints reduce text-to-code performance.
  • B.6 Subtask and Language Analysis: The language-specific performance gap is partly confounded because “any” queries accept solutions in all five languages.The supplied analysis identifies this acceptance difference as a confound rather than attributing the entire gap solely to target-language constraints.
  • B.7 Per-Subtask and Per-Language Detailed Results: Table 15 reports code-to-code nDCG@10 stratified by anchor language, while Table 16 summarizes corpus composition and token-length statistics.These tables provide fine-grained per-subtask and per-language results that complement the aggregate main-text numbers.
  • B.8 Full Parameter Efficiency Figure: Figure 13 presents the complete three-panel parameter-efficiency analysis, adding per-task scatter and the full bar ranking to the main-text views.Figures 9 and 10 show only the Pareto-frontier scatter plot and top/bottom efficiency bars.

B.9 Anchor Exclusion in Code-to-Code Evaluation

Code-to-code evaluation must exclude each query’s byte-identical anchor, which otherwise trivially ranks first and distorts retrieval metrics. After exclusion, first-rank precision and recall reflect genuine cross-language retrieval performance.

  • Anchor exclusion: Every embedding model assigns the byte-identical anchor cosine similarity ≥0.99, placing it at rank 1 even though it is not a positive.The anchor is present in the shared retrieval corpus by construction.
  • Anchor exclusion: Removing the anchor before metric computation makes rank 1 correspond to each model’s best genuine retrieval candidate.This correction is applied to every code-to-code query.
  • Corrected results: After anchor exclusion, Jina-code-0.5b leads nDCG@1 at 0.378, followed by Jina-code-1.5b at 0.356 and GemEmb-2 at 0.331.C2LLM-7B reaches nDCG@1 = 0.327, while Qwen3-Emb-8B reaches nDCG@1 = 0.155.
  • Corrected results: GemEmb-2 reaches Recall@10 = 1.000, indicating that the corrected code-to-code recall curve reflects genuine cross-language retrieval behavior.The passage attributes the sharp Recall@k curve to evaluation after anchor exclusion.
  • Practical implication: Evaluation runners that retain the anchor systematically inflate Recall and waste nDCG@1 and MRR@1 on an irrelevant anchor hit.COREB provides a query id → anchor code id map for reproducing corrected metrics.

B.10 nDCG–Recall Divergence Across Tasks … B.13 Limitations

Across tasks, retrieval coverage can remain intact while ranking quality diverges, especially for text-to-code and code-to-code. The paper argues that CoIR’s structural flaws undermine evaluation reliability, while CoREB introduces graded, multi-relevant judgments but remains limited in scope and query realism.

  • B.10 nDCG–Recall Divergence Across Tasks: On text-to-code and code-to-code, models retrieve relevant items in the top ten but rank them lower, making ranking precision—not coverage—the primary bottleneck.Code-to-text nDCG@10 and Recall@10 track closely, unlike the larger gap on the other two tasks.
  • B.11 Extended Related Work: Code retrieval research spans general embedding benchmarks, code-specialized retrievers, and LLM-based coding assistants, but existing benchmarks cover few whole-code retrieval settings.The related work discusses BEIR, MTEB, IdBench, CodeBERT, GraphCodeBERT, and newer code-specialized retrieval models.
  • B.12 Structural Flaws in CoIR: CoIR’s ten datasets share structural problems that cast doubt on the reliability of model comparisons.The paper presents both universal and dataset-specific flaws across the benchmark collection.
  • B.12.1 Universal: Trivial 1-to-1 Qrels: All ten CoIR datasets use one binary-relevant document per query, making nDCG@k a function of rank alone, perfectly correlating nDCG with MRR and reducing Recall@k to 0 or 1.CoREB instead has multi-relevant qrels: 68% of text-to-code queries have 2–10 relevant documents, code-to-code averages 2.2 relevant translations, and v202602/v202603 contain 11,810/12,017 graded judgments.
  • B.12.2 CosQA: ∼51% Mislabeled Pairs: ∼37.5% of 80 manually reviewed CosQA pairs were clear mislabels, ∼22.5% were weak matches, and only ∼40% were reasonable, producing a high-variance 500-pair test split.The domain mismatch between Bing search logs and CodeSearchNet functions was independently associated with around 51% mismatching pairs by CoSQA+.
  • B.12.3 CodeSearchNet: Docstring Retrieval, Not Code Search: CodeSearchNet evaluates code paired with same-author docstrings rather than natural-language search questions, limiting its practicality for real code search.The cited critiques emphasize shared vocabulary and documentation-style queries.
  • B.12.4 CodeSearchNet-CCR: String Completion: CCR measures string continuation through leaked function titles, while CodeFeedback-MT enables near-deduplication from repeated prior code and has average queries of 4,558 characters.CCR splits functions at 40–70%; CodeFeedback-MT queries exceed most embedding models’ context windows.
  • B.12.6 Other Datasets: Other CoIR datasets contain artificial or low-quality retrieval signals, including LLM-generated coherence, verbatim DDL leakage, ∼0.15% code-containing StackOverflow queries, and 180–446-query CodeTransOcean test sets.The paper also notes non-code corpus items, Python-only APPS data without quality control, and related dataset-specific weaknesses; Table 17 summarizes the structural comparison between CoIR and CoREB.
Loading 2605.04615v2…