Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hey fellow open-source enthusiasts,

We built Korvus, an open-source RAG (Retrieval-Augmented Generation) pipeline that consolidates the entire RAG workflow - from embedding generation to text generation - into a single SQL query, significantly reducing architectural complexity and latency.

Here's some of the highlights:

- Full RAG pipeline (embedding generation, vector search, reranking, and text generation) in one SQL query

- SDKs for Python, JavaScript, and Rust (more languages planned)

- Built on PostgreSQL, leveraging pgvector and pgml

- Open-source, with support for open models

- Designed for high performance and scalability

Korvus utilizes Postgres' advanced features to perform complex RAG operations natively within the database. We're also the developers of PostgresML, so we're big advocates of in-database machine learning. This approach eliminates the need for external services and API calls, potentially reducing latency by orders of magnitude compared to traditional microservice architectures. It's how our founding team built and scaled the ML platform at Instacart.

We're eager to get feedback from the community and welcome contributions. Check out our GitHub repo for more details, and feel free to hit us up in our Discord!



Very cool! A assume you use Postgres' native full-text search capabilities? Any plans for BM25 or similar? This would make Korvus the end-game for open source rag IMO.


How do you resolve the disparity between semantic and text search? Surely these rankings are difficult to combine.


I’d start with something very simple such as Reciprocal Rank Fusion. I’d also want to make sure I really trusted the outputs of each search pipeline before worrying too much about the appropriate algorithm for combining the rankings.


I find it misleading to use an f-string containing encoded `{CONTEXT}` <https://github.com/postgresml/korvus/blob/bce269a20a1dbea933...>, and after digging into TFM <https://postgresml.org/docs/open-source/korvus/guides/rag#si...> it seems it is not, in fact, an f-string artifact but rather the literal characters "{"+"CONTEXT"+"}" and are the same in all the language bindings?

IMHO it would be much clearer if you just used the normal %s for the "outer" string and left the implicit f-string syntax as it is, e.g.

                    {
                        "role": "user",
                        # this is not an f-string, is rather replaced by TODO FIXME
                        "content": "Given the context\n:{CONTEXT}\nAnswer the question: %s" % query,
                    },
The way the example (in both the readme and the docs) is written, it seems to imply I can put my own fileds as siblings to the chat key and they, too, will be resolved

    results = await collection.rag(
        {
            "EXAMPLE": {
              "uh-huh": True
            },
            "CONTEXT": {
                "vector_search": {
                    "query": {
                        "fields": {"text": {"query": query}},
                    },
                    "document": {"keys": ["id"]},
                    "limit": 1,
                },
                "aggregate": {"join": "\n"},
            },
            "chat": {
              "messages": [{"content": "Given Context:\n{CONTEXT}\nAn Example:\n{EXAMPLE}"
            }


One could not fault the user for thinking such a thing since the *API* docs say "see the *GUIDE*" :-( https://postgresml.org/docs/open-source/korvus/api/collectio...


This section of the docs may be confusing. What you described will actually almost work. See: https://postgresml.org/docs/open-source/korvus/guides/rag#ra...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: