Pith. sign in

REVIEW 3 major objections 5 minor 48 references

Toward Understanding Bugs in Vector Database Management Systems

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

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

Pith's one-line read This paper argues that software defects in vector database management systems cluster in the query layer, with 57.3 percent of bugs surfacing as functional failures, based on manual classification of 1,671 bug-fix pull requests.

desk verdict Solid first taxonomy of VDBMS bugs, but the headline prevalence numbers rest on two reverse-chronological convenience samples that make up half the dataset. read the letter →

arxiv 2506.02617 v1 pith:V6E3V32O submitted 2025-06-03 cs.SE

Yinglin Xie , Xinyi Hou , Yanjie Zhao , Shenao Wang , Kai Chen , Haoyu Wang This is my paper
classification cs.SE
keywords vectordatabasemanagementsystemssoftwaredefectsbugtaxonomyrootcauseanalysisapproximatenearestneighborretrieval-augmentedgenerationempiricalengineeringfixstrategies
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

Vector database management systems power semantic search and retrieval-augmented generation, yet the paper argues their reliability has not been studied at scale. It aims to establish the first broad empirical map of VDBMS defects, built by manually classifying 1,671 bug-fix pull requests from 15 open-source systems into a taxonomy of symptoms, root causes, and fix strategies. The central result is a prevalence profile: 57.3 percent of bugs surface as functional failures, 48.6 percent sit in the query layer, and missing exception handling plus parameter misconfiguration dominate the root causes. If the profile holds, it would tell developers and testers to concentrate on query logic, boundary conditions, and configuration validation rather than importing traditional database testing assumptions.

What carries the argument

The load-bearing artifact is a three-axis bug taxonomy: symptoms, root causes, and fix strategies, grounded in a decomposition of VDBMS architecture into query, index, storage, parsing and interaction, and configuration layers. The symptom and fix-strategy axes adapt categories from earlier defect studies, while the root-cause hierarchy was built inductively: a 150-pull-request pilot was refined through iterative discussion, expanded and later consolidated to 31 leaf-level causes, with two independent annotators and a third arbitrator reaching an inter-rater agreement above 0.95. The taxonomy carries the argument because every prevalence number in the paper is a count of annotations inside this hierarchy.

What would settle it

Take the full merged-pull-request history of Milvus and Vespa, apply the same taxonomy, and compare the symptom and root-cause distributions with the sampled months; a shift of more than about ten percentage points in functional failures or query-layer bugs would show the reported global distributions are an artifact of the sampling window.

Watch

Extended reading notes

Core claim

The paper claims that real-world VDBMS bugs follow a stable, classifiable pattern that is distinct from traditional database bugs. From 1,463 confirmed bugs it derives five symptom categories, 31 leaf-level root causes organized into five architectural areas (query, storage, index, parsing and interaction, configuration), and 12 fix strategies. Its headline findings are that functional failures account for 57.3 percent of symptoms, the query layer for 48.6 percent of root causes, and configuration for 26.5 percent, with query algorithm logic issues and missing exception handling as the most common recurring faults. The paper further claims that bug profiles track architecture: systems with richer query engines accumulate query-layer bugs, while systems with custom storage backends accumulate storage bugs. The intended takeaway is that this taxonomy and its distributions give VDBMS developers and researchers a reliable picture of where defects concentrate and what repairs actually look like.

Load-bearing premise

The assumption that the most recent months of merged pull requests from Milvus and Vespa stand in for all bugs those systems have ever had, even though those two samples provide about half of the confirmed bugs.

Editorial extensions

If this is right

  • VDBMS testing effort should shift toward query algorithm logic, especially missing exception handling and parameter validation, since these are the largest root-cause groups.
  • Test suites should include abnormal inputs such as NaN values, empty vectors, null IDs, and out-of-bound vectors, plus concurrency scenarios, because the paper finds these trigger crashes and functional failures.
  • Configuration handling deserves first-class validation, with startup checks and machine-readable configuration, given that 26.5 percent of bugs trace to configuration issues.
  • Because functional failures dominate and are hard to catch with standard unit tests, domain-specific verification and fuzzing for vector quantization, indexing, and similarity computation are the natural next tools.
  • Architecture choices predict bug profiles, so reliability reviews should target the parts of a system that deviate from standard infrastructure, such as custom storage or custom query planners.

Reading between the lines

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

  • The reverse-chronological sampling window for Milvus and Vespa is narrow, so the reported global percentages may understate long-term or historical bug patterns; re-running the study on full PR histories would test this directly.
  • The taxonomy could be turned into a VDBMS-specific bug-injection benchmark, for example mutating vector dimensionalities, index update timing, filter syntax, and configuration defaults to see which produce the documented failure modes.
  • The prominence of configuration and integration bugs in Python-based and extended systems hints that language and deployment model shape defect profiles, but the paper does not isolate those factors from system age or scope; a controlled comparison across matched systems would be needed.
  • The distinction between mostly-vector and mostly-mixed systems suggests that hybrid query support is a growing fault surface that traditional database test generators do not target.
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

3 major / 5 minor

Summary. The paper presents an empirical study of software defects in vector database management systems (VDBMSs). The authors collect 1,671 bug-fix pull requests from 15 open-source VDBMSs, manually label them, and construct a taxonomy with 5 symptom categories, 31 leaf-level root causes under 5 top-level aspects, and 12 fix strategies. They report prevalence distributions (e.g., 57.3% functional failures, 48.6% query-layer bugs, 26.5% configuration bugs) and cross-system comparisons, and they distill 10 insights for developers, architects, and researchers. The dataset is released on Figshare.

Significance. If the prevalence estimates are reliable, this is a valuable and timely contribution: it is the first large-scale study of VDBMS defects, providing a structured taxonomy and a public labeled dataset. The annotation process is described with care, including a pilot with Cohen's kappa above 0.95, and the taxonomy is grounded in concrete PR examples. The insights on query-logic bugs, configuration failures, and fix strategies are actionable for testing and tool development. The main weakness is that the aggregate distributions are dominated by two recent time-window samples, so the representativeness of the headline percentages is not established.

major comments (3)
  1. [§III-A2, Table I, Figures 3–4] The aggregate prevalence estimates are dominated by two reverse-chronological convenience samples. Milvus (363 bugs) and Vespa (348 bugs) together account for 711 of the 1,463 confirmed bugs (48.6%), yet their PRs were selected from a five-month window (August–December 2024) and a one-month window (December 2024), respectively, rather than sampled uniformly or stratified over project history. The paper states without support (end of §III-A2) that this yields a "comprehensive and representative dataset". Because the headline claims (57.3% functional failures, 48.6% Query, 26.5% Configuration) are computed from this pooled mixture, a time-dependent shift in these two projects—e.g., recent churn in configuration or deployment issues—would directly alter every aggregate percentage in Figures 3 and 4 and the RQ4 comparison in Table III. Please provide a sensitivity analysis (e.g., compare with another time window, reweight, or report results excluding Milvus/Vespa), or add confidence intervals and explicitly reframe the aggregate numbers as descriptive of the sampled PR window rather than of VDBMSs in general.
  2. [§V-A, Table III] The cross-system comparisons rely on percentages computed from very small samples for several systems, making the qualitative claims in RQ4 statistically fragile. For example, Faiss has 9 confirmed bugs, Annoy 1, txtai 5, Hnswlib 6, and Voyager 17; a single re-labeled PR changes the reported percentage by more than 10 points. The claim that "Qdrant is a notable outlier, with 40.7% of its bugs located in the storage layer" is based on 27 bugs (11 storage bugs), with no uncertainty estimate. Please report raw counts alongside percentages and either add confidence intervals or restrain the cross-system interpretation to systems with sufficient sample sizes.
  3. [§III-A1, Table I] The stated selection criterion—"included only those with over 14,000 stars as of November 29, 2024"—is contradicted by Table I, which lists eight systems with fewer stars (e.g., Vespa 6.1k, LanceDB 6.1k, Marqo 4.8k, pgvecto.rs 2.0k, Voyager 1.4k). Please clarify the actual inclusion criteria or correct the text; as written, the inconsistency weakens the representativeness argument for subject selection.
minor comments (5)
  1. [Table III] The table layout is difficult to parse; consider replacing "/" with "0" or an em dash, aligning columns, and adding raw counts alongside percentages to make the small sample sizes visible.
  2. [References [37] and [38]] References [37] and [38] list the same Milvus SIGMOD 2021 paper; please merge the duplicate entry.
  3. [§III-B2] The reported Cohen's kappa exceeds 0.95 for the pilot with the initial 20-root-cause taxonomy, but the final taxonomy has 31 root causes after iterative expansion and re-annotation; please clarify whether a second agreement check was performed on the final taxonomy or state that all final labels were resolved by consensus.
  4. [§IV-B5] The two configuration subcategories (Environment Configuration Error at 79.6% and Logging Issues at 20.4%) are not defined in the text; please add a sentence defining what counts as an environment configuration error.
  5. [Contributions bullet list] The contributions section promises "10 actionable insights", and the text does indeed present Insight 1 through Insight 10; consider numbering or cross-referencing them consistently in the abstract or introduction.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the bug taxonomy and prevalence distributions are descriptive summaries of manually labeled PRs, not predictions fitted to their own inputs.

full rationale

The paper's derivation chain is descriptive, not inferential in a way that reduces to its inputs. It collects merged bug-fix PRs using keyword filters, manually labels each PR along symptom, root cause, and fix-strategy dimensions, and then reports the frequencies of those labels (e.g., 57.3% functional failures, 48.6% query-layer bugs). The taxonomy itself is explicitly induced from the same dataset: the authors state in Section III-B that the root-cause taxonomy was iteratively refined based on observed patterns, expanded to 41 root causes, and then consolidated to 31. This is standard practice for an empirical taxonomy study and is not circular because the paper makes no out-of-sample prediction and fits no parameter that is then renamed as a finding. The Milvus and Vespa reverse-chronological PR subsets raise a representativeness concern, not a circularity concern; no equation or definition forces the aggregate percentages to equal the sampling window. The only same-author citation that appears in a supporting role is reference [43], used for a background remark about memory leaks causing instability, and it does not supply the dataset, the labels, or the taxonomy. Removing that citation would not change any reported result. The paper is self-contained in the sense that every reported distribution is directly traceable to the stated manual annotation procedure.

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

The study rests on domain assumptions about the correspondence between GitHub PRs and bug reality, and about the representativeness of the sampled projects and time windows. No new entities or fitted parameters are introduced.

assumptions (5)
  • domain assumption Keyword-filtered merged GitHub PRs approximate the full population of VDBMS bugs.
    The study only includes PRs whose title or labels contain bug-related keywords (Section III-A2). Bug fixes with neutral titles or uncovered fix paths are excluded, so prevalence estimates may miss a part of the bug population.
  • domain assumption Milvus and Vespa current time-window subsets represent their overall bug mix.
    Both repositories have far more closed PRs than can be manually inspected; the authors took the most recent 412 PRs for each (Section III-A2). If bug types changed over time, the cross-system comparisons in Table III and the aggregate distributions are biased.
  • domain assumption Manual labels by two annotators with third-party arbitration are accurate ground truth.
    Cohen's kappa of 0.95 was measured only on a 150-PR pilot (Section III-B2), not on the remaining 1,313 PRs. Labeling quality on the full dataset is assumed.
  • domain assumption The 15 selected systems represent the VDBMS ecosystem.
    Selection used GitHub stars greater than 14,000 as of 2024-11-29 (Section III-A1). Smaller and commercial systems are excluded, so findings may not generalize to all VDBMSs.
  • domain assumption A bug-fix PR maps to one discrete root cause and one symptom.
    The methodology splits multi-bug PRs and assigns one symptom/root cause per entry (Section III-B2), which assumes such a one-to-one mapping is meaningful for all cases.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Toward Understanding Bugs in Vector Database Management Systems." pith.science (2026). https://pith.science/paper/V6E3V32O

@misc{pith2026250602617,
  author       = {Pith},
  title        = {Pith review of: Toward Understanding Bugs in Vector Database Management Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/V6E3V32O}},
  note         = {Machine review of arXiv:2506.02617}
}
read the original abstract

Vector database management systems (VDBMSs) play a crucial role in facilitating semantic similarity searches over high-dimensional embeddings from diverse data sources. While VDBMSs are widely used in applications such as recommendation, retrieval-augmented generation (RAG), and multimodal search, their reliability remains underexplored. Traditional database reliability models cannot be directly applied to VDBMSs because of fundamental differences in data representation, query mechanisms, and system architecture. To address this gap, we present the first large-scale empirical study of software defects in VDBMSs. We manually analyzed 1,671 bug-fix pull requests from 15 widely used open-source VDBMSs and developed a comprehensive taxonomy of bugs based on symptoms, root causes, and developer fix strategies. Our study identifies five categories of bug symptoms, with more than half manifesting as functional failures. We further reveal 31 recurring fault patterns and highlight failure modes unique to vector search systems. In addition, we summarize 12 common fix strategies, whose distribution underscores the critical importance of correct program logic. These findings provide actionable insights into VDBMS reliability challenges and offer guidance for building more robust future systems.

Figures

Figures reproduced from arXiv: 2506.02617 by the authors.

Figure 1
Figure 1. Architecture of VDBMSs. 1) VDBMS Server: User requests, transmitted via the client, flow through three layers on the server: query, index, and storage. The query layer parses and plans the request, the index layer performs efficient vector retrieval, and the storage layer provides access to the underlying data, which is then returned to the query layer for final processing and response. Query. This layer includes fo… view at source ↗
Figure 2
Figure 2. Overview of the methodology for investigating bug characteristics in VDBMSs. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Distribution of symptoms [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Overview and example of the bug classification method. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

48 extracted references · 31 canonical work pages

  1. [43]

    Towards Reliable Vector Database Management Systems: A Software Testing Roadmap for 2030

    S. Wang, Y . Zhao, Y . Xie, Z. Liu, X. Hou, Q. Zou, and H. Wang, “Towards reliable vector database management systems: A software testing roadmap for 2030,” 2025. [Online]. Available: https://arxiv.org/abs/2502.20812

    work page Pith review arXiv 2025

  2. [1]

    Annoy, “Annoy,” https://github.com/spotify/annoy, 2013

    work page 2013

  3. [2]

    Approximate nearest neighbor queries in fixed dimensions,

    S. Arya and D. M. Mount, “Approximate nearest neighbor queries in fixed dimensions,” in Proceedings of the Fourth Annual ACM-SIAM Symposium on Discrete Algorithms , ser. SODA ’93. USA: Society for Industrial and Applied Mathematics, 1993, p. 271–280

    work page 1993

  4. [3]

    Attu, “Attu,” https://zilliz.com.cn/attu, 2022

    work page 2022

  5. [4]

    Toward Understanding Deep Learning Framework Bugs

    J. Chen, Y . Liang, Q. Shen, J. Jiang, and S. Li, “Toward understanding deep learning framework bugs,” 2024. [Online]. Available: https://arxiv.org/abs/2203.04026

    work page Pith review arXiv 2024

  6. [5]

    Chroma, “Chroma,” https://github.com/chroma-core/chroma, 2022

    work page 2022

  7. [6]

    Nearest neighbor pattern classification,

    T. Cover and P. Hart, “Nearest neighbor pattern classification,” IEEE Transactions on Information Theory , vol. 13, no. 1, pp. 21–27, 1967

    1967

  8. [7]

    Understanding transaction bugs in database systems,

    Z. Cui, W. Dou, Y . Gao, D. Wang, J. Song, Y . Zheng, T. Wang, R. Yang, K. Xu, Y . Hu, J. Wei, and T. Huang, “Understanding transaction bugs in database systems,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering , ser. ICSE ’24. New York, NY , USA: Association for Computing Machinery, 2024. [Online]. Available: https://...

    arXiv 2024

Show all 48 references
  1. [8]

    Random projection trees revisited,

    A. Dhesi and P. Kar, “Random projection trees revisited,” in Advances in Neural Information Processing Systems , J. Lafferty, C. Williams, J. Shawe-Taylor, R. Zemel, and A. Culotta, Eds., vol. 23. Curran Associates, Inc., 2010. [Online]. Available: https://proceedings.neurips....

    2010

  2. [9]

    Partially relevant video retrieval,

    J. Dong, X. Chen, M. Zhang, X. Yang, S. Chen, X. Li, and X. Wang, “Partially relevant video retrieval,” in Proceedings of the 30th ACM International Conference on Multimedia , ser. MM ’22. ACM, Oct. 2022, p. 246–257. [Online]. Available: http://dx.doi.org/10.1145/3503161.3547976

    2022

  3. [10]

    The faiss library,

    M. Douze, A. Guzhva, C. Deng, J. Johnson, G. Szilvasy, P.-E. Mazar ´e, M. Lomeli, L. Hosseini, and H. J ´egou, “The faiss library,” 2024

    2024

  4. [11]

    Vector quantization,

    R. Gray, “Vector quantization,” IEEE ASSP Magazine, vol. 1, no. 2, pp. 4–29, 1984

    1984

  5. [12]

    gRPC, “gRPC,” https://github.com/grpc/grpc, 2025

    2025

  6. [13]

    Manu: A cloud native vector database management system,

    R. Guo, X. Luan, L. Xiang, X. Yan, X. Yi, J. Luo, Q. Cheng, W. Xu, J. Luo, F. Liu, Z. Cao, Y . Qiao, T. Wang, B. Tang, and C. Xie, “Manu: A cloud native vector database management system,” 2022. [Online]. Available: https://arxiv.org/abs/2206.13843

    2022 arXiv

  7. [14]

    Deep lake: a lakehouse for deep learning,

    S. Hambardzumyan, A. Tuli, L. Ghukasyan, F. Rahman, H. Topchyan, D. Isayan, M. Harutyunyan, T. Hakobyan, I. Stranic, and D. Buniatyan, “Deep lake: a lakehouse for deep learning,” 2023. [Online]. Available: https://www.cidrdb.org/cidr2023/papers/p69-buniatyan.pdf

    2023

  8. [15]

    Product quantization for nearest neighbor search,

    H. J ´egou, M. Douze, and C. Schmid, “Product quantization for nearest neighbor search,” IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 33, no. 1, pp. 117–128, 2011

    2011

  9. [16]

    Lancedb,

    LanceDB, “Lancedb,” https://github.com/lancedb/lancedb, 2023

    2023

  10. [17]

    Langchain,

    LangChain, “Langchain,” https://www.langchain.com/, 2022

    2022

  11. [18]

    An empirical study on the characteristics of database access bugs in java applications,

    W. Liu, S. Mondal, and T.-H. Chen, “An empirical study on the characteristics of database access bugs in java applications,” 2024. [Online]. Available: https://arxiv.org/abs/2405.15008

    2024 arXiv

  12. [19]

    Llamaindex,

    LlamaIndex, “Llamaindex,” https://docs.llamaindex.ai/, 2023

    2023

  13. [20]

    The next stop for vector databases: 8 predictions for 2023,

    J. Luan, “The next stop for vector databases: 8 predictions for 2023,” https://zilliz.com/blog/ the-next-stop-for-vector-databases-8-predictions-for-2023, 2022

    2023

  14. [21]

    Efficient and robust approxi- mate nearest neighbor search using hierarchical navigable small world graphs,

    Y . A. Malkov and D. A. Yashunin, “Efficient and robust approxi- mate nearest neighbor search using hierarchical navigable small world graphs,” IEEE transactions on pattern analysis and machine intelligence, vol. 42, no. 4, pp. 824–836, 2018

    2018

  15. [22]

    Marqo, “Marqo,” https://github.com/marqo-ai/marqo, 2022

    2022

  16. [23]

    A survey of product quantization,

    Y . Matsui, Y . Uchida, H. J ´egou, and S. Satoh, “A survey of product quantization,” ITE Transactions on Media Technology and Applications, vol. 6, no. 1, pp. 2–10, 2018

    2018

  17. [24]

    Fast approximate nearest neighbors with automatic algorithm configuration

    M. Muja and D. Lowe, “Fast approximate nearest neighbors with automatic algorithm configuration.” vol. 1, 01 2009, pp. 331–340

    2009

  18. [25]

    Survey of vector database management systems,

    J. J. Pan, J. Wang, and G. Li, “Survey of vector database management systems,” The VLDB Journal , vol. 33, no. 5, pp. 1591–1615, 2024

    2024

  19. [26]

    pgvecto.rs,

    pgvecto.rs, “pgvecto.rs,” https://github.com/tensorchord/pgvecto.rs, 2023

    2023

  20. [27]

    Qdrant, “Qdrant,” https://github.com/qdrant/qdrant, 2020

    2020

  21. [28]

    Towards understanding the faults of javascript-based deep learning systems,

    L. Quan, Q. Guo, X. Xie, S. Chen, X. Li, and Y . Liu, “Towards understanding the faults of javascript-based deep learning systems,” in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering , ser. ASE ’22. ACM, Oct. 2022, p. 1–13. [Online]....

    2022

  22. [29]

    Detecting optimization bugs in database engines via non-optimizing reference engine construction,

    M. Rigger and Z. Su, “Detecting optimization bugs in database engines via non-optimizing reference engine construction,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering , ser. ESE...

    2020

  23. [30]

    Optimised kd-trees for fast image descriptor matching,

    C. Silpa-Anan and R. Hartley, “Optimised kd-trees for fast image descriptor matching,” in 2008 IEEE Conference on Computer Vision and Pattern Recognition, 2008, pp. 1–8

    2008

  24. [31]

    (vector) space is not the final frontier: Product search as program synthesis,

    J. Tagliabue and C. Greco, “(vector) space is not the final frontier: Product search as program synthesis,” 2023. [Online]. Available: https://arxiv.org/abs/2304.11473

    2023 arXiv

  25. [32]

    txtai, “txtai,” https://github.com/neuml/txtai, 2020

    2020

  26. [33]

    USearch by Unum Cloud,

    A. Vardanian, “USearch by Unum Cloud,” Oct. 2023. [Online]. Available: https://github.com/unum-cloud/usearch

    2023

  27. [34]

    Vespa, “Vespa,” https://github.com/vespa-engine/vespa, 2016

    2016

  28. [35]

    Cohen’s kappa coeffi- cient as a performance measure for feature selection,

    S. M. Vieira, U. Kaymak, and J. M. C. Sousa, “Cohen’s kappa coeffi- cient as a performance measure for feature selection,” in International Conference on Fuzzy Systems , 2010, pp. 1–8

    2010

  29. [36]

    V oyager,

    V oyager, “V oyager,” https://github.com/spotify/voyager, 2023

    2023

  30. [37]

    Milvus: A purpose-built vector data management system,

    J. Wang, X. Yi, R. Guo, H. Jin, P. Xu, S. Li, X. Wang, X. Guo, C. Li, X. Xu et al., “Milvus: A purpose-built vector data management system,” in Proceedings of the 2021 International Conference on Management of Data, 2021, pp. 2614–2627

    2021

  31. [38]

    Milvus: A purpose-built vector data management system,

    J. Wang, X. Yi, R. Guo, H. Jin, P. Xu, S. Li, X. Wang, X. Guo, C. Li, X. Xu, K. Yu, Y . Yuan, Y . Zou, J. Long, Y . Cai, Z. Li, Z. Zhang, Y . Mo, J. Gu, R. Jiang, Y . Wei, and C. Xie, “Milvus: A purpose-built vector data management system,” in Proceedings of the 2021 Internati...

    2021

  32. [39]

    A survey on learning to hash,

    J. Wang, T. Zhang, J. Song, N. Sebe, and H. T. Shen, “A survey on learning to hash,” 2017. [Online]. Available: https: //arxiv.org/abs/1606.00185

    2017 arXiv

  33. [40]

    A comprehensive survey and experimental comparison of graph-based approximate nearest neighbor search,

    M. Wang, X. Xu, Q. Yue, and Y . Wang, “A comprehensive survey and experimental comparison of graph-based approximate nearest neighbor search,” 2021. [Online]. Available: https://arxiv.org/abs/2101.12631

    2021 arXiv

  34. [41]

    Large language model supply chain: A research agenda,

    S. Wang, Y . Zhao, X. Hou, and H. Wang, “Large language model supply chain: A research agenda,” CoRR, vol. abs/2404.12736, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2404.12736

    2024 doi arXiv

  35. [42]

    Sok: Understanding vulnerabilities in the large language model supply chain,

    S. Wang, Y . Zhao, Z. Liu, Q. Zou, and H. Wang, “Sok: Understanding vulnerabilities in the large language model supply chain,” CoRR, vol. abs/2502.12497, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2502.12497

    2025 doi arXiv

  36. [44]

    Weaviate,

    Weaviate, “Weaviate,” https://github.com/weaviate/weaviate, 2016

    2016

  37. [45]

    Analyticdb-v: a hybrid analytical engine towards query fusion for structured and unstructured data,

    C. Wei, B. Wu, S. Wang, R. Lou, C. Zhan, F. Li, and Y . Cai, “Analyticdb-v: a hybrid analytical engine towards query fusion for structured and unstructured data,” Proc. VLDB Endow. , vol. 13, no. 12, p. 3152–3165, Aug. 2020. [Online]. Available: https://doi.org/10.14778/341547...

    2020

  38. [46]

    Hqann: Efficient and robust similarity search for hybrid queries with structured and unstructured constraints,

    W. Wu, J. He, Y . Qiao, G. Fu, L. Liu, and J. Yu, “Hqann: Efficient and robust similarity search for hybrid queries with structured and unstructured constraints,” 2022. [Online]. Available: https://arxiv.org/abs/2207.07940

    2022 arXiv

  39. [47]

    Bhakti: A lightweight vector database management system for endowing large language models with semantic search capabilities and memory,

    Z. Wu, “Bhakti: A lightweight vector database management system for endowing large language models with semantic search capabilities and memory,” 2025. [Online]. Available: https://arxiv.org/abs/2504.01553

    2025 arXiv

  40. [48]

    Who you are matters: Bridging topics and social roles via llm-enhanced logical recommendation,

    Q. Yu, X. Wang, S. Liu, Y . Bai, X. Yang, X. Wang, C. Meng, S. Wu, H. Yang, H. Xiao, X. Li, F. Yang, X. Feng, L. Hu, H. Li, K. Gai, and L. Zou, “Who you are matters: Bridging topics and social roles via llm-enhanced logical recommendation,” 2025. [Online]. Available: https://a...

    2025

Pith tools

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