Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5648] [FEAT]: use wiki-llm or proxy pointer RAG #5217

New Issue
Closed
opened 2026-06-05 14:52:42 -04:00 by yindo · 2 comments
yindo commented 2026-06-05 14:52:42 -04:00
Owner
Copy Link
Copy Source

Originally created by @jakob1379 on GitHub (May 18, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5648

What would you like to see?

these two overlapping, not quite competing ideas has proven to be much more useful than regular naive RAG in retrieval. Wiki is for more dynamic content that develops over time, whereas the proxy pointer rag seems better for content that does not change rapidly. Both improves tremendously on the retrieval and reasoning.

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
https://towardsdatascience.com/proxy-pointer-rag-structure-meets-scale-100-accuracy-with-smarter-retrieval/

Originally created by @jakob1379 on GitHub (May 18, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5648 ### What would you like to see? these two overlapping, not quite competing ideas has proven to be much more useful than regular naive RAG in retrieval. Wiki is for more dynamic content that develops over time, whereas the proxy pointer rag seems better for content that does not change rapidly. Both improves tremendously on the retrieval and reasoning. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f https://towardsdatascience.com/proxy-pointer-rag-structure-meets-scale-100-accuracy-with-smarter-retrieval/
yindo added the enhancementfeature request labels 2026-06-05 14:52:42 -04:00
yindo closed this issue 2026-06-05 14:52:42 -04:00
yindo commented 2026-06-05 14:52:43 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (May 19, 2026):

We've looked at both wiki-llm and proxy pointer RAG approaches.

While these are interesting research directions, we're hesitant to fold them into AnythingLLM's core retrieval path for a few reasons:

  1. Maintenance burden - Any architectural change to the RAG pipeline becomes something we maintain indefinitely. These approaches are relatively new and haven't been battle-tested at scale across diverse use cases.

  2. Complexity vs. gain - The papers show promising results in specific scenarios, but introducing this complexity into the critical path affects every user, not just those who would benefit from it. Candidly, most are not going to use this.

  3. There's already a simpler path - If you're using a wiki-based knowledge system, you can achieve similar results today using AnythingLLM's agent capabilities with a custom tool. Create a tool that queries your wiki as a REST service, and the model can interact with it dynamically during conversations. This gives you the "live lookup" benefit without requiring core changes and is far more extensible since its basically a plugin now.

Ultimately, we need to be disciplined about what goes into the retrieval pipeline since those decisions are tedious to reverse esp when even a small cohort become reliant on them. We'd rather see these approaches mature in the ecosystem before considering them for core integration.

<!-- gh-comment-id:4490959358 --> @timothycarambat commented on GitHub (May 19, 2026): We've looked at both wiki-llm and proxy pointer RAG approaches. While these are interesting research directions, we're hesitant to fold them into AnythingLLM's core retrieval path for a few reasons: 1. **Maintenance burden** - Any architectural change to the RAG pipeline becomes something we maintain indefinitely. These approaches are relatively new and haven't been battle-tested at scale across diverse use cases. 2. **Complexity vs. gain** - The papers show promising results in specific scenarios, but introducing this complexity into the critical path affects **every** user, not just those who would benefit from it. Candidly, most are not going to use this. 3. **There's already a simpler path** - If you're using a wiki-based knowledge system, you can achieve similar results today using AnythingLLM's agent capabilities with a custom tool. Create a tool that queries your wiki as a REST service, and the model can interact with it dynamically during conversations. This gives you the "live lookup" benefit without requiring core changes and is far more extensible since its basically a plugin now. Ultimately, we need to be disciplined about what goes into the retrieval pipeline since those decisions are tedious to reverse esp when even a small cohort become reliant on them. We'd rather see these approaches mature in the ecosystem before considering them for core integration.
yindo commented 2026-06-05 14:52:43 -04:00
Author
Owner
Copy Link
Copy Source

@jakob1379 commented on GitHub (May 19, 2026):

Thank, you for a very, detailed answer and I, completely understand the burden such a decision would potentially be to maintain ☺️

<!-- gh-comment-id:4491095047 --> @jakob1379 commented on GitHub (May 19, 2026): Thank, you for a very, detailed answer and I, completely understand the burden such a decision would potentially be to maintain ☺️
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#5217
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?