Is your feature request related to a problem? Please describe.
Currently, users can only scope their RAG queries to either a single active document (document_id) or the entire workspace/personal space. There is no middle ground. If a user has uploaded 10 documents and wants to compare, analyze, or synthesize information from exactly 3 specific documents, they must either query them one by one (which prevents cross-document reasoning) or query the entire workspace (which introduces background noise from the other 7 documents and unnecessarily fills up the context window).
Describe the solution you'd like
I would like to support multi-document selection within the chat interface:
Frontend UI: Enhance the document sidebar to allow selecting multiple documents via checkboxes, displaying a indicator such as "Chatting with 3 selected files".
API Schema: Update the ChatRequest schema in backend/app/schemas.py to accept document_ids: Optional[List[str]] = None.
Agent Tools: Update the PDFSearchTool in backend/app/rag/tools.py to accept a list of document_ids and pass them to the hybrid retriever.
Retriever Integration: Forward the list of document_ids to the retrieve() function in backend/app/rag/retriever.py, which is already designed to filter by a list of active document IDs.
WebSocket & SSE Payload: Ensure both uvicorn WebSocket and SSE route payloads support forwarding the document_ids array.
Describe alternatives you've considered
Workspace Isolation: Creating a new temporary workspace every time a user wants to query a custom subset of files. However, this introduces significant backend overhead (workspace creation, member assignment, document re-association) and is disruptive to the user's workspace structure.
Post-Retrieval Filtering: Retrieving chunks from all documents in the workspace and relying on the LLM to ignore chunks from unselected documents. This wastes LLM input tokens, increases response latency, and increases the risk of hallucination/context dilution.
Additional Context
The database query logic in backend/app/rag/retriever.py already handles a list of document IDs:
Since the core retrieval logic is already in place, implementation will focus primarily on updating the LangChain tool interface, route handlers, WebSocket payload, and frontend selection state.
GSSoC '26
Is your feature request related to a problem? Please describe.
Currently, users can only scope their RAG queries to either a single active document (document_id) or the entire workspace/personal space. There is no middle ground. If a user has uploaded 10 documents and wants to compare, analyze, or synthesize information from exactly 3 specific documents, they must either query them one by one (which prevents cross-document reasoning) or query the entire workspace (which introduces background noise from the other 7 documents and unnecessarily fills up the context window).
Describe the solution you'd like
I would like to support multi-document selection within the chat interface:
Frontend UI: Enhance the document sidebar to allow selecting multiple documents via checkboxes, displaying a indicator such as "Chatting with 3 selected files".
API Schema: Update the ChatRequest schema in backend/app/schemas.py to accept document_ids: Optional[List[str]] = None.
Agent Tools: Update the PDFSearchTool in backend/app/rag/tools.py to accept a list of document_ids and pass them to the hybrid retriever.
Retriever Integration: Forward the list of document_ids to the retrieve() function in backend/app/rag/retriever.py, which is already designed to filter by a list of active document IDs.
WebSocket & SSE Payload: Ensure both uvicorn WebSocket and SSE route payloads support forwarding the document_ids array.
Describe alternatives you've considered
Workspace Isolation: Creating a new temporary workspace every time a user wants to query a custom subset of files. However, this introduces significant backend overhead (workspace creation, member assignment, document re-association) and is disruptive to the user's workspace structure.
Post-Retrieval Filtering: Retrieving chunks from all documents in the workspace and relying on the LLM to ignore chunks from unselected documents. This wastes LLM input tokens, increases response latency, and increases the risk of hallucination/context dilution.
Additional Context
The database query logic in backend/app/rag/retriever.py already handles a list of document IDs:
Since the core retrieval logic is already in place, implementation will focus primarily on updating the LangChain tool interface, route handlers, WebSocket payload, and frontend selection state.
GSSoC '26