community: fix AzureSearch vectorstore asyncronous methods

[thedavgar]

Description
Fix the asyncronous methods to retrieve documents from AzureSearch VectorStore. The previous changes from this commit create a similar code for the syncronous methods and the asyncronous ones but the asyncronous client return an asyncronous iterator "AsyncSearchItemPaged" as said in the issue #24740.
To solve this issue, the syncronous iterators in asyncronous methods where changed to asyncronous iterators.

@chrislrobert said in this comment that there was a still a flaw due to with blocks that close the client after each call. I removed this with blocks in the async_client following the same pattern as the sync client.

In order to close up the connections, a del method is included to gently close up clients once the vectorstore object is destroyed.

Issue: #24740 and #24064
Dependencies: No new dependencies for this change

Example notebook: I created a notebook just to test the changes work and gives the same results as the syncronous methods for vector and hybrid search. With these changes, the asyncronous methods in the retriever work as well.

Lint and test: Passes the tests and the linter

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
langchain	⬜️ Ignored (Inspect)	Visit Preview		Aug 1, 2024 3:51pm

[chrislrobert]

Thanks, @thedavgar, for tackling this!

From a quick look at the code, it looks like this should allow accessing search results, multiple calls, etc. Just two questions:

1. Is anything special needed to ensure that the async_client is eventually cleaned up (closed)?
2. There are still with blocks in aadd_embeddings and adelete, which leaves those as kind of one-way doors: they'll suffer the same issue where subsequent calls will fire exceptions about the client being closed. I can see focusing this fix on the actual search cases, but is there an issue somewhere to clean that up too? Shame to leave it broken.

Thanks again!

[thedavgar]

Thanks, @thedavgar, for tackling this!

From a quick look at the code, it looks like this should allow accessing search results, multiple calls, etc. Just two questions:

1. Is anything special needed to ensure that the async_client is eventually cleaned up (closed)?
2. There are still with blocks in aadd_embeddings and adelete, which leaves those as kind of one-way doors: they'll suffer the same issue where subsequent calls will fire exceptions about the client being closed. I can see focusing this fix on the actual search cases, but is there an issue somewhere to clean that up too? Shame to leave it broken.

Thanks again!

1. The best way could be to close the clients once the vectorstore instance is closed.
2. Thank you telling me the missing methods that still have the with block. I will try to tackle it.

[thedavgar]

The async code works

[chrislrobert]

@thedavgar, this all looks good to me — but I have to say that I'm not an official reviewer for LangChain and don't know their standards and practices. If possible, I would ask @eyurtsev and/or @baskaryan to review, as they were involved in the original async PR #22075.

[thedavgar]

Hi @baskaryan,

I’m looking forward to approving this PR for the next LangChain community version. I’ve followed the steps in the contributor guide, but I’m not sure how to assign or approve the code.

Thanks in advance!

[thedavgar]

Hi @isahers1, the async version of AzureSearch vectorstore continues to fail. This PR solves several issues in the code. Could you help me get these changes approved to have it fixed for the next version of langchain community?

[ND-code-ai]

Amazing! For me your changes also fixed some faulty behaviour in the @search.score calculation where retrieved Doc objects would contain unexpected extremely low scores