Submission checklist
Package (Required)
Feature Description
I would like LangChain to support native document reranking through the existing langchain-fireworks partner package.
This feature would introduce a FireworksRerank implementation based on LangChain's BaseDocumentCompressor abstraction, allowing Fireworks reranking models to be used directly within LangChain retrieval and RAG pipelines.
The reranker would accept a query and a collection of LangChain Document objects, send the relevant information to the Fireworks reranking API, and return the documents reordered according to their relevance.
This would provide a first-class Fireworks integration for document reranking while remaining compatible with LangChain's existing document compression and retrieval interfaces.
Use Case
I'm trying to build a RAG application using Fireworks as part of the retrieval and generation workflow.
A typical retrieval pipeline first retrieves a larger set of candidate documents and then uses a reranking step to identify which documents are most relevant to the user's query. Having a native Fireworks reranker would make it possible to add this step directly to an existing LangChain retrieval pipeline.
Currently, I have to work around this by implementing a custom integration around the Fireworks API or introducing another provider specifically for reranking. This adds unnecessary dependencies and provider-specific configuration to applications that are already using Fireworks.
This feature would help users integrate Fireworks reranking into existing LangChain retrieval pipelines without having to maintain custom wrappers or use a separate reranking provider.
Proposed Solution
I think this could be implemented by adding a new rerank.py module to the existing libs/partners/fireworks/langchain_fireworks/ package.
The module could expose a FireworksRerank class inheriting from BaseDocumentCompressor. The implementation would send the query and candidate documents to the Fireworks reranking API, process the returned relevance information, and return the original Document objects in their new ranking order while preserving their metadata.
The API could look like:
from typing import Any, Sequence
from langchain_core.documents import BaseDocumentCompressor, Document
from pydantic import ConfigDict
class FireworksRerank(BaseDocumentCompressor):
"""Document reranker powered by Fireworks."""
model: str
model_config = ConfigDict(
extra="forbid",
arbitrary_types_allowed=True,
)
def compress_documents(
self,
documents: Sequence[Document],
query: str,
callbacks: Any = None,
) -> Sequence[Document]:
"""Rerank documents according to their relevance to the query."""
...The resulting implementation could then be used with existing LangChain contextual compression workflows:
from langchain.retrievers.contextual_compression import ContextualCompressionRetriever
from langchain_fireworks import FireworksRerank
compressor = FireworksRerank()
compression_retriever = ContextualCompressionRetriever(
base_compressor=compressor, base_retriever=retriever
)
compressed_docs = compression_retriever.invoke(
"Your-query-here"
)This approach would keep the functionality within the existing langchain-fireworks package and reuse LangChain's established document compression abstraction rather than introducing a new retrieval interface.
Alternatives Considered
I've considered using a generic reranking wrapper or integrating another provider's reranking implementation into the retrieval pipeline.
Alternative approaches I considered:
- Building a custom wrapper around the Fireworks reranking API.
- Using a separate third-party reranking provider alongside Fireworks.
- Implementing the functionality outside the existing
langchain-fireworks partner package.
These approaches would work around the missing integration, but they introduce additional dependencies, configuration, and provider-specific code.
Adding the functionality directly to langchain-fireworks would provide a more consistent experience and allow the reranker to integrate naturally with LangChain's existing BaseDocumentCompressor and contextual compression APIs.
Additional Context
The proposed implementation follows the existing pattern used by LangChain's provider-specific reranking integrations, such as langchain-cohere.
The intended retrieval flow would be:
User Query
│
▼
Retriever
│
▼
Candidate Documents
│
▼
FireworksRerank
│
▼
Relevant Documents
│
▼
LLM
│
▼
Response
The main purpose of this feature is to make Fireworks reranking available through the standard LangChain document compression interface, allowing it to be composed with existing retrieval components.
The implementation would remain contained within the existing Fireworks partner package and would not require changes to LangChain's core retrieval abstractions.
Related issues: #38937
Submission checklist
Package (Required)
Feature Description
I would like LangChain to support native document reranking through the existing
langchain-fireworkspartner package.This feature would introduce a
FireworksRerankimplementation based on LangChain'sBaseDocumentCompressorabstraction, allowing Fireworks reranking models to be used directly within LangChain retrieval and RAG pipelines.The reranker would accept a query and a collection of LangChain
Documentobjects, send the relevant information to the Fireworks reranking API, and return the documents reordered according to their relevance.This would provide a first-class Fireworks integration for document reranking while remaining compatible with LangChain's existing document compression and retrieval interfaces.
Use Case
I'm trying to build a RAG application using Fireworks as part of the retrieval and generation workflow.
A typical retrieval pipeline first retrieves a larger set of candidate documents and then uses a reranking step to identify which documents are most relevant to the user's query. Having a native Fireworks reranker would make it possible to add this step directly to an existing LangChain retrieval pipeline.
Currently, I have to work around this by implementing a custom integration around the Fireworks API or introducing another provider specifically for reranking. This adds unnecessary dependencies and provider-specific configuration to applications that are already using Fireworks.
This feature would help users integrate Fireworks reranking into existing LangChain retrieval pipelines without having to maintain custom wrappers or use a separate reranking provider.
Proposed Solution
I think this could be implemented by adding a new
rerank.pymodule to the existinglibs/partners/fireworks/langchain_fireworks/package.The module could expose a
FireworksRerankclass inheriting fromBaseDocumentCompressor. The implementation would send the query and candidate documents to the Fireworks reranking API, process the returned relevance information, and return the originalDocumentobjects in their new ranking order while preserving their metadata.The API could look like:
The resulting implementation could then be used with existing LangChain contextual compression workflows:
This approach would keep the functionality within the existing
langchain-fireworkspackage and reuse LangChain's established document compression abstraction rather than introducing a new retrieval interface.Alternatives Considered
I've considered using a generic reranking wrapper or integrating another provider's reranking implementation into the retrieval pipeline.
Alternative approaches I considered:
langchain-fireworkspartner package.These approaches would work around the missing integration, but they introduce additional dependencies, configuration, and provider-specific code.
Adding the functionality directly to
langchain-fireworkswould provide a more consistent experience and allow the reranker to integrate naturally with LangChain's existingBaseDocumentCompressorand contextual compression APIs.Additional Context
The proposed implementation follows the existing pattern used by LangChain's provider-specific reranking integrations, such as langchain-cohere.
The intended retrieval flow would be:
The main purpose of this feature is to make Fireworks reranking available through the standard LangChain document compression interface, allowing it to be composed with existing retrieval components.
The implementation would remain contained within the existing Fireworks partner package and would not require changes to LangChain's core retrieval abstractions.
Related issues: #38937