mirror of
https://github.com/hwchase17/langchain.git
synced 2025-08-07 12:06:43 +00:00
docs: fix some typos (#27519)
* Fix some typos * Add some missing links
This commit is contained in:
Eugene Yurtsev
GitHub
parent
13f7d2d58d
commit
aa0b25cb2a
@ -6,11 +6,11 @@
|
||||
* [Documents](/docs/concepts/retrievers/#interface)
|
||||
|
||||
:::
|
||||
:::info[Note]
|
||||
|
||||
This conceptual overview focuses on text-based embedding models.
|
||||
Embedding models can also be [multi-modal](https://cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-multimodal-embeddings), allowing for the embedding of a wide variety of data types.
|
||||
|
||||
:::info[Note]
|
||||
This conceptual overview focuses on text-based embedding models.
|
||||
|
||||
Embedding models can also be [multimodal](/docs/concepts/multimodality) though such models are not currently supported by LangChain.
|
||||
:::
|
||||
|
||||
## Overview
|
||||
@ -154,9 +154,9 @@ However, ColBERT does come with some trade-offs:
|
||||
- **Increased computational cost**: Processing and storing token-level embeddings requires more resources.
|
||||
- **Complexity**: Implementing and optimizing ColBERT can be more challenging than simpler embedding models.
|
||||
|
||||
| Name | When to use | Description |
|
||||
|-------------------|----------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [ColBERT](/docs/integrations/providers/ragatouille/#using-colbert-as-a-reranker) | When higher granularity embeddings are needed. | ColBERT uses contextually influenced embeddings for each token in the document and query to get a granular query-document similarity score. [Paper](https://arxiv.org/abs/2112.01488). |
|
||||
| Name | When to use | Description |
|
||||
|----------------------------------------------------------------------------------|------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [ColBERT](/docs/integrations/providers/ragatouille/#using-colbert-as-a-reranker) | When higher granularity embeddings are needed. | ColBERT uses contextually influenced embeddings for each token in the document and query to get a granular query-document similarity score. [Paper](https://arxiv.org/abs/2112.01488). |
|
||||
|
||||
:::tip
|
||||
|
||||
|
||||
@ -63,12 +63,12 @@ Here are some key benefits of using models for query analysis in unstructured da
|
||||
|
||||
Various techniques have been developed to leverage models for query re-writing, including:
|
||||
|
||||
| Name | When to use | Description |
|
||||
|---------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Multi-query](/docs/how_to/MultiQueryRetriever/) | When you want to ensure high recall in retrieval by providing multiple pharsings of a question. | Rewrite the user question with multiple pharsings, retrieve documents for each rewritten question, return the unique documents for all queries. |
|
||||
| [Decomposition](https://github.com/langchain-ai/rag-from-scratch/blob/main/rag_from_scratch_5_to_9.ipynb) | When a question can be broken down into smaller subproblems. | Decompose a question into a set of subproblems / questions, which can either be solved sequentially (use the answer from first + retrieval to answer the second) or in parallel (consolidate each answer into final answer). |
|
||||
| [Step-back](https://github.com/langchain-ai/rag-from-scratch/blob/main/rag_from_scratch_5_to_9.ipynb) | When a higher-level conceptual understanding is required. | First prompt the LLM to ask a generic step-back question about higher-level concepts or principles, and retrieve relevant facts about them. Use this grounding to help answer the user question. [Paper](https://arxiv.org/pdf/2310.06117). |
|
||||
| [HyDE](https://github.com/langchain-ai/rag-from-scratch/blob/main/rag_from_scratch_5_to_9.ipynb) | If you have challenges retrieving relevant documents using the raw user inputs. | Use an LLM to convert questions into hypothetical documents that answer the question. Use the embedded hypothetical documents to retrieve real documents with the premise that doc-doc similarity search can produce more relevant matches. [Paper](https://arxiv.org/abs/2212.10496). |
|
||||
| Name | When to use | Description |
|
||||
|-----------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Multi-query](/docs/how_to/MultiQueryRetriever/) | When you want to ensure high recall in retrieval by providing multiple pharsings of a question. | Rewrite the user question with multiple pharsings, retrieve documents for each rewritten question, return the unique documents for all queries. |
|
||||
| [Decomposition](https://github.com/langchain-ai/rag-from-scratch/blob/main/rag_from_scratch_5_to_9.ipynb) | When a question can be broken down into smaller subproblems. | Decompose a question into a set of subproblems / questions, which can either be solved sequentially (use the answer from first + retrieval to answer the second) or in parallel (consolidate each answer into final answer). |
|
||||
| [Step-back](https://github.com/langchain-ai/rag-from-scratch/blob/main/rag_from_scratch_5_to_9.ipynb) | When a higher-level conceptual understanding is required. | First prompt the LLM to ask a generic step-back question about higher-level concepts or principles, and retrieve relevant facts about them. Use this grounding to help answer the user question. [Paper](https://arxiv.org/pdf/2310.06117). |
|
||||
| [HyDE](https://github.com/langchain-ai/rag-from-scratch/blob/main/rag_from_scratch_5_to_9.ipynb) | If you have challenges retrieving relevant documents using the raw user inputs. | Use an LLM to convert questions into hypothetical documents that answer the question. Use the embedded hypothetical documents to retrieve real documents with the premise that doc-doc similarity search can produce more relevant matches. [Paper](https://arxiv.org/abs/2212.10496). |
|
||||
|
||||
As an example, query decomposition can simply be accomplished using prompting and a structured output that enforces a list of sub-questions.
|
||||
These can then be run sequentially or in parallel on a downstream retrieval system.
|
||||
@ -121,11 +121,11 @@ This translation is crucial for effectively interacting with various types of da
|
||||
|
||||
These approaches leverage models to bridge the gap between user intent and the specific query requirements of different data storage systems. Here are some popular techniques:
|
||||
|
||||
| Name | When to Use | Description |
|
||||
|---------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Self Query](/docs/how_to/self_query/) | If users are asking questions that are better answered by fetching documents based on metadata rather than similarity with the text. | This uses an LLM to transform user input into two things: (1) a string to look up semantically, (2) a metadata filter to go along with it. This is useful because oftentimes questions are about the METADATA of documents (not the content itself). |
|
||||
| [Text to SQL](/docs/tutorials/sql_qa/) | If users are asking questions that require information housed in a relational database, accessible via SQL. | This uses an LLM to transform user input into a SQL query. |
|
||||
| [Text-to-Cypher](/docs/tutorials/graph/) | If users are asking questions that require information housed in a graph database, accessible via Cypher. | This uses an LLM to transform user input into a Cypher query. |
|
||||
| Name | When to Use | Description |
|
||||
|------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Self Query](/docs/how_to/self_query/) | If users are asking questions that are better answered by fetching documents based on metadata rather than similarity with the text. | This uses an LLM to transform user input into two things: (1) a string to look up semantically, (2) a metadata filter to go along with it. This is useful because oftentimes questions are about the METADATA of documents (not the content itself). |
|
||||
| [Text to SQL](/docs/tutorials/sql_qa/) | If users are asking questions that require information housed in a relational database, accessible via SQL. | This uses an LLM to transform user input into a SQL query. |
|
||||
| [Text-to-Cypher](/docs/tutorials/graph/) | If users are asking questions that require information housed in a graph database, accessible via Cypher. | This uses an LLM to transform user input into a Cypher query. |
|
||||
|
||||
As an example, here is how to use the `SelfQueryRetriever` to convert natural language queries into metadata filters.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
## Overview
|
||||
|
||||
Many different types of retrieval systems exist, including vectorstores, graph databases, and relational databases.
|
||||
With the rise on popuarity of large language models, retrieval systems have become an important component in AI application (e.g., [RAG](/docs/concepts/rag/)).
|
||||
With the rise on popularity of large language models, retrieval systems have become an important component in AI application (e.g., [RAG](/docs/concepts/rag/)).
|
||||
Because of their importance and variability, LangChain provides a uniform interface for interacting with different types of retrieval systems.
|
||||
The LangChain [retriever](/docs/concepts/retrievers/) interface is straightforward:
|
||||
|
||||
@ -77,7 +77,7 @@ For example, you can build a retriever for a SQL database using text-to-SQL conv
|
||||
|
||||
As discussed in our conceptual review of [retrieval](/docs/concepts/retrieval/), many search engines are based upon matching words in a query to the words in each document.
|
||||
[BM25](https://en.wikipedia.org/wiki/Okapi_BM25#:~:text=BM25%20is%20a%20bag%2Dof,slightly%20different%20components%20and%20parameters.) and [TF-IDF](https://en.wikipedia.org/wiki/Tf%E2%80%93idf) are [two popular lexical search algorithms](https://cameronrwolfe.substack.com/p/the-basics-of-ai-powered-vector-search?utm_source=profile&utm_medium=reader2).
|
||||
LangChain has retreivers for many popular lexical search algorithms / engines.
|
||||
LangChain has retrievers for many popular lexical search algorithms / engines.
|
||||
|
||||
:::info[Further reading]
|
||||
|
||||
@ -117,7 +117,7 @@ This motivates the concept of re-ranking, which takes the output of multiple ret
|
||||
|
||||
### Source Document Retention
|
||||
|
||||
Many retriers utilize some kind of index to make documents easily searchable.
|
||||
Many retrievers utilize some kind of index to make documents easily searchable.
|
||||
The process of indexing can include a transformation step (e.g., vectorstores often use document splitting).
|
||||
Whatever transformation is used, can be very useful to retain a link between the *transformed document* and the original, giving the retriever the ability to return the *original* document.
|
||||
|
||||
@ -131,10 +131,10 @@ LangChain has two different retrievers that can be used to address this challeng
|
||||
The [Multi-Vector](/docs/how_to/multi_vector/) retriever allows the user to use any document transformation (e.g., use an LLM to write a summary of the document) for indexing while retaining linkage to the source document.
|
||||
The [ParentDocument](/docs/how_to/parent_document_retriever/) retriever links document chunks from a text-splitter transformation for indexing while retaining linkage to the source document.
|
||||
|
||||
| Name | Index Type | Uses an LLM | When to Use | Description |
|
||||
|---------------------------|------------------------------|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [ParentDocument](/docs/how_to/parent_document_retriever/) | Vector store + Document Store | No | If your pages have lots of smaller pieces of distinct information that are best indexed by themselves, but best retrieved all together. | This involves indexing multiple chunks for each document. Then you find the chunks that are most similar in embedding space, but you retrieve the whole parent document and return that (rather than individual chunks). |
|
||||
| [Multi Vector](/docs/how_to/multi_vector/) | Vector store + Document Store | Sometimes during indexing | If you are able to extract information from documents that you think is more relevant to index than the text itself. | This involves creating multiple vectors for each document. Each vector could be created in a myriad of ways - examples include summaries of the text and hypothetical questions. |
|
||||
| Name | Index Type | Uses an LLM | When to Use | Description |
|
||||
|-----------------------------------------------------------|-------------------------------|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [ParentDocument](/docs/how_to/parent_document_retriever/) | Vector store + Document Store | No | If your pages have lots of smaller pieces of distinct information that are best indexed by themselves, but best retrieved all together. | This involves indexing multiple chunks for each document. Then you find the chunks that are most similar in embedding space, but you retrieve the whole parent document and return that (rather than individual chunks). |
|
||||
| [Multi Vector](/docs/how_to/multi_vector/) | Vector store + Document Store | Sometimes during indexing | If you are able to extract information from documents that you think is more relevant to index than the text itself. | This involves creating multiple vectors for each document. Each vector could be created in a myriad of ways - examples include summaries of the text and hypothetical questions. |
|
||||
|
||||
:::info[Further reading]
|
||||
|
||||
|
||||
@ -62,13 +62,13 @@ TODO: There are many other ways to define schemas (Dataclasses, TypedDicts, Cust
|
||||
|
||||
With a schema defined, we need a way to instruct the model to use it.
|
||||
While one approach is to include this schema in the prompt and *ask nicely* for the model to use it, this is not recommended.
|
||||
Several more powerful methods that utilites native features in the model provider's API are available.
|
||||
Several more powerful methods that utilities native features in the model provider's API are available.
|
||||
|
||||
### Using Tool Calling
|
||||
|
||||
Many [model providers support](/docs/integrations/chat/) tool calling, a concept discussed in more detail in our [tool calling guide](/docs/concepts/tool_calling/).
|
||||
In short, tool calling involves binding a tool to a model and, when appropriate, the model can *decide* to call this tool and ensure its response conforms to the tool's schema.
|
||||
With this in mind, the central concept is strightforward: *simply bind our schema to a model as a tool!*
|
||||
With this in mind, the central concept is straightforward: *simply bind our schema to a model as a tool!*
|
||||
Here is an example using the `ResponseFormatter` schema defined above:
|
||||
|
||||
```python
|
||||
@ -108,7 +108,7 @@ ai_msg.content
|
||||
```
|
||||
|
||||
One important point to flag: the model *still* returns a string, which needs to be parsed into a JSON object.
|
||||
This can, of course, simply use the `json` library or a JSON output parser if you need more adavanced functionality.
|
||||
This can, of course, simply use the `json` library or a JSON output parser if you need more advanced functionality.
|
||||
See this [how-to guide on the JSON output parser](/docs/how_to/output_parser_json) for more details.
|
||||
|
||||
```python
|
||||
@ -137,5 +137,7 @@ structured_output
|
||||
ResponseFormatter(answer="The powerhouse of the cell is the mitochondrion. Mitochondria are organelles that generate most of the cell's supply of adenosine triphosphate (ATP), which is used as a source of chemical energy.", followup_question='What is the function of ATP in the cell?')
|
||||
```
|
||||
|
||||
TODO: We need to explain the choice of implementation under the hood. Seems to be set with the `method` argument. How is default choosen? What if provider only has JSON mode? What inputs schemas are supported?
|
||||
TODO: We need to explain the choice of implementation under the hood. Seems to be set with the `method` argument. How is default chosen? What if provider only has JSON mode? What inputs schemas are supported?
|
||||
|
||||
|
||||
For more details on usage, see our [how-to guide](/docs/how_to/structured_output/#the-with_structured_output-method).
|
||||
|
||||
@ -1,12 +1,10 @@
|
||||
# Text Splitters
|
||||
|
||||
<span data-heading-keywords="embedding,embeddings"></span>
|
||||
|
||||
:::info[Prerequisites]
|
||||
|
||||
* [Documents](/docs/concepts/retrievers/#interface)
|
||||
* Tokenization
|
||||
|
||||
* Tokenization(/docs/concepts/tokens)
|
||||
:::
|
||||
|
||||
## Overview
|
||||
@ -35,9 +33,7 @@ There are several reasons to split documents:
|
||||
Now, the next question is *how* to split the documents into chunks! There are several strategies, each with its own advantages.
|
||||
|
||||
:::info[Further reading]
|
||||
|
||||
* See Greg Kamradt's [chunkviz](https://chunkviz.up.railway.app/) to visualize different splitting strategies discussed below.
|
||||
|
||||
:::
|
||||
|
||||
## Approaches
|
||||
@ -134,6 +130,6 @@ This technique helps create chunks that are more semantically coherent, potentia
|
||||
:::info[Further reading]
|
||||
|
||||
* See the how-to guide for [splitting text based on semantic meaning](/docs/how_to/semantic-chunker/).
|
||||
* See Greg Kamradt's [notebook ](https://github.com/FullStackRetrieval-com/RetrievalTutorials/blob/main/tutorials/LevelsOfTextSplitting/5_Levels_Of_Text_Splitting.ipynb) showcasing semantic splitting.
|
||||
* See Greg Kamradt's [notebook](https://github.com/FullStackRetrieval-com/RetrievalTutorials/blob/main/tutorials/LevelsOfTextSplitting/5_Levels_Of_Text_Splitting.ipynb) showcasing semantic splitting.
|
||||
|
||||
:::
|
||||
|
||||
@ -1,8 +1,14 @@
|
||||
# Tool Calling
|
||||
|
||||
:::info[Prerequisites]
|
||||
* [Tools](/docs/concepts/tools)
|
||||
* [Chat Models](/docs/concepts/chat_models)
|
||||
:::
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
Many AI applications interact directly with humans. In these cases, it is approrpiate for models to respond in natural langague.
|
||||
Many AI applications interact directly with humans. In these cases, it is appropriate for models to respond in natural language.
|
||||
But what about cases where we want a model to also interact *directly* with systems, such as databases or an API?
|
||||
These systems often have a particular input schema; for example, APIs frequently have a required payload structure.
|
||||
This need motivates the concept of *tool calling*. You can use [tool calling](https://platform.openai.com/docs/guides/function-calling/example-use-cases) to request model responses that match a particular schema.
|
||||
@ -15,9 +21,8 @@ You will sometimes hear the term `function calling`. We use this term interchang
|
||||
|
||||
## Key Concepts
|
||||
|
||||
**(1) Tool Creation:** The tool needs to be described to the model so that the model knows what arguments to provide when it decides to call the tool.
|
||||
TODO: @eyurtsev to elaborate. **(2) Tool Binding:** The tool needs to be connected to a model that supports tool calling.
|
||||
This gives the model awarenes of the tool and the associated input schema required by the tool.
|
||||
**(1) Tool Creation:** Use the [@tool](https://python.langchain.com/api_reference/core/tools/langchain_core.tools.convert.tool.html) decorator to create a [tool](/docs/concepts/tools). A tool is an association between a function and its schema.
|
||||
**(2) Tool Binding:** The tool needs to be connected to a model that supports tool calling. This gives the model awareness of the tool and the associated input schema required by the tool.
|
||||
**(3) Tool Calling:** When appropriate, the model can decide to call a tool and ensure its response conforms to the tool's input schema.
|
||||
**(4) Tool Execution:** The tool can be executed using the arguments provided by the model.
|
||||
|
||||
@ -28,7 +33,7 @@ This gives the model awarenes of the tool and the associated input schema requir
|
||||
This psuedo-code illustrates the recommended workflow for using tool calling.
|
||||
Created tools are passed to `.bind_tools()` method as a list.
|
||||
This model can be called, as usual. If a tool call is made, model's response will contain the tool call arguments.
|
||||
The tool call arguemtns can be passed directly to the tool.
|
||||
The tool call arguments can be passed directly to the tool.
|
||||
|
||||
```python
|
||||
# Tool creation
|
||||
@ -41,9 +46,23 @@ response = modelwtools.invoke(user_input)
|
||||
tool_output = my_tool(response.tool_calls)
|
||||
```
|
||||
|
||||
## Tool Creation
|
||||
## Tool Creation
|
||||
|
||||
TODO: @eyurtsev to add links and summary of the conceptual guide.
|
||||
The recommended way to create a tool is using the `@tool` decorator.
|
||||
|
||||
```python
|
||||
from langchain_core.tools import tool
|
||||
|
||||
@tool
|
||||
def multiply(a: int, b: int) -> int:
|
||||
"""Multiply a and b."""
|
||||
return a * b
|
||||
```
|
||||
|
||||
For more information about tool creation, please see:
|
||||
|
||||
* [Conceptual guide on tools](/docs/concepts/tools/)
|
||||
* [How to create custom tools](https://python.langchain.com/docs/how_to/custom_tools/)
|
||||
|
||||
## Tool Binding
|
||||
|
||||
@ -106,8 +125,6 @@ For more details on usage, see our [how-to guides](/docs/how_to/#tools)!
|
||||
|
||||
## Tool execution
|
||||
|
||||
TODO: @eyurtsev @vbarda let's discuss this. This should also link to tool execution in LangGraph.
|
||||
|
||||
## Best practices
|
||||
|
||||
When designing tools to be used by a model, it is important to keep in mind that:
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
# Vector stores
|
||||
|
||||
<span data-heading-keywords="vector,vectorstore,vectorstores,vector store,vector stores"></span>
|
||||
|
||||
:::info[Prerequisites]
|
||||
@ -13,7 +12,6 @@
|
||||
This conceptual overview focuses on text-based indexing and retrieval for simplicity.
|
||||
However, embedding models can be [multi-modal](https://cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-multimodal-embeddings)
|
||||
and vectorstores can be used to store and retrieve a variety of data types beyond text.
|
||||
|
||||
:::
|
||||
|
||||
## Overview
|
||||
@ -94,7 +92,7 @@ Second, there needs to be an algorithm to efficiently perform this similarity se
|
||||
|
||||
### Similarity metrics
|
||||
|
||||
A critical advange of embeddings vectors is they can be compared using many simple mathematical operations:
|
||||
A critical advantage of embeddings vectors is they can be compared using many simple mathematical operations:
|
||||
|
||||
- **Cosine Similarity**: Measures the cosine of the angle between two vectors.
|
||||
- **Euclidean Distance**: Measures the straight-line distance between two points.
|
||||
@ -105,10 +103,10 @@ As an example, Pinecone allows the user to select the [similarity metric on inde
|
||||
|
||||
```python
|
||||
pc.create_index(
|
||||
name=index_name,
|
||||
dimension=3072,
|
||||
metric="cosine",
|
||||
)
|
||||
name=index_name,
|
||||
dimension=3072,
|
||||
metric="cosine",
|
||||
)
|
||||
```
|
||||
|
||||
:::info[Further reading]
|
||||
@ -158,7 +156,7 @@ Vectorstore support for metadata filtering is typically dependent on the underly
|
||||
Here is example usage with [Pinecone](/docs/integrations/vectorstores/pinecone/#query-directly), showing that we filter for all documents that have the metadata key `source` with value `tweet`.
|
||||
|
||||
```python
|
||||
results = vector_store.similarity_search(
|
||||
results = vectorstore.similarity_search(
|
||||
"LangChain provides abstractions to make working with LLMs easy",
|
||||
k=2,
|
||||
filter={"source": "tweet"},
|
||||
@ -172,7 +170,7 @@ results = vector_store.similarity_search(
|
||||
|
||||
:::
|
||||
|
||||
## Advanced search and retreival techniques
|
||||
## Advanced search and retrieval techniques
|
||||
|
||||
While algorithms like HNSW provide the foundation for efficient similarity search in many cases, additional techniques can be employed to improve search quality and diversity.
|
||||
For example, [maximal marginal relevance](https://python.langchain.com/v0.1/docs/modules/model_io/prompts/example_selectors/mmr/) is a re-ranking algorithm used to diversify search results, which is applied after the initial similarity search to ensure a more diverse set of results.
|
||||
@ -180,9 +178,9 @@ As a second example, some [vector stores](/docs/integrations/retrievers/pinecone
|
||||
At the moment, there is no unified way to perform hybrid search using LangChain vectorstores, but it is generally exposed as a keyword argument that is passed in with `similarity_search`.
|
||||
See this [how-to guide on hybrid search](/docs/how_to/hybrid/) for more details.
|
||||
|
||||
| Name | When to use | Description |
|
||||
|-------------------|----------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Hybrid search](/docs/integrations/retrievers/pinecone_hybrid_search/) | When combining keyword-based and semantic similarity. | Hybrid search combines keyword and semantic similarity, marrying the benefits of both approaches. [Paper](https://arxiv.org/abs/2210.11934). |
|
||||
| [Maximal Marginal Relevance (MMR)](/docs/integrations/vectorstores/pinecone/#maximal-marginal-relevance-searches) | When needing to diversify search results. | MMR attempts to diversify the results of a search to avoid returning similar and redundant documents. |
|
||||
| Name | When to use | Description |
|
||||
|-------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Hybrid search](/docs/integrations/retrievers/pinecone_hybrid_search/) | When combining keyword-based and semantic similarity. | Hybrid search combines keyword and semantic similarity, marrying the benefits of both approaches. [Paper](https://arxiv.org/abs/2210.11934). |
|
||||
| [Maximal Marginal Relevance (MMR)](/docs/integrations/vectorstores/pinecone/#maximal-marginal-relevance-searches) | When needing to diversify search results. | MMR attempts to diversify the results of a search to avoid returning similar and redundant documents. |
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user