langchain.schema.vectorstore.VectorStore

[peachkeel]

Is there some reason why the project cannot use the langchain.schema.vectorstore.VectorStore abstraction in lieu of Ragna's VectorDatabaseSourceStorage class? LangChain has so many adapters already written, including ones for Chroma and LanceDB, that it seems like a shame not to leverage that work here in some fashion.

See also:
https://api.python.langchain.com/en/latest/schema/langchain.schema.vectorstore.VectorStore.html
https://python.langchain.com/docs/integrations/vectorstores

[pmeier]

The reason is twofold:

1. Right now our policy is to only have components in the main library that don't require additional infrastructure. Meaning, requirements in the form of packages that needed to be installed as well as environment variables to be set is fine. We can easily check those and thus give the user an indication if their configuration is "valid".

   For infrastructure this is not so easy. How would we check if some instance of whatever vector store is running on your cluster?

   I agree that this policy is a little restrictive and we might change it later on. At least we should have a "recipe catalog" for these use cases.

   Anyway, this policy currently excludes most of the vector stores that langchain has.

2. We had very bad experiences with langchain in the past. Everything is buried under multiple layers of abstraction and really hard to properly configure if you want to go beyond the defaults. Peeking at their implementation, I see that some of our pain points that we had ~6 months ago are resolved.

   Still, just from my quick peek I see "standardization" issues, that would make it hard for us to reuse:

   • langchain Chroma puts all documents into one collection where we have a new collection per chat:

     ragna/ragna/source_storages/_chroma.py

     Lines 44 to 46 in dc497ef

     	collection = self._client.create_collection(
     	str(chat_id), embedding_function=self._embedding_function
     	)

   • langchain LanceDB requires a connection to be established on the outside and similar to Chroma above, puts everything into one table.

   I don't see a hard barrier here that would prevent us from actually re-using their code. However, given the difficulties doing that and on the flip side the simplicity of our implementation, I currently don't see a reason for doing that.