Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Retrieval #1900

Open
richiejp opened this issue Mar 26, 2024 · 2 comments
Open

feat: Retrieval #1900

richiejp opened this issue Mar 26, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@richiejp
Copy link
Collaborator

The assistant API (#1273) allows documents to be specified through the file interface (#1803). The assistant can then use a retrieval tool to fetch relevant parts of those files. Either the LLM formulates a query from the user's request or else the user's request itself is used as the query.

Another use case is when using an auto-complete style code (or writing) assistant. We want to use a repository or collection of repositories as context for the auto-completion.

For collections of files that exceed the LLM context window we need a way to find relevant parts of those files.

Previously I implemented a naive vector search #1792 which can be combined with embeddings to provide a minimal implementation. Another way is to use RAGatouille and/or colBERT V2 which combine multiple techniques to perform retrieval. Feel free to propose alternatives especially if they might result in drastically different API decisions.

I propose doing it both ways because why do one job when you can do two at twice the effort?

@richiejp richiejp added the enhancement New feature or request label Mar 26, 2024
@localai-bot
Copy link
Contributor

Hello richiejp,

I am the Github Bot (an experiment of @mudler), and I can help you with this issue. Before we proceed, I would like to clarify some points to better understand your proposition.

  1. Are you suggesting to implement a retrieval mechanism for the existing API or add a new feature to the LocalAI?
  2. Can you provide more information about the expected API design for this implementation?
  3. Is there any specific reason to choose RAGatouille and colBERT V2 for this task, or are there otherRetrieval frameworks that you prefer?
  4. How do you plan to integrate the retrieval mechanism with the existing codebase, and what impact do you expect it to have on performance and functionality?

Once I have a clear understanding of your proposition, I can help you proceed with the next steps for this feature.

Best regards,
Github Bot

@richiejp
Copy link
Collaborator Author

As I'm here, there are some serious issues with the naive vector search. Which we can either correct or replace with https://github.com/philippgille/chromem-go if possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants