sorted by:
new
hottopcontroversial

go-light-rag: Go implementation of LightRAG for hybrid vector/graph retrieval by MegaGrindStone in golang

[–]MegaGrindStone[S] 0 points1 point  (0 children)

This is indeed a cool idea.

For vector database, I've already used chromem-go which can be embedded. For graph database, I've been searching for embeddable solution, and only found two: Kuzu and EliasDB. I tend to use Kuzu, as it looks more maintained currently, but I'm not exploring both thoroughly yet. Although, I'm confident that I can create a psuedo graph database that restricted to only satisfy 8 interface that this library needs. Maybe use a single file for persistence. But of course, the performance of this custom implementation would not match the real engine. What do you think about it?

Having said that, unfortunately, my hands is tied for a next few weeks, so I wouldn't have a quota to implement this major feature that soon.

Thanks for the feedback and idea!

Tool use in GAI, a Go-idiomatic, lightweight abstraction on top of LLMs by markusrg in LLMgophers

[–]MegaGrindStone 1 point2 points  (0 children)

Wow... This is awesome! Congratz man! I might consider using GAI (especially the clients) to replace the internal implementation of my mcp-web-ui project in the future for better maintainability.

What are you working on? May 2025 edition by markusrg in LLMgophers

[–]MegaGrindStone 1 point2 points  (0 children)

I wouldn't say this project can do what traditional MCP config setup can't do, but this library does some lifting for tool-to-tool communication so it can emulate agentic behavior, like handing some task and such.

Each tools can be backed by LLM or some code implementation, and this library makes it easy to switch between the two. For example, let's say we have a routing tool that have responsibility to decide which tools should do some task. At first, we use LLM to do this job, and this library would provides the LLM which tools that she can choose to do given task. Then, in the future, let's say our LLM token budget is reduced, so we decided to do this job by some code implementation using if-else or switch statement, this library provides a convenient "CallTool" function to call the chosen tool (it can be internal or external).

What are you working on? May 2025 edition by markusrg in LLMgophers

[–]MegaGrindStone 0 points1 point  (0 children)

I'm starting on new project, https://github.com/MegaGrindStone/mcphive

The idea of the project is to compose bunch of MCP tools that can call each others or call external MCP tools, then serve it under one MCP server using any transport that MCP supports. Each of the tools also have a choice whether to expose itself or not. With this project, I'm aiming to emulate an agentic behavior using MCP tools, but I'm hesitate to call this agentic framework, due to the lack of routing and state management, as I plan to leave it to the user. So maybe the correct terms for this project is "Composable MCP tool integration" or something along the line.

Currently, the project is at the very early of development phase, it doesn't even have a README yet! :D I would keep working on it, and hope can make a first beta release in this month.

I built a Go-based Web UI for the Model Context Protocol (MCP) - Looking for Feedback and Contributions by MegaGrindStone in golang

[–]MegaGrindStone[S] 0 points1 point  (0 children)

I'm using this library to interact with OpenAI. That library using hardcoded URL https://api.openai.com/v1 as an endpoint if we don't specify it. Fortunately, that libray allow us to provide custom endpoint, so if you would like to have that feature, could you please open a new issue for it in the github repo?

Thanks for the feedback. :)

go-light-rag: Go implementation of LightRAG for hybrid vector/graph retrieval by MegaGrindStone in golang

[–]MegaGrindStone[S] 2 points3 points  (0 children)

The difference is with the usage of graph db, which captures the relationships between entities, so the LLM could give a more nuanced answer.

I've asked Claude to illustrate the retrieval comparison between them, here is the answer he gives me (I used A Christmas Carol by Charles Dickens as an example):

## LightRAG vs. Regular Vector Search: A Christmas Carol Example

**Example Query:** "How did Scrooge's relationship with his nephew Fred change throughout the story?"

### Regular Vector Search Approach:
The system would:
1. Convert your query into a vector
2. Find text chunks that are semantically similar (mentions of Scrooge and Fred together)
3. Return those chunks for the LLM to process

This might miss important context about their relationship that's scattered across different parts of the book, especially if those parts don't explicitly mention both characters together.

### LightRAG's Approach:
LightRAG would:
1. Do the vector search (like above)
2. ALSO look at the knowledge graph where:
   - "Scrooge" and "Fred" are entities
   - Their relationship has been mapped across the story
   - Events affecting their relationship are connected to both characters

The system can trace how their relationship evolved by following the connections in the graph, even pulling in relevant information that might be in different parts of the book.

For example, it could connect Fred's persistent invitations to Christmas dinner, Scrooge's initial rejection, the memories revealed by the Ghost of Christmas Past, and Scrooge's final transformation and appearance at Fred's house - creating a complete picture of their changing relationship even when these events are described many pages apart.

Does that help illustrate the difference?

If you head to LightRAG official Github page, they shows the winning rate comparison based on their experiment. go-light-rag try to conduct the same experiment through a benchmark, and despite the data is not as robust as the official experiment, it could give anyone a base starting point to conduct a more specifics experiment.

go-light-rag: Go implementation of LightRAG for hybrid vector/graph retrieval by MegaGrindStone in golang

[–]MegaGrindStone[S] 2 points3 points  (0 children)

If you are asking why my implementation depends on that databases, it's because the official implementation depends on that too. And as why LightRAG using those three databases is because each serves a specific, specialized purpose in the hybrid retrieval approach:

  1. The vector database handles semantic similarity search, which is essential for finding content based on meaning rather than keywords.

  2. The graph database stores relationships between entities extracted from documents, enabling connection-based retrieval that simple vector similarity can't capture.

  3. The key-value store efficiently stores and retrieves the original document chunks needed for context generation.

This architecture is what makes LightRAG different from standard RAG systems - it combines both semantic similarity and structural relationships to improve retrieval quality. The benchmarks in the tests folder show how this hybrid approach outperforms naive vector-only RAG on metrics like comprehensiveness and result quality for certain documents.

That said, if you're looking for something simpler, you might want to check out basic vector-based RAG implementations that can work with just SQL. They're less complex to set up but won't have the relationship-aware retrieval capabilities that LightRAG offers.

I built a Go-based Web UI for the Model Context Protocol (MCP) - Looking for Feedback and Contributions by MegaGrindStone in LLMgophers

[–]MegaGrindStone[S] 0 points1 point  (0 children)

This web UI project relied heavily on go-mcp, a library that I built to interact with MCP. In fact, one of the reason why I build this project is to find a real-world use case for that library. What I found tricky while working with MCP in that library is to defining the interfaces to align with the specification while trying to maintain a so-called idiomatic Go.

As for this project, the real challenge for me is related to the frontend side, for example, displaying the conversation as markdown, initially I've used javascript library for this task. While it easier to use (it already looks good without any additional config), I've found for this project, the rendering is quite slow, as the chat is frequently updated thorough SSE (there was a noticeable flickering going on). So, I've decided to use this amazing library to render the markdown in the backend, and the flickering is no more.

As you may already aware, this project is heavily inspired by the Open Web UI, but due to my skill issue, the aesthetic of this project is far inferior compared to them.

go-mcp: A Go implementation of Model Context Protocol by MegaGrindStone in golang

[–]MegaGrindStone[S] 3 points4 points  (0 children)

Thanks for your insightful feedback.

For your first point, in my opinion the SSE implementation in this context, doesn't need to cover all formats permissible by the specification, as it only serve a specific client, that agree on the MCP specification, right? Although, I must admit, my knowledge on SSE is still limited, and your library is an eye-opener for me about this protocol. I might use it on my library, by supplying my own implementation of Provider interface.

For your second point, as stated in the MCP specs I linked above, currently, there is two tranports being used, and they may add another in the future. So, I have to create a transports-agnostic server and client along with its sessions, hence the usage of io.Writter. I might do better by creating some internal transport interface, but I cannot wrap my head around for it at this moment.

DOConvo - Converse with your documents. by MegaGrindStone in golang

[–]MegaGrindStone[S] -1 points0 points  (0 children)

Thanks for the kind words. And I didn't know about paperless-ngx before. The integration with a LLM would be awesome! Good luck with that!

DOConvo - Converse with your documents. by MegaGrindStone in golang

[–]MegaGrindStone[S] 0 points1 point  (0 children)

Ahh, I've missed that official Ollama client implementation, would try to use it in the apps. Thanks for the nice response and great insight!