This repository has been archived by the owner on Mar 16, 2024. It is now read-only.
Integrate non-symbol documentation #26
Comments
Hi @emrgnt-cmplxty! |
emrgnt-cmplxty
added a commit
that referenced
this issue
Aug 28, 2023
Huntemall
pushed a commit
to Huntemall/automata-dev
that referenced
this issue
Oct 30, 2023
…r-cleanup Feature/refactor cleanup
Huntemall
pushed a commit
to Huntemall/automata-dev
that referenced
this issue
Oct 30, 2023
…r-tool-layout Refactor agent tool layout
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Our current
SymbolDocEmbeddingHandler
class is an effective method for embedding source code documentation into symbols. However, there are instances in which relevant and important documentation does not correspond directly to a specific symbol. For instance, the contents of a README.md file or any other similar documents. These non-symbol documents often contain valuable contextual information that could be of significant importance in certain coding instances.Problem:
We currently lack a strategy to include these non-symbol documents in our embedding and retrieval process. Not incorporating such important pieces of information can result in a less context-aware and informative system, which can potentially affect the quality of our coding assistance.
Tentative Solution:
Please note that the following proposed solution is preliminary and subject to revision.
One possible solution is to introduce a new class, let's call it
NonSymbolDocEmbeddingHandler
. This class can be similar in structure toSymbolDocEmbeddingHandler
but would be specifically designed to handle non-symbol documents.We can treat each non-symbol document as an individual entity that has its own embeddings. We can store these embeddings in the database just like we do for symbols. The document's name (or path) can serve as its identifier.
Here's a rough blueprint for the
NonSymbolDocEmbeddingHandler
class:By incorporating such a system, we would be able to create and retrieve embeddings for non-symbol documents, integrating them into our current workflow.
Points to Consider:
A mechanism is needed to detect and handle updates in the non-symbol documents, similar to how we handle symbol source code changes.
A strategy for identifying when to consider non-symbol documentation in the retrieval process. Perhaps certain queries or contexts can trigger the consideration of these documents.
Performance implications: The addition of non-symbol documents could significantly increase the amount of data stored in the database. This might require optimizations or changes to how we store and retrieve embeddings.
Tasks:
NonSymbolDocEmbeddingHandler
.Your feedback and suggestions are welcome to help refine this preliminary solution.
As always, don't hesitate to ask if you have any questions or need further clarification. Your contributions to this project are highly valued!
The text was updated successfully, but these errors were encountered: