Top AI Repos — open-source AI, indexed and scored
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Embeddable vector database for Go with Chroma-like interface and zero third-party dependencies. In-memory with optional persistence.
| Date | Stars |
|---|---|
| 2026-07-31 | 1041 |
| 2026-08-07 | 1044 |
| 2026-08-18 | 1046 |
| 2026-08-21 | 1047 |
| 2026-08-23 | 1048 |
| 2026-08-29 | 1050 |
| 2026-08-30 | 1049 |
| 2026-09-01 | 1050 |
| 2026-09-02 | 1051 |
| 2026-09-04 | 1052 |
| 2026-09-05 | 1053 |
| 2026-09-09 | 1054 |
| 2026-09-11 | 1055 |
| 2026-09-12 | 1056 |
| 2026-09-16 | 1058 |
| 2026-09-17 | 1058 |
| 2026-09-23 | 1059 |
| 2026-09-26 | 1058 |
| 2026-09-27 | 1059 |
| 2026-10-02 | 1060 |
| 2026-10-03 | 1061 |
| 2026-10-05 | 1062 |
| 2026-10-07 | 1063 |
| 2026-10-10 | 1063 |
| 2026-10-11 | 1065 |
| 2026-10-13 | 1067 |
| 2026-10-16 | 1068 |
| 2026-10-17 | 1069 |
| 2026-10-22 | 1070 |
| 2026-10-23 | 1071 |
| 2026-10-25 | 1072 |
| 2026-10-27 | 1073 |
| 2026-10-30 | 1072 |
| 2026-11-01 | 1073 |
| 2026-11-02 | 1072 |
| 2026-11-03 | 1073 |
| 2026-11-04 | 1074 |
Today
+1 stars today
This week
+1 stars this week
This month
+12 stars this month
Momentum
0.0
growth rate 0.09%/day
# chromem-go [](https://pkg.go.dev/github.com/philippgille/chromem-go) [](https://github.com/philippgille/chromem-go/actions/workflows/go.yml) [](https://goreportcard.com/report/github.com/philippgille/chromem-go) [](https://github.com/philippgille/chromem-go/releases) Embeddable vector database for Go with Chroma-like interface and zero third-party dependencies. In-memory with optional persistence. Because `chromem-go` is embeddable it enables you to add retrieval augmented generation (RAG) and similar embeddings-based features into your Go app *without having to run a separate database*. Like when using SQLite instead of PostgreSQL/MySQL/etc. It's *not* a library to connect to Chroma and also not a reimplementation of it in Go. It's a database on its own. The focus is not scale (millions of documents) or number of features, but simplicity and performance for the most common use cases. On a mid-range 2020 Intel laptop CPU you can query 1,000 documents in 0.3 ms and 100,000 documents in 40 ms, with very few and small memory allocations. See [Benchmarks](#benchmarks) for details. > ⚠️ The project is in beta, under heavy construction, and may introduce breaking changes in releases before `v1.0.0`. All changes are documented in the [`CHANGELOG`](./CHANGELOG.md). ## Contents 1. [Use cases](#use-cases) 2. [Interface](#interface) 3. [Features + Roadmap](#features) 4. [Installation](#installation) 5. [Usage](#usage) 6. [Benchmarks](#benchmarks) 7. [Development](#development) 8. [Motivation](#motivation) 9. [Related projects](#related-projects) ## Use cases With a vector database you can do various things: - Retrieval augmented generation (RAG), question answering (Q&A) - Text and code search - Recommendation systems - Classification - Clustering Let's look at the RAG use case in more detail: ### RAG The knowledge of large language models (LLMs) - even the ones with 30 billion, 70 billion parameters and more - is limited. They don't know anything about what happened after their training ended, they don't know anything about data they were not trained with (like your company's intranet, Jira / bug tracker, wiki or other kinds of knowledge bases), and even the data they *do* know they often can't reproduce it *exactly*, but start to *hallucinate* instead. Fine-tuning an LLM can help a bit, but it's more meant to improve the LLMs reasoning about specific topics, or reproduce the style of written text or code. Fine-tuning does *not* add knowledge *1:1* into the model. Details are lost or mixed up. And knowledge cutoff (about anything that happened after the fine-tuning) isn't solved either. => A vector database can act as the up-to-date, precise knowledge for LLMs: 1. You store relevant documents that you want the LLM to know in the database. 2. The database stores the *embeddings* alongside the documents, which you can either provide or can be created by specific "embedding models" like OpenAI's `text-embedding-3-small`. - `chromem-go` can do this for you and supports multiple embedding providers and models out-of-the-box. 3. Later, when you want to talk to the LLM, you first send the question to the vector DB to find *similar*/*related* content. This is called "nearest neighbor search". 4. In the question to the LLM, you provide this content alongside your question. 5. The LLM can take this up-to-date precise content into account when answering. Check out the [example code](examples) to see it in action! ## Interface Our original inspiration was the [Chroma](https://www.trychroma.com/) interface, whose core API is the following (taken from their [README](https://github.com/chro
Excerpt of 17,874 characters
Read on GitHub
Philipp Gillé · @Heetch · Germany
346
12
9
6
Adrian Cole · Netflix
2
2
2
Would you bet a product on this? Bounded 0–100 and slow moving.
matched fp:5fb5605b4592d1b8, topic:vector-database, topic:vector-search, desc:vector database
matched fp:5fb5605b4592d1b8, topic:rag, topic:retrieval-augmented-generation, readme:retrieval-augmented generation