Integrate RAG within ConversationSpace and GithubDiscussion

[sarrah-basta]

Within the LLAMOSC framework (situated in Open Source Sustainability using LLMs), incorporate Retrieval-Augmented Generation (RAG) for enhanced information retrieval in simulated ConversationSpace and GitHub discussions.

This issue can only be attempted after the completion of #60

[sarrah-basta]

Hi @Orthogonal-Research-Lab,
Thank you for the contribution @SatyaKapardi and the feedback @quirky-blu.
While this PR introduces the basic mechanics of RAG, I want to clarify that this is only a preliminary step. For our GSoC candidates, RAG integration is a major research area that must be tied directly to the development of the ConversationSpace. Please read through #64 (comment) to understand this in depth.

A successful GSoC proposal must move beyond basic indexing and address the following:

• Real-World Continuity: The primary purpose of RAG in LLAMOSC is to ingest archived conversation history from platforms like Slack, IRC, and Discord. The goal is to allow our agents to continue real-life discussions seamlessly within the simulation.
• Vector Store Research: We are looking for research-backed comparisons of different vector databases (e.g., FAISS vs. Pinecone vs. Chroma) and embedding models. Proposals should analyze the cost-effectiveness and performance trade-offs of these tools at scale.
• Architectural Dependency: RAG cannot be finalized until the ConversationSpace is fully defined. Proposals should outline a strategy for how the RAG pipeline will dynamically scale as we bring in larger external datasets.
• Frontend & Performance: As noted in the discussion, performance is a major concern. We need a design that ensures RAG remains efficient and fully integrated into the frontend without causing the simulation to lag or become unusable.

We expect contributors to use this current implementation as a basic reference point, but your proposals should focus on the research, data ingestion strategies, and architectural design required to make real-world archival data a functional part of our agentic simulations.

[SandeepChauhan00]

Hey @sarrah-basta, I created an issue and PR that addresses part of this:

• Issue Add pluggable vector store backends for RAG with benchmarking support #133: Proposed vector store abstraction
• PR Add vector store abstraction layer for RAG - supports FAISS and Chroma backends #135: Implemented FAISS + Chroma backends with pluggable interface

This makes it easy to compare different vector stores without code changes. Next step would be adding a benchmark script to test performance at different scales.

Let me know if this aligns with what you're looking for!

[quirky-blu]

@SandeepChauhan00 i think you've misunderstood the the comment especially the vector db part

Vector Store Research: We are looking for research-backed comparisons of different vector databases (e.g., FAISS vs. Pinecone vs. Chroma) and embedding models. Proposals should analyze the cost-effectiveness and performance trade-offs of these tools at scale.

This part suggests doing some research before using the best possible vector db for the rag

Your pr adds support for all 3 mentioned vectors db rather than the best with some backed esearch

Ps I don't see how making vector dbs pluggable would help?
The aim of vector dbs are to allow contributor agent to refers to previous simulated conversation of the repo

Giving data of some another conversation would be hardly of use?

[sarrah-basta]

I urge all contributors to use AI with care and consideration, using it for assistance in coding or understanding large databases is understandable with proper code review, but using it everywhere is not what GSoC is about. A 3-6 month project requires you to do research, understand requirements, implement and debug, and in the weeks leading up to the proposal submission, your ability to do this is what will be judged most by the mentors