Pith. sign in

REVIEW 5 major objections 5 minor 21 references

Why Braking? Scenario Extraction and Reasoning Utilizing LLM

T0 review · 5 major / 5 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 converting vehicle bus signals into structured natural-language scenario descriptions lets an LLM classify the cause of braking events, outperforming a rule-based baseline on known categories and retrieving unseen…

desk verdict A useful LLM-based braking scenario extractor with a genuinely new overlap tag, but the KeyIdent filter silently drops gentle anticipatory braking, so the zero-shot OOD claim is narrower than the title suggests. read the letter →

arxiv 2507.15874 v1 pith:TTCY4NF2 submitted 2025-07-17 cs.AI cs.CL

Yin Wu , Daniel Slieter , Vivek Subramanian , Ahmed Abouelazm , Robin Bohn , J. Marius Zöllner This is my paper · ORCID
classification cs.AIcs.CL
keywords autonomousdrivingADASscenarioextractionlargelanguagemodelbrakingeventsscenario-basedvalidationout-of-distributionretrievalzero-shotgeneralization
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 answer a practical question for automated-driving validation: when a logged vehicle brakes, which surrounding object caused it, and what scenario does that interaction belong to? Its proposal is to convert low-level vehicle bus signals into compact natural-language descriptions of each ego-vehicle–object interaction and let a large language model rephrase, classify, and explain the event. The authors claim this beats a hand-tuned rule-based filter on four known scenario categories and, through embedding-based similarity search, retrieves three previously unseen categories in a zero-shot manner. That matters because braking events are abundant in real-world driving data but rule filters are brittle in urban settings, so a language-based pipeline could make corner-case mining more scalable and more flexible.

What carries the argument

The load-bearing mechanism is a two-stage translation. First, a rule-based module assigns activity tags (longitudinal, lateral, position, collision, distance) and a newly defined TrajOverlapTag, which aggregates future bounding boxes over 1.5 and 3 second windows to flag overlap risk. A KeyIdent step keeps only ego–object pairs where the ego is decelerating or stationary and the object carries LOW or HIGH collision or overlap risk. Those surviving pairs are compressed from timestamp tables into duration-based text segments, fed to the LLM with a role prompt and a fixed closed set of scenario categories plus an 'unknown but relevant' option; the LLM returns a rephrased description, a category, and an explanation. The rephrased description is embedded, and retrieval runs two paths: exact match on the LLM-assigned category, or cosine similarity against a free-form query.

What would settle it

Take the annotated right-ped and approach-stop logs from the authors' own dataset, filter them through the KeyIdent rule, and compute recall among those with gentle braking and no risk tags; if that recall is near zero, the zero-shot OOD claim holds only for risk-flagged events, not for the full set of annotated braking logs. A second check is to run retrieval with a query for a truly novel category (e.g., 'ego brakes for a cyclist swerving from behind a parked truck') and measure whether any correct matches appear in the top 50.

Watch

Extended reading notes

Core claim

The central claim is that an LLM, given structured text built from rule-based activity tags, can recover the cause of ego braking better than the rule-based filter alone. The paper reports overall F1 of 0.52 for the LLM pipeline versus 0.33 for the tuned rule baseline, with recall rising from 0.66 to 0.78 on the four known categories, and top-50 recall between 0.31 and 0.67 on three out-of-distribution categories found by embedding similarity. The authors also identify a boundary: because the KeyIdent filter only forwards objects that already show collision or trajectory-overlap risk while the ego decelerates or stands still, gentle anticipatory braking cases such as approaching a stopped vehicle or yielding to a pedestrian are often filtered out before the LLM sees them.

Load-bearing premise

The pipeline assumes that any object that causes the ego to brake will already show a detected collision or trajectory-overlap risk while the ego is decelerating or standing still, so objects that trigger only gentle anticipatory braking are excluded before the language model can examine them.

Editorial extensions

If this is right

  • Scenario catalogs for ADAS validation could be built by typing a natural-language description rather than tuning filter thresholds.
  • Unseen scenario types can be surfaced from raw logs without retraining, as long as their descriptions resemble the stored text embeddings.
  • The LLM's explanation field gives engineers a human-readable reason for each retrieved braking event, which rule-based tags do not provide.
  • The reported coverage is limited to braking with detected risk: anticipatory or gentle braking without a risk tag will be missed, so the method should be seen as a critical-braking miner, not a universal braking-cause oracle.

Reading between the lines

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

  • A natural next experiment is to relax the KeyIdent risk condition to include shrinking distance or predicted time-to-arrival, then measure whether right-ped and approach-stop recall rises without flooding the LLM with irrelevant objects.
  • The stored scenario embeddings could be clustered to discover a data-driven taxonomy of braking reasons, which the paper does not attempt.
  • Because the pipeline uses bus signals and object tracks rather than HD maps, it may transfer across cities or sensor configurations, but the paper does not test that transfer.
  • The top-10 precision of 0.30-0.40 on embedding retrieval suggests that in practice a human-in-the-loop review would be needed before the retrieved OOD scenarios are trusted for validation.
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

5 major / 5 minor

Summary. The paper proposes an LLM-based framework for extracting and reasoning about the causes of ego-vehicle braking events from BUS data. The pipeline first applies rule-based activity and interaction tagging (including a newly introduced TrajOverlapTag), then uses a KeyIdent module to filter candidate interacting objects, converts the selected ego-object pairs into structured natural-language descriptions, and asks an LLM to produce a rephrased description, a scenario category, and an explanation. A dual-path retrieval module supports both category-based search for known scenarios and embedding-based similarity search for out-of-distribution (OOD) scenarios. The authors curate 727 scenario annotations from 700 Argoverse 2 logs and report that their approach outperforms the rule-based baseline of Guo et al. [3] (overall F1 0.52 vs 0.33) and shows 'zero-shot generalization' on three OOD categories not present in the prompt.

Significance. If the claims hold, the paper makes a useful applied contribution: it shows how low-level time-series vehicle data can be converted into natural-language scenario descriptions that an LLM can classify and retrieve, without fine-tuning and without relying on HD maps. The dual-path retrieval design is sensible, and the introduction of TrajOverlapTag is a reasonable extension of risk tagging that uses actual future trajectories. The paper also contributes a curated scenario annotation set for Argoverse 2. The main claims are not circular in a derivation sense, and the OOD retrieval path is genuinely zero-shot in that no OOD labels are used in the prompt. However, the scope of the central claim is narrower than stated because the KeyIdent filter removes exactly the anticipatory-braking cases that the motivating question 'Why braking?' most naturally includes, and several evaluation details are missing. The paper is therefore of interest to the scenario-mining community, but the headline claims need revision and additional evidence.

major comments (5)
  1. [Section III-C and V-E] The KeyIdent gate defined in Section III-C admits only objects with LOW or HIGH CollisionTag or TrajOverlapTag while the ego is DECELERATING or STANDING STILL. The failure analysis in Section V-E and Figures 5b/5c explicitly states that approach-stop and right-pedestrian scenarios often involve only gentle, anticipatory braking with no detected collision or trajectory-overlap risk, so those objects are filtered out before the LLM sees them. Consequently, the scenario database and the OOD retrieval metrics in Table VI are computed on the filtered subset only, and Table IV does not report KeyIdent recall for approach-stop, lead-brake, or pedestrian-crossing categories. The abstract and conclusion therefore overstate the scope of the contribution: the reported gains apply to braking events whose cause is detectable by conventional collision or overlap risk, not to all braking events behind the motivating question 'Why braking?'. I ask the authors to quantify KeyIdent's coverage for the OOD categories and to qualify the generalization claim accordingly.
  2. [Section V-B] The baseline comparison is not fully specified. Section V-B states only that the baseline retrieval filter was 'carefully adjusted' to maximize its F1 score, without giving the exact thresholds, the search procedure, or the per-category tuning details. Since the baseline is a rule-based filter with many free thresholds, and since some categories have very few examples (e.g., 5 left-oppo annotations in Table III), the headline overall F1 improvement (0.52 vs 0.33) cannot be distinguished from test-set tuning or sampling noise. Please report the exact baseline rule set, the optimization criterion, and per-category counts, and add confidence intervals or a significance test over annotation or bootstrap samples.
  3. [Sections III-D and V-B] The in-distribution evaluation is a closed-set classification task in which the LLM prompt contains the same scenario-category names and definitions that the human annotators used to label the data, and Table V evaluates only four of the seven categories. This makes the ID result largely a test of label matching rather than of semantic scenario understanding. I recommend including 'unknown_but_relevant' and 'not_relevant' in the reported confusion matrix, holding out one or more categories from the prompt to test category-level generalization, or otherwise demonstrating that the LLM is not simply exploiting the provided definitions.
  4. [Section V-C] The OOD retrieval evaluation is under-specified. The query descriptions in Table VI are short natural-language statements that are very close to the names of the target categories, and the retrieved embeddings are computed from LLM-generated rephrased descriptions of the same logs. The paper does not state whether these query texts were excluded from any development process, nor does it compare the embedding-based retrieval path against a rule-based or TF-IDF baseline. Without such a comparison, the P@10 and R@50 values in Table VI do not by themselves support the claim of 'strong zero-shot generalization.' Please add a baseline for the retrieval path and a discussion of query-robustness.
  5. [Section IV-A] The evaluation relies entirely on the authors' curated annotations over 700 Argoverse 2 logs, but no annotation protocol, inter-annotator agreement measure, or label-quality statistics are reported. Inconsistent or subjective labels would directly affect all precision, recall, and F1 numbers in Tables IV-VI. Please add a short annotation-quality subsection, for example a second annotator on a random sample with Cohen's kappa or a similar agreement metric.
minor comments (5)
  1. [Figure 2] The figure contains the misspelled word 'Explaination'; it should be 'Explanation.'
  2. [Table V] The paper does not state whether the 'Overall' precision, recall, and F1 values are macro-averages or micro-averages over the four categories; please define the aggregation and, if macro, report the category weights or the per-category support.
  3. [Section IV-B] The deterministic sampling settings (temperature = 0, top_p = 1.0, top_k = 1) are reported for the best model, but it is not stated whether the same settings were applied to GPT-4.1 and Qwen3-32B; please clarify.
  4. [Abstract and Section I] The acronym 'BUS' is used without expansion; please spell out 'body control module / vehicle bus system' at first use and define what signals are meant.
  5. [Section V-C] Please state whether the embedding-based retrieval was evaluated only on the filtered subset produced by KeyIdent or on the full annotated set; this is closely related to the first major comment and should be made explicit in the table caption.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the LLM classification and zero-shot OOD retrieval are genuinely inferred from rule-based tags, and the KeyIdent coverage limitation is explicitly acknowledged rather than a by-construction reduction.

full rationale

The paper's derivation chain is self-contained. The pipeline converts BUS data into rule-based tags (following external work [3] plus a new TrajOverlapTag defined in Sec. III-B), filters candidate objects with the hand-coded KeyIdent rule (Sec. III-C), translates tag sequences into text descriptions (Sec. III-D), and asks an LLM to classify the scenario into categories provided in the prompt. No parameter is fitted to the evaluation data, no prediction is a renamed input, and the paper contains no self-citations at all: every load-bearing reference ([3], [4], [6]) is an external method, dataset, or benchmark. The ID evaluation is a closed-set classification task in which the prompt categories and the annotation taxonomy necessarily coincide; the LLM must nevertheless infer which category applies to each unseen tag sequence, so the result is not determined by construction. The OOD retrieval (Table VI) uses categories absent from the prompt (approach stop, lead brake, ped crossing) with free-text queries embedded by a frozen external model, so it is a genuine zero-shot transfer test. The nearest concern, that KeyIdent admits only objects with LOW/HIGH CollisionTag or TrajOverlapTag while the ego decelerates and thus excludes anticipatory-braking scenarios, is a coverage limitation that the paper itself acknowledges in Sec. V-E ('the proposed method ... remains limited in capturing softer or anticipatory braking cases'), not a circular reduction: within the admitted subset, the category and explanation are still inferred by the LLM, not read off the filter. Thus the central claims hold as empirical evaluations with a stated scope, and no circular step is exhibited.

Assumptions & free parameters 5 free parameters · 4 assumptions · 1 invented entities

The central empirical claim depends on a set of hand-chosen thresholds, a key-object filter, and the reliability of LLM outputs. No fitted constants or invented physical entities are introduced; the only new construct is the TrajOverlapTag rule. The main burden is that the rule-based tagging semantics are inherited from [3] without revalidation, the thresholds are hand-set, and the prompt categories and ground-truth labels come from the same team.

free parameters (5)
  • VEERING/TURNING angular thresholds = 0.05 rad and 0.17 rad
    Chosen by hand in Section IV.B to subdivide the LatitudeTag; changes would alter scenario descriptions and LLM classifications.
  • CollisionTag TTC thresholds = LOW risk 1.5-3 s, HIGH risk <1.5 s
    Adopted from [3] as implementation refinements; not derived from data in this paper, and key for KeyIdent filtering.
  • TrajOverlapTag time windows = HIGH at 1.5 s, LOW at 3.0 s
    Introduced in Section III.B as a new tag; the 1.5/3.0 s boundaries are hand-chosen and define which braking interactions are considered key.
  • DistanceTag thresholds = VERY CLOSE, CLOSE <10 m, MEDIUM 10-50 m, FAR >50 m
    Borrowed from [3] and listed in Section IV.B; they influence the textual scenario description.
  • KeyIdent risk requirement = ego DECEL/STANDING_STILL plus LOW/HIGH collision or trajectory-overlap
    A categorical filter chosen in Section III.C; it excludes anticipatory braking and directly determines recall.
assumptions (4)
  • domain assumption Rule-based tagging semantics from Guo et al. [3] transfer to Argoverse 2 without HD maps.
    The paper reuses LongitudeTag, LatitudeTag, CollisionTag, PositionTag, DistanceTag rules from [3], but does not reproduce or validate them on this dataset.
  • domain assumption Future ground-truth trajectories in the logs are valid causal evidence for braking.
    TrajOverlapTag uses actual future trajectories (Section III-B); this is only available in offline data, not at decision time, and assumes future trajectory overlap is a proxy for the reason the ego braked.
  • domain assumption LLM outputs at temperature 0 are deterministic enough for evaluation.
    The authors set temperature=0, top_p=1, top_k=1 (Section IV-B) and report single-run results without variance, so the reliability of this determinism is assumed.
  • ad hoc to paper The provided scenario category definitions match the semantics of the curated annotations.
    Both the prompt categories (Fig. 4d) and the ground-truth labels (Table III) were authored by the team; no inter-annotator agreement or external taxonomy is reported.
invented entities (1)
  • TrajOverlapTag
    purpose: New interaction tag that flags future temporal overlap of ego and guest bounding boxes, used by KeyIdent and the scenario description.
    Defined in Section III-B using a hand-selected 1.5/3.0 s window on ground-truth future trajectories; it is a pipeline-internal label, not an independently measured quantity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Why Braking? Scenario Extraction and Reasoning Utilizing LLM." pith.science (2026). https://pith.science/paper/TTCY4NF2

@misc{pith2026250715874,
  author       = {Pith},
  title        = {Pith review of: Why Braking? Scenario Extraction and Reasoning Utilizing LLM},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TTCY4NF2}},
  note         = {Machine review of arXiv:2507.15874}
}
read the original abstract

The growing number of ADAS-equipped vehicles has led to a dramatic increase in driving data, yet most of them capture routine driving behavior. Identifying and understanding safety-critical corner cases within this vast dataset remains a significant challenge. Braking events are particularly indicative of potentially hazardous situations, motivating the central question of our research: Why does a vehicle brake? Existing approaches primarily rely on rule-based heuristics to retrieve target scenarios using predefined condition filters. While effective in simple environments such as highways, these methods lack generalization in complex urban settings. In this paper, we propose a novel framework that leverages Large Language Model (LLM) for scenario understanding and reasoning. Our method bridges the gap between low-level numerical signals and natural language descriptions, enabling LLM to interpret and classify driving scenarios. We propose a dual-path scenario retrieval that supports both category-based search for known scenarios and embedding-based retrieval for unknown Out-of-Distribution (OOD) scenarios. To facilitate evaluation, we curate scenario annotations on the Argoverse 2 Sensor Dataset. Experimental results show that our method outperforms rule-based baselines and generalizes well to OOD scenarios.

Figures

Figures reproduced from arXiv: 2507.15874 by the authors.

Figure 1
Figure 1. Four representative scenarios where the black ego [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. The scenario tagging and retrieval framework consists of several stages. The preprocessed raw driving data is [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Comparison between CollisionTag (left) with Tra￾jOverlapTag (right). Red: ego vehicle; orange: guest vehicle; dash line: predicted / actual future trajectory. CTRV model and Time to Collision (TTC) estimation, our method directly leverages the ground-truth future trajecto￾ries recorded in the logs. For both the ego vehicle and a surrounding object, we aggregate all 2D bounding boxes over a future time interval to fo… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Building scenario description and prompt to LLM and an output example [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Visualization of failure cases in scenario extraction. Red: ego vehicle; orange: guest vehicle; grey: pedestrian; dashed [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 13 canonical work pages

  1. [3]

    Scenario extraction from a large real-world dataset for the assessment of automated vehicles,

    D. Guo, M. M. S ´anchez, E. de Gelder, and T. P. van der Sande, “Scenario extraction from a large real-world dataset for the assessment of automated vehicles,” in 2023 IEEE 26th International Conference on Intelligent Transportation Systems (ITSC) , 2023

    work page 2023

  2. [1]

    Krzanich

    B. Krzanich. (2016) Data is the new oil in the future of automated driving. Intel Newsroom

    work page 2016

  3. [2]

    Real-world scenario mining for the assessment of automated vehicles,

    E. De Gelder, J. Manders, C. Grappiolo, J.-P. Paardekooper, O. O. Den Camp, and B. De Schutter, “Real-world scenario mining for the assessment of automated vehicles,” in 2020 IEEE 23rd International Conference on Intelligent Transportation Systems (ITSC) , 2020

    work page 2020

  4. [4]

    Chat2scenario: Scenario extraction from dataset through utilization of large language model,

    Y . Zhao, W. Xiao, T. Mihalj, J. Hu, and A. Eichberger, “Chat2scenario: Scenario extraction from dataset through utilization of large language model,” in 2024 IEEE Intelligent Vehicles Symposium (IV) , 2024

    work page 2024

  5. [5]

    Refav: Towards planning- centric scenario mining,

    C. Davidson, D. Ramanan, and N. Peri, “Refav: Towards planning- centric scenario mining,” arXiv preprint arXiv:2505.20981 , 2025

    arXiv 2025

  6. [6]

    Argoverse 2: Next generation datasets for self-driving perception and forecasting,

    B. Wilson, W. Qi, T. Agarwal, J. Lambert, J. Singh, S. Khandelwal, B. Pan, R. Kumar, A. Hartnett, J. K. Pontes et al., “Argoverse 2: Next generation datasets for self-driving perception and forecasting,” arXiv preprint arXiv:2301.00493, 2023

    arXiv 2023

  7. [7]

    Driving to safety: How many miles of driving would it take to demonstrate autonomous vehicle reliability?

    N. Kalra and S. M. Paddock, “Driving to safety: How many miles of driving would it take to demonstrate autonomous vehicle reliability?” Transportation research part A: policy and practice , 2016

    work page 2016

  8. [8]

    6-layer model for a structured description and categorization of urban traffic and environment,

    M. Scholtes, L. Westhofen, L. R. Turner, K. Lotto, M. Schuldes, H. Weber, N. Wagener, C. Neurohr, M. H. Bollmann, F. K ¨ortke et al., “6-layer model for a structured description and categorization of urban traffic and environment,” iEEE Access, 2021

    work page 2021

Show all 21 references
  1. [9]

    Scenario based testing of automated driving systems: A literature survey,

    D. Nalic, T. Mihalj, M. B ¨aumler, M. Lehmann, A. Eichberger, and S. Bernsteiner, “Scenario based testing of automated driving systems: A literature survey,” in FISITA web Congress, 2020

    2020

  2. [10]

    1001 ways of scenario generation for testing of self-driving cars: A survey,

    B. Sch ¨utt, J. Ransiek, T. Braun, and E. Sax, “1001 ways of scenario generation for testing of self-driving cars: A survey,” in 2023 IEEE Intelligent Vehicles Symposium (IV) , 2023

    2023

  3. [11]

    Generat- ing useful accident-prone driving scenarios via a learned traffic prior,

    D. Rempe, J. Philion, L. J. Guibas, S. Fidler, and O. Litany, “Generat- ing useful accident-prone driving scenarios via a learned traffic prior,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2022, pp. 17 305–17 315

    2022

  4. [12]

    Drivelm: Driving with graph visual question answering,

    C. Sima, K. Renz, K. Chitta, L. Chen, H. Zhang, C. Xie, J. Beißwenger, P. Luo, A. Geiger, and H. Li, “Drivelm: Driving with graph visual question answering,” in European Conference on Computer Vision, 2024

    2024

  5. [13]

    Drivevlm: The convergence of au- tonomous driving and large vision-language models,

    X. Tian, J. Gu, B. Li, Y . Liu, Y . Wang, Z. Zhao, K. Zhan, P. Jia, X. Lang, and H. Zhao, “Drivevlm: The convergence of au- tonomous driving and large vision-language models,” arXiv preprint arXiv:2402.12289, 2024

    2024 arXiv

  6. [14]

    Chain-of-thought prompting elicits reasoning in large language models,

    J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V . Le, D. Zhou et al. , “Chain-of-thought prompting elicits reasoning in large language models,” Advances in neural information processing systems, 2022

    2022

  7. [15]

    Pre- train, prompt, and predict: A systematic survey of prompting methods in natural language processing,

    P. Liu, W. Yuan, J. Fu, Z. Jiang, H. Hayashi, and G. Neubig, “Pre- train, prompt, and predict: A systematic survey of prompting methods in natural language processing,” ACM computing surveys , 2023

    2023

  8. [16]

    What is a savitzky-golay filter?[lecture notes],

    R. W. Schafer, “What is a savitzky-golay filter?[lecture notes],” IEEE Signal processing magazine , vol. 28, no. 4, pp. 111–117, 2011

    2011

  9. [17]

    A survey of large language models,

    W. X. Zhao, K. Zhou, J. Li, T. Tang, X. Wang, Y . Hou, Y . Min, B. Zhang, J. Zhang, Z. Dong et al. , “A survey of large language models,” arXiv preprint arXiv:2303.18223 , 2023

    2023 arXiv

  10. [18]

    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

  11. [19]

    Gem- ini: a family of highly capable multimodal models,

    G. Team, R. Anil, S. Borgeaud, J.-B. Alayrac, J. Yu, R. Soricut, J. Schalkwyk, A. M. Dai, A. Hauth, K. Millican et al. , “Gem- ini: a family of highly capable multimodal models,” arXiv preprint arXiv:2312.11805, 2023

    2023 arXiv

  12. [20]

    Qwen3 technical report,

    A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lv et al. , “Qwen3 technical report,” arXiv preprint arXiv:2505.09388, 2025

    2025 arXiv

  13. [21]

    Nomic embed: Training a reproducible long context text embedder,

    Z. Nussbaum, J. X. Morris, B. Duderstadt, and A. Mulyar, “Nomic embed: Training a reproducible long context text embedder,” arXiv preprint arXiv:2402.01613, 2024

    2024 arXiv

Pith tools

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