Pith. sign in

REVIEW 4 major objections 4 minor 3 cited by

EdgeRAG: Online-Indexed RAG for Edge Devices

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

Pith's one-line read EdgeRAG runs memory-exceeding RAG indexes on edge devices.

desk verdict Useful engineering combination with a plausible central claim, but the reported numbers don't yet hang together. read the letter →

arxiv 2412.21023 v2 pith:CMQP2XMJ submitted 2024-12-30 cs.LG

classification cs.LG
keywords retrievalaugmentedgenerationedgedevicesvectorindexinvertedfileembeddingmemorypruningtime-to-first-tokenonlineindexing
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 retrieval-augmented generation system can run on an edge device even when the embedding database is several times larger than device memory, by converting most stored embeddings into on-demand computation. The proposed system, EdgeRAG, keeps only cluster centroids in memory, generates second-level embeddings during retrieval, precomputes embeddings for heavy-tail clusters whose generation would exceed a latency target, and caches frequently reused embeddings. On six BEIR datasets over an 8 GB edge platform, the paper reports 1.8x lower time-to-first-token on average and 3.82x for datasets that exceed memory, with recall and LLM generation scores within 5 percent of a Flat index full-scan baseline. The significance is that local personal-data RAG could fit on phones and similar devices without sacrificing response time or quality.

What carries the argument

The load-bearing mechanism is the two-level IVF index with pruned second level, plus two profiled decisions. During indexing, each cluster's generation latency is estimated as total chunk length divided by a fixed GenRate (Algorithm 1); clusters whose estimate exceeds the SLO have their embeddings stored, while others are regenerated on demand. A second mechanism, the adaptive Minimum Latency Caching Threshold (Algorithm 3), starts by caching everything and then raises or lowers the minimum generation cost required for a cluster's regenerated embeddings to be cached, using cache-hit feedback and a moving average of retrieval latency. Cache replacement uses a cost-aware LFU policy (Algorithm 2) that evicts the cluster minimizing generation latency times access count, with counters decayed over time. Together these mechanisms decide, per cluster, whether to store, generate, cache, or load embeddings at query time.

What would settle it

Measure actual embedding generation time against chunk length for the same embedding model on the target device; if per-cluster generation time does not track total chunk length divided by a fixed GenRate, then the Algorithm 1 threshold misclassifies tail clusters, and a query hitting a misclassified heavy cluster will exceed the SLO.

Watch

Extended reading notes

Core claim

EdgeRAG's central claim is that the memory bottleneck of RAG on edge devices can be broken by a hybrid of storage and generation rather than by compression alone. In an IVF index, only the first-level centroids need to be resident; second-level embeddings can be pruned and regenerated from text chunks at query time, since most clusters are never probed and generation is cheap for small clusters. EdgeRAG additionally identifies tail-heavy clusters, whose generation time would violate the SLO, and persists only those embeddings; a cost-aware cache stores regenerated embeddings for clusters whose generation cost exceeds an adaptive threshold. The paper evaluates this design on an 8 GB mobile-class platform and reports that all six BEIR datasets fit in memory, retrieval latency improves 1.8x on average and 3.82x for the three memory-exceeding datasets versus the IVF baseline, and recall and generation quality stay within 5 percent of the Flat index baseline.

Load-bearing premise

The system assumes a cluster's embedding generation time is proportional to its total chunk length divided by a constant rate, so the profiler can decide offline which clusters are too expensive to generate online; if that rate is not stable across datasets or chunk sizes, the precomputation decision selects the wrong clusters and tail latency can exceed the SLO.

Editorial extensions

If this is right

  • RAG over corpora whose raw embedding footprint exceeds device memory can run without disk thrashing, since only centroids and a sparse set of precomputed embeddings are resident.
  • Time-to-first-token drops 1.8x on average and 3.82x on memory-exceeding datasets versus the standard IVF index on the evaluated platform.
  • The 95th-percentile retrieval tail shrinks by more than 4x from pruning alone, and another 2x from preloading heavy clusters, removing the 64x median-to-tail gap of the IVF baseline.
  • Retrieval results are identical to the IVF index because the same centroids and search path are used; recall and GPT-4o generation-quality scores stay within 5 percent of the Flat index.
  • The cache uses only about 7 percent additional system memory on top of the pruned index, which remains within the device's memory budget.

Reading between the lines

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

  • A natural extension: replace the fixed GenRate estimate with per-cluster measured generation cost; if generation time is nonlinear in chunk length, the offline precomputation decision should use measured cost curves rather than a linear divisor.
  • The adaptive caching threshold reacts only to hit/miss and moving-average latency; a frequency-aware or query-stream-aware policy could push hit rates higher on workloads with skewed access, potentially improving the reported numbers further.
  • If an NPU offloads embedding generation, the crossover point between generating and loading embeddings shifts, so the SLO threshold for precomputing clusters would move and online generation could be viable for larger clusters than the current GPU-bound measurements show.
  • The paper's idea of treating embedding storage as a latency-versus-memory trade-off could apply beyond RAG, for example to any vector-search workload with compute-cheap-to-regenerate features, but that application is not evaluated here.
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

4 major / 4 minor

Summary. The paper proposes EdgeRAG, a two-level IVF-based retrieval index for edge devices that reduces memory footprint by pruning most second-level embeddings, generating embeddings online during retrieval, precomputing and storing embeddings for clusters whose estimated generation latency exceeds an SLO, and adaptively caching generated embeddings with a cost-aware LFU policy. The system is evaluated on an 8 GB Nvidia Jetson Orin Nano with six BEIR datasets, comparing Flat, standard IVF, IVF with online generation, IVF with generation plus heavy-cluster loading, and the full EdgeRAG configuration. The headline claims are 1.8x faster TTFT on average and 3.82x for larger datasets compared with the IVF baseline, generation quality within 5 percent of the Flat index, and that all evaluated datasets fit in device memory.

Significance. If the central claims hold, EdgeRAG addresses a real bottleneck for on-device RAG: fitting vector databases whose raw embedding footprint exceeds edge-device memory while keeping time-to-first-token acceptable. The paper has genuine strengths: it evaluates on six BEIR workloads, including three datasets whose original embedding sizes exceed the 8 GB platform memory, and it uses a structured ablation (Flat, IVF, online generation, heavy-cluster loading, caching) that isolates the effect of each optimization. Retrieval recall is normalized against the Flat baseline and generation quality is judged by an LLM evaluator. However, the central quantitative claims are not yet established: the speedup numbers are internally inconsistent across sections, the memory-fit claim is not supported by measured EdgeRAG memory footprints, and the key latency estimate in Algorithm 1 relies on an unvalidated fixed GenRate constant. These issues are fixable but require re-reporting or additional experiments.

major comments (4)
  1. [Section 1, Section 6.3.4, Section 8] The headline speedup claim is inconsistent across the manuscript. Section 1 states EdgeRAG offers 1.8x faster TTFT on average and 3.82x for larger datasets; Section 6.3.4 states 'overall retrieval latency 1.8x on average'; Section 8 states 'improves retrieval latency by 1.22x on average and by a substantial 3.69x for large datasets'; and the third contribution bullet reports a 131% improvement for large datasets. TTFT and retrieval latency are different metrics, and 1.8x, 1.22x, and 2.31x are different magnitudes. No per-dataset latency table is provided to reconcile these numbers. Please define the metric precisely and report per-dataset values for all configurations.
  2. [Table 2 and Section 6.2] The claim that all evaluated datasets fit in memory is not supported by measured memory footprints. Table 2 lists original embedding sizes and a qualitative 'Fit in Dev. Mem' column, but the manuscript never reports EdgeRAG's actual peak memory usage, which must account for the first-level centroids, stored second-level embeddings, the embedding cache, the text corpus, and the generation model. For nq, hotpotqa, and fever the original embeddings exceed 8 GB, so the memory-fit claim depends on exactly how many embeddings are pruned, stored, and cached; without measured footprints the central memory-fit claim is unverifiable.
  3. [Algorithm 1 (Section 4.1)] The decision to precompute a cluster's embeddings depends entirely on Centroid.GenLatency = SUM(len(Centroid.Datachunks))/GenRate, but GenRate is treated as a fixed constant without validation. Figure 4 plots generation rate against cluster size but does not establish that the linear model holds across clusters, datasets, or different chunk-size distributions, nor does the paper report the prediction error or the resulting SLO-violation rate. Because this estimate determines which clusters are precomputed, an inaccurate estimate would leave tail-heavy clusters to be generated online and directly undermine the latency claims.
  4. [Section 6.3.4 and Figure 12] The latency evaluation reports no error bars, confidence intervals, or repeated-run statistics. Given that the reported average speedup ranges from 1.22x to 1.8x depending on the section, run-to-run variability on the Jetson platform could change the ranking of configurations, especially for the smaller datasets where the differences are likely smaller. The tail-latency distribution is shown only for nq. Please report variance over multiple repetitions or justify why single measurements are sufficient for the paper's conclusions.
minor comments (4)
  1. [Algorithm 2] In Algorithm 2, the eviction condition compares 'cluster.genLatency × cluster.counter < maxCost' and then assigns to 'minCost'; this appears to be a typo for comparing against and updating 'minCost'.
  2. [Section 4.1 and Section 3.2] The term GenRate is not formally defined with units, and the text alternates between 'characters' and 'tokens' when describing cluster size; please define the unit and use it consistently.
  3. [Section 6.3.4] The statement that caching 'utilizes an additional 7% of system memory' is not accompanied by cache-capacity settings or per-dataset cache sizes; please report these values so the memory trade-off is reproducible.
  4. [Section 6.3.3] The text says the 95th percentile of IVF latency exceeds the median by over 64x, but no exact values are given in the text; adding the measured median and 95th percentile values would make this comparison concrete.

Circularity Check

1 steps flagged · score 4.0 of 10

One quality metric (recall within 5% of Flat) is enforced by per-dataset hyperparameter tuning; the central latency comparison remains independent.

  1. fitted input called prediction [Section 6.2 (Methodology) and Section 1 (Introduction)]
    "we optimize the retrieval hyperparameters, specifically the number of cluster probes and retrieved data chunks. This optimization is aimed at normalizing the recall metric to match that of the flat index baseline (Chen et al., 2024). [...] EdgeRAG maintains a similar generation quality with recall and generation scores within 5 percent of the Flat Index baseline."

    The recall part of the reported quality result is chosen, not measured: the number of probes and retrieved chunks are tuned per dataset specifically to make recall match the Flat baseline. Reporting that recall is within 5 percent of Flat is therefore a restatement of the tuning target rather than an independent outcome of EdgeRAG. The generation scores come from a separate GPT-4o evaluation and the latency claims are not affected by this tuning, so the circularity is limited to the recall claim.

full rationale

EdgeRAG is an empirical systems paper rather than a derivation, so most of its claims are benchmark outcomes rather than theorem-like consequences of its inputs. The central latency contribution (pruning second-level embeddings, precomputing tail clusters, and cost-aware caching) is evaluated against Flat and IVF baselines and does not reduce by construction to any fitted parameter. The main circular element is the recall-quality claim: Section 6.2 states that retrieval hyperparameters are optimized to normalize recall against Flat, and Section 1 then presents recall within 5 percent of Flat as a result. That particular claim is enforced by the tuning procedure. I do not treat the chosen SLO threshold, the linear GenRate estimate, or the use of BEIR both for motivation and evaluation as circularity, because none of these makes a reported number equal to an input by construction. The inconsistent speedup figures (1.8x/3.82x TTFT, 1.8x retrieval latency, 1.22x/3.69x retrieval latency, 131%) are a reporting/verifiability problem, not a circular-derivation problem, so they do not raise the circularity score further.

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

The central latency claims depend on several unspecified constants and on the assumption that profiling on these six BEIR datasets transfers to other corpora. The evaluation also tunes IVF hyperparameters and SLO thresholds in-sample. This ledger makes explicit what is pulled from the authors' choices rather than from prior literature.

free parameters (7)
  • Retrieval SLO threshold = 1 s for scidocs/fiqa/quora, 1.5 s for nq/hotpotqa/fever
    Determines which clusters are precomputed in Algorithm 1; chosen by the authors per dataset, not derived.
  • IVF nprobe and top-k = Not reported
    Tuned per dataset to normalize recall against the Flat baseline (Section 6.2).
  • IVF cluster count (nlist) = Not reported
    Set during FAISS k-means clustering; affects the granularity of pruning and is not stated.
  • Minimum Latency Caching Threshold = Adaptive, initialized to 0, step size unspecified
    Controls which cluster embeddings are cached in Algorithm 3; the increment and decrement amounts are not specified.
  • decayFactor for LFU counters = Not reported
    Used in Algorithm 2 to decay access counters; the value is not given.
  • alpha for moving average = Not reported
    Used in Algorithm 3 to update the moving average latency; the value is not given.
  • GenRate (embedding generation rate) = Not reported
    Used in Algorithm 1 to estimate cluster generation latency from chunk length; no measurement or constant is provided.
assumptions (3)
  • domain assumption Two-level IVF recall can be matched to Flat index recall by tuning nprobe and top-k.
    Section 6.2 states that hyperparameters are optimized to normalize recall against Flat. If this normalization is incomplete, the quality comparison is unfair.
  • ad hoc to paper Cluster embedding generation latency is predictable from total chunk length using a fixed GenRate.
    Algorithm 1 computes Centroid.GenLatency = SUM(len(Centroid.Datachunks))/GenRate. No evidence is given that a single GenRate is stable across chunk sizes and datasets.
  • domain assumption GPT-4o as an LLM judge produces valid generation quality scores.
    Section 6.3.2 uses GPT-4o as an automated evaluator, which is a proxy for human judgment and is treated as ground truth without calibration.

how reviews work

0 comments
Cite this review

Pith. "Pith review of EdgeRAG: Online-Indexed RAG for Edge Devices." pith.science (2026). https://pith.science/paper/CMQP2XMJ

@misc{pith2026241221023,
  author       = {Pith},
  title        = {Pith review of: EdgeRAG: Online-Indexed RAG for Edge Devices},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CMQP2XMJ}},
  note         = {Machine review of arXiv:2412.21023}
}
read the original abstract

Deploying Retrieval Augmented Generation (RAG) on resource-constrained edge devices is challenging due to limited memory and processing power. In this work, we propose EdgeRAG which addresses the memory constraint by pruning embeddings within clusters and generating embeddings on-demand during retrieval. To avoid the latency of generating embeddings for large tail clusters, EdgeRAG pre-computes and stores embeddings for these clusters, while adaptively caching remaining embeddings to minimize redundant computations and further optimize latency. The result from BEIR suite shows that EdgeRAG offers significant latency reduction over the baseline IVF index, but with similar generation quality while allowing all of our evaluated datasets to fit into the memory.

Figures

Figures reproduced from arXiv: 2412.21023 by the authors.

Figure 1
Figure 1. RAG Pipelines. 2.2. Index Similarity Search As mentioned in the previous section, RAG searches for the embedding representation of the data chunk in the database with the closest distance to the query embeddings. However, 2 [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Retrieval process of Inverted File Index embeddings often reside in high-dimensional spaces. Tech￾niques like sorting, which are efficient in low-dimensional spaces, become less effective or even infeasible in high￾dimensional spaces. Consequently, finding similar embed￾dings in high-dimensional spaces requires computationally expensive operations. Distance metrics such as Euclidean distance or cosine similarity inv… view at source ↗
Figure 3
Figure 3. presents the latency breakdown of the RAG system on an edge platform. End-to-end latency is categorized into three phases: 1) Retrieval latency, the duration of vector similarity search to identify relevant text chunks; 2) First [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Embedding Generation Rate of different cluster size 4. High-level Ideas We present EdgeRAG, a memory-efficient RAG system by selectively pruning second-level embeddings. Upon re￾ceiving an incoming query, EdgeRAG generates related second-level embeddings during runtime…
Figure 6
Figure 6. Figure 6: Timing breakdown of EdgeRAG Retrieval Process. dings of smaller, more common clusters. An analysis of queries across various datasets revealed a substantial degree of overlap in the accessed clusters. This overlap is quanti￾fied in [PITH_FULL_IMAGE:figures/full_fig_p0…
Figure 7
Figure 7. Figure 7: Retrieval Latency and Cache Hit rate with different Min￾imum Caching Threshold of fever dataset. 5. EdgeRAG System 5.1. Overview EdgeRAG index is a two-level indexing system that exploits memory efficiency and online computation. EdgeRAG in￾dex is based on the traditio…
Figure 9
Figure 9. Figure 9: shows EdgeRAG retrieval process. EdgeRAG first identifies the most similar centroid cluster to the query embedding (Step 1 ). It then checks if pre-computed em￾beddings exist for this cluster (Step 2 ). If so, EdgeRAG searches for stored embeddings (Step 3 ) and these …
Figure 10
Figure 10. Figure 10: BEIR Evaluation Scores [PITH_FULL_IMAGE:figures/full_fig_p007_10.png]
Figure 11
Figure 11. Figure 11: LLM Generation Evaluation Scores. chunks, leading to a decrease in precision. 6.3.2. GENERATION QUALITY EVALUATION As mentioned in the previous section, IVF-based EdgeRAG exploits a precision-latency trade-off, prioritizing recall over precision. To investigate the po…
Figure 12
Figure 12. Figure 12: Retrieval Latency distribution with different optimiza￾tion. 7 [PITH_FULL_IMAGE:figures/full_fig_p007_12.png]
Figure 13
Figure 13. Figure 13: Retrieval and First Token Latency. dataset. The baseline IVF index, while achieving low la￾tency for most queries, exhibits an extreme long tail latency, with the 95th percentile exceeding the median by over 64×. This behavior stems from memory thrashing when accessin…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

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

  1. WebANNS: Fast and Efficient Approximate Nearest Neighbor Search in Web Browsers

    cs.IR 2025-07 conditional novelty 5.0 of 10

    A new browser-native ANNS engine uses WebAssembly, lazy loading, and a memory optimizer to cut P99 query latency by up to 743.8x and memory use by up to 39% compared to Mememo.

  2. CaGR-RAG: Context-aware Query Grouping for Disk-based Vector Search in RAG Systems

    cs.DC 2025-05 conditional novelty 5.0 of 10

    CaGR-RAG reorders RAG queries into groups with overlapping cluster accesses and prefetches next-group clusters, improving cache hits and cutting p99 latency by up to 51.55% in disk-based IVF search.

  3. MobileRAG: A Fast, Memory-Efficient, and Energy-Efficient Method for On-Device RAG

    cs.DB 2025-07 conditional novelty 4.0 of 10

    A fully on-device RAG pipeline using a partitioned, partially disk-loaded graph index and selective sentence-window reduction claims 1.72-8.89x faster vector search and up to 40.2% lower power than baselines, with com...

Reference graph

Works this paper leans on

33 extracted references · 18 canonical work pages · cited by 3 Pith papers

  1. [1]

    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 global.max substring 't := if while FUNCTION format.date year duplicate empty "emp...

  2. [2]

    URL https://support.apple.com/en-us/121029

  3. [3]

    URL https://www.oneplus.com/us/launch/13

  4. [4]

    URL https://www.samsung.com/ae/support/mobile-devices/what-are-the-s24-external-memory-limits-and-memory-sizes-of-different-s24-variants/

    Jan 2024. URL https://www.samsung.com/ae/support/mobile-devices/what-are-the-s24-external-memory-limits-and-memory-sizes-of-different-s24-variants/

  5. [5]

    Y., Rajbhandari, S., Awan, A

    Aminabadi, R. Y., Rajbhandari, S., Awan, A. A., Li, C., Li, D., Zheng, E., Ruwase, O., Smith, S., Zhang, M., Rasley, J., et al. Deepspeed-inference: enabling efficient inference of transformer models at unprecedented scale. In SC22: International Conference for High Performance Computing, Networking, Storage and Analysis, pp.\ 1--15. IEEE, 2022

  6. [6]

    Ms marco web search: a large-scale information-rich web dataset with millions of real click labels

    Chen, Q., Geng, X., Rosset, C., Buractaon, C., Lu, J., Shen, T., Zhou, K., Xiong, C., Gong, Y., Bennett, P., et al. Ms marco web search: a large-scale information-rich web dataset with millions of real click labels. In Companion Proceedings of the ACM on Web Conference 2024, pp.\ 292--301, 2024

  7. [7]

    Chen, W., Hu, H., Chen, X., Verga, P., and Cohen, W. W. Murag: Multimodal retrieval-augmented generator for open question answering over images and text. arXiv preprint arXiv:2210.02928, 2022

  8. [8]

    Cohan, A., Feldman, S., Beltagy, I., Downey, D., and Weld, D. S. Specter: Document-level representation learning using citation-informed transformers. In ACL, 2020

Show all 33 references
  1. [9]

    The faiss library

    Douze, M., Guzhva, A., Deng, C., Johnson, J., Szilvasy, G., Mazaré, P.-E., Lomeli, M., Hosseini, L., and Jégou, H. The faiss library. 2024

  2. [10]

    Nanollm: Optimized local inference for llms

    Franklin, D. Nanollm: Optimized local inference for llms. URL https://github.com/dusty-nv/NanoLLM

  3. [11]

    Google assistant, 2024

    Google. Google assistant, 2024. URL https://assistant.google.com/

  4. [12]

    Google tensor is a milestone for machine learning

    Gupta, M. Google tensor is a milestone for machine learning. Google, October 2021. URL https://blog.google/products/pixel/introducing-google-tensor/

  5. [13]

    K., Masouros, D., Xydis, S., and Soudris, D

    Kakolyris, A. K., Masouros, D., Xydis, S., and Soudris, D. Slo-aware gpu dvfs for energy-efficient llm inference serving. IEEE Computer Architecture Letters, 2024

  6. [14]

    M., Uszkoreit, J., Le, Q., and Petrov, S

    Kwiatkowski, T., Palomaki, J., Redfield, O., Collins, M., Parikh, A., Alberti, C., Epstein, D., Polosukhin, I., Devlin, J., Lee, K., Toutanova, K., Jones, L., Kelcey, M., Chang, M.-W., Dai, A. M., Uszkoreit, J., Le, Q., and Petrov, S. Natural questions: A benchmark for questio...

  7. [15]

    u ttler, H., Lewis, M., Yih, W.-t., Rockt \

    Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., K \"u ttler, H., Lewis, M., Yih, W.-t., Rockt \"a schel, T., et al. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in Neural Information Processing Systems, 33: 0 9459--9474, 2020

  8. [16]

    Towards general text embeddings with multi-stage contrastive learning, 2023

    Li, Z., Zhang, X., Zhang, Y., Long, D., Xie, P., and Zhang, M. Towards general text embeddings with multi-stage contrastive learning, 2023. URL https://arxiv.org/abs/2308.03281

  9. [17]

    and Byrne, B

    Lin, W. and Byrne, B. Retrieval augmented visual question answering with outside knowledge. arXiv preprint arXiv:2210.03809, 2022

  10. [18]

    LlamaIndex , 11 2022

    Liu, J. LlamaIndex , 11 2022. URL https://github.com/jerryjliu/llama_index

  11. [19]

    Www'18 open challenge: Financial opinion mining and question answering

    Maia, M., Handschuh, S., Freitas, A., Davis, B., McDermott, R., Zarrouk, M., and Balahur, A. Www'18 open challenge: Financial opinion mining and question answering. In Companion Proceedings of the The Web Conference 2018, WWW '18, pp.\ 1941–1942, Republic and Canton of Geneva,...

  12. [20]

    Microsoft Copilot : Your AI companion

    Microsoft. Microsoft Copilot : Your AI companion. URL https://copilot.microsoft.com/

  13. [21]

    URL https://images.nvidia.com/content/Solutions/data-center/vgpu-L40-datasheet.pdf

    Nvidia. URL https://images.nvidia.com/content/Solutions/data-center/vgpu-L40-datasheet.pdf

  14. [22]

    NVIDIA Jetson Orin

    NVIDIA. NVIDIA Jetson Orin . URL https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/

  15. [23]

    URL https://openai.com/index/hello-gpt-4o/

    OpenAI. URL https://openai.com/index/hello-gpt-4o/

  16. [24]

    URL https://quoradata.quora.com/First-Quora-Dataset-Release-Question-Pairs

    Quora. URL https://quoradata.quora.com/First-Quora-Dataset-Release-Question-Pairs

  17. [25]

    Ares: An automated evaluation framework for retrieval-augmented generation systems

    Saad-Falcon, J., Khattab, O., Potts, C., and Zaharia, M. Ares: An automated evaluation framework for retrieval-augmented generation systems. arXiv preprint arXiv:2311.09476, 2023

  18. [26]

    Video google: a text retrieval approach to object matching in videos

    Sivic and Zisserman. Video google: a text retrieval approach to object matching in videos. In Proceedings Ninth IEEE International Conference on Computer Vision, pp.\ 1470--1477 vol.2, 2003. doi:10.1109/ICCV.2003.1238663

  19. [27]

    BEIR : A heterogeneous benchmark for zero-shot evaluation of information retrieval models

    Thakur, N., Reimers, N., R \"u ckl \'e , A., Srivastava, A., and Gurevych, I. BEIR : A heterogeneous benchmark for zero-shot evaluation of information retrieval models. In Thirty-fifth Conference on Neural Information Processing Systems Datasets and Benchmarks Track (Round 2),...

  20. [28]

    FEVER : a large-scale dataset for fact extraction and VER ification

    Thorne, J., Vlachos, A., Christodoulopoulos, C., and Mittal, A. FEVER : a large-scale dataset for fact extraction and VER ification. In Walker, M., Ji, H., and Stent, A. (eds.), Proceedings of the 2018 Conference of the North A merican Chapter of the Association for Computatio...

  21. [29]

    More modular than ever before: Iphone 16 pro and pro max teardown, Sep 2024

    Wiens, K. More modular than ever before: Iphone 16 pro and pro max teardown, Sep 2024. URL https://www.ifixit.com/News/100693/more-modular-than-ever-before-iphone-16-pro-and-pro-max-teardown

  22. [30]

    Sheared llama: Accelerating language model pre-training via structured pruning

    Xia, M., Gao, T., Zeng, Z., and Chen, D. Sheared llama: Accelerating language model pre-training via structured pruning. arXiv preprint arXiv:2310.06694, 2023

  23. [31]

    Yang, Z., Qi, P., Zhang, S., Bengio, Y., Cohen, W., Salakhutdinov, R., and Manning, C. D. H otpot QA : A dataset for diverse, explainable multi-hop question answering. In Riloff, E., Chiang, D., Hockenmaier, J., and Tsujii, J. (eds.), Proceedings of the 2018 Conference on Empi...

  24. [32]

    4" FUNCTION default.is.dash.repeated.names #0 FUNCTION default.name.format.string

    11em plus .33em minus .07em 4000 4000 100 4000 4000 500 `\.=1000 = #1 \@IEEEnotcompsoconly \@IEEEcompsoconly #1 * [1] 0pt [0pt][0pt] #1 * [1] 0pt [0pt][0pt] #1 * \| ** #1 \@IEEEauthorblockNstyle \@IEEEcompsocnotconfonly \@IEEEauthorblockAstyle \@IEEEcompsocnotconfonly \@IEEEco...

  25. [33]

    write newline

    " write newline "" initialize.prev.this.status FUNCTION begin.bib " write newline preamble empty 'skip preamble write newline if " thebibliography " longest.label * " " * write newline " [1] #1 " write newline " url@samestyle " write newline " " write newline " [2] #2 " write ...

Pith tools

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