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

Myscale/improve string pattern match #6737

Closed

Conversation

mpskex
Copy link
Contributor

@mpskex mpskex commented Jun 26, 2023

  • Description: Improved prompts for comparator LIKE and CONTAIN. They are ambiguous under some circumstances like "Answer this questions using papers published by Geoffrey Hinton". In that example LLM tends to use LIKE instead of CONTAIN to column authors, which is actually a column with type list of strings.

We revised the prompt to address this problem:

  1. Changed prompt for comparator LIKE to string_pattern_like
  2. Changed prompt for comparator CONTAIN to list_contain

@hwchase17

@vercel
Copy link

vercel bot commented Jun 26, 2023

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

1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
langchain ⬜️ Ignored (Inspect) Jul 6, 2023 8:00am

CONTAIN = "contain"
LIKE = "like"
CONTAIN = "list_contain"
LIKE = "string_pattern_like"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this name still feels ambiguous to me, what is the LIKE comparison doing again? is it a regex match?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is just doing something like column LIKE '%pattern%'.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I think this function should be bounded with datatypes. Unfortunately I didn't find any place to insert the allowed datatypes with those functions. Do you have better idea?

We also explored some new ways to implement self-query retriever with openai's function call. We found pretrained LLMs are good SQL translator so it is probably a good new to SQL based vector databases.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I probably misunderstand the issue. Do you mean the LIKE is ambiguous? Perhaps SUBSTRING_MATCH would be a better fit?

@mpskex mpskex requested a review from dev2049 June 27, 2023 06:28
@dosubot dosubot bot added the 🤖:improvement Medium size change to existing code to handle new use-cases label Jul 14, 2023
baskaryan pushed a commit that referenced this pull request Sep 7, 2023
Squashed from #7454 with updated features

We have separated the `SQLDatabseChain` from `VectorSQLDatabseChain` and
put everything into `experimental/`.

Below is the original PR message from #7454.

-------

We have been working on features to fill up the gap among SQL, vector
search and LLM applications. Some inspiring works like self-query
retrievers for VectorStores (for example
[Weaviate](https://python.langchain.com/en/latest/modules/indexes/retrievers/examples/weaviate_self_query.html)
and
[others](https://python.langchain.com/en/latest/modules/indexes/retrievers/examples/self_query.html))
really turn those vector search databases into a powerful knowledge
base! 🚀🚀

We are thinking if we can merge all in one, like SQL and vector search
and LLMChains, making this SQL vector database memory as the only source
of your data. Here are some benefits we can think of for now, maybe you
have more 👀:

With ALL data you have: since you store all your pasta in the database,
you don't need to worry about the foreign keys or links between names
from other data source.
Flexible data structure: Even if you have changed your schema, for
example added a table, the LLM will know how to JOIN those tables and
use those as filters.
SQL compatibility: We found that vector databases that supports SQL in
the marketplace have similar interfaces, which means you can change your
backend with no pain, just change the name of the distance function in
your DB solution and you are ready to go!

### Issue resolved:
- [Feature Proposal: VectorSearch enabled
SQLChain?](#5122)

### Change made in this PR:
- An improved schema handling that ignore `types.NullType` columns 
- A SQL output Parser interface in `SQLDatabaseChain` to enable Vector
SQL capability and further more
- A Retriever based on `SQLDatabaseChain` to retrieve data from the
database for RetrievalQAChains and many others
- Allow `SQLDatabaseChain` to retrieve data in python native format
- Includes PR #6737 
- Vector SQL Output Parser for `SQLDatabaseChain` and
`SQLDatabaseChainRetriever`
- Prompts that can implement text to VectorSQL
- Corresponding unit-tests and notebook

### Twitter handle: 
- @MyScaleDB

### Tag Maintainer:
Prompts / General: @hwchase17, @baskaryan
DataLoaders / VectorStores / Retrievers: @rlancemartin, @eyurtsev

### Dependencies:
No dependency added
@mpskex
Copy link
Contributor Author

mpskex commented Sep 7, 2023

Won't fix for now and waiting for dynamic operator prompting strategy.

@mpskex mpskex closed this Sep 7, 2023
rsharath pushed a commit to getjavelin/langchain that referenced this pull request Sep 8, 2023
Squashed from langchain-ai#7454 with updated features

We have separated the `SQLDatabseChain` from `VectorSQLDatabseChain` and
put everything into `experimental/`.

Below is the original PR message from langchain-ai#7454.

-------

We have been working on features to fill up the gap among SQL, vector
search and LLM applications. Some inspiring works like self-query
retrievers for VectorStores (for example
[Weaviate](https://python.langchain.com/en/latest/modules/indexes/retrievers/examples/weaviate_self_query.html)
and
[others](https://python.langchain.com/en/latest/modules/indexes/retrievers/examples/self_query.html))
really turn those vector search databases into a powerful knowledge
base! 🚀🚀

We are thinking if we can merge all in one, like SQL and vector search
and LLMChains, making this SQL vector database memory as the only source
of your data. Here are some benefits we can think of for now, maybe you
have more 👀:

With ALL data you have: since you store all your pasta in the database,
you don't need to worry about the foreign keys or links between names
from other data source.
Flexible data structure: Even if you have changed your schema, for
example added a table, the LLM will know how to JOIN those tables and
use those as filters.
SQL compatibility: We found that vector databases that supports SQL in
the marketplace have similar interfaces, which means you can change your
backend with no pain, just change the name of the distance function in
your DB solution and you are ready to go!

### Issue resolved:
- [Feature Proposal: VectorSearch enabled
SQLChain?](langchain-ai#5122)

### Change made in this PR:
- An improved schema handling that ignore `types.NullType` columns 
- A SQL output Parser interface in `SQLDatabaseChain` to enable Vector
SQL capability and further more
- A Retriever based on `SQLDatabaseChain` to retrieve data from the
database for RetrievalQAChains and many others
- Allow `SQLDatabaseChain` to retrieve data in python native format
- Includes PR langchain-ai#6737 
- Vector SQL Output Parser for `SQLDatabaseChain` and
`SQLDatabaseChainRetriever`
- Prompts that can implement text to VectorSQL
- Corresponding unit-tests and notebook

### Twitter handle: 
- @MyScaleDB

### Tag Maintainer:
Prompts / General: @hwchase17, @baskaryan
DataLoaders / VectorStores / Retrievers: @rlancemartin, @eyurtsev

### Dependencies:
No dependency added
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤖:improvement Medium size change to existing code to handle new use-cases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants