Cómo LangChain implementa autoconsultas
LangChain es una biblioteca de código abierto superpopular para la orquestación de LLM. Recientemente, añadieron el recuperador “Self Query”. El recuperador “Self Query” te permite usar LangChain para consultar una base de datos vectorial como Milvus. Veamos cómo se implementa este recuperador de autoconsulta. Cubrimos las líneas 189 a 233 del archivo base.py en la carpeta self-query. Esta publicación también cubre from_llm, el único método de clase.
En esta publicación, cubriremos:
- La definición del método de clase Self Query
- El análisis de los parámetros de Self-Query
- La creación de la cadena LLM
- La devolución de un recuperador Self Query
Definición del método de clase self query
El único método de clase para la clase base self query es from_llm. Hay ocho parámetros especificados y uno para permitirnos pasar argumentos de palabra clave (kwargs). Es posible que notes que el primer “parámetro” de la clase es cls. Si no tienes formación formal en Python, la diferencia entre cls y self es simplemente una cuestión de estilo y uso, según PEP8.
Hay cuatro parámetros requeridos para crear una clase self query: llm, vectorstore, document_contents y metadata_field_info.
llmsirve para pasar un modelo de lenguaje.vectorstorese utiliza para pasar un almacén vectorial como Milvus.- El nombre del parámetro
document_contentses un poco engañoso. No se refiere al contenido real de los documentos almacenados, sino a una breve descripción de ellos. metadata_field_infoes una secuencia de objetosAttributeInfo, diccionarios que contienen información sobre los datos en la base de datos vectorial.
Después de los parámetros requeridos vienen los parámetros opcionales. También hay cuatro: structured_query_translator, chain_kwargs, enable_limit y use_original_query. Los dos primeros tienen como valor predeterminado None, y el segundo False.
El parámetro structured_query_translator nos permite pasar un traductor. Los traductores convierten expresiones en instrucciones de filtro para cada base de datos vectorial. Estas instrucciones de filtro se pasan a chain_kwargs como “allowed_comparators” o “allowed_operators,” según su uso. Cada almacén vectorial tiene comparadores y operadores únicos. Por ejemplo, estas son las expresiones booleanas permitidas para Milvus.
Usando el parámetro enable_limit, podemos decidir si habilitar el operador limit. Este operador es una función nativa de LangChain que restringe el número de documentos que se van a recuperar. El parámetro final es use_original_query, que determina si queremos utilizar nuestra consulta original o la generada por LLM.
@classmethod
def from_llm(
cls,
llm: BaseLanguageModel,
vectorstore: VectorStore,
document_contents: str,
metadata_field_info: Sequence[Union[AttributeInfo, dict]],
structured_query_translator: Optional[Visitor] = None,
chain_kwargs: Optional[Dict] = None,
enable_limit: bool = False,
use_original_query: bool = False,
**kwargs: Any,
) -> "SelfQueryRetriever":
Análisis de los parámetros de self query
Permíteme explicar cómo manejamos los parámetros. En función de los parámetros pasados, usamos una serie de instrucciones if para determinar qué hacer.
Primero, comprobamos si ya hay un traductor de consultas estructuradas definido. Si no, usamos el traductor integrado para el almacén vectorial definido.
A continuación, comprobamos los argumentos de palabra clave de la cadena. Podemos establecerlos en los valores pasados o mantenerlos en un diccionario vacío. Continuamos comprobando estos argumentos para las dos siguientes sentencias if. Las dos claves que buscamos son los comparadores y operadores permitidos. Estas claves determinan cómo podemos escribir las expresiones de filtro.
if structured_query_translator is None:
structured_query_translator = _get_builtin_translator(vectorstore)
chain_kwargs = chain_kwargs or {}
if (
"allowed_comparators" not in chain_kwargs
and structured_query_translator.allowed_comparators is not None
):
chain_kwargs[
"allowed_comparators"
] = structured_query_translator.allowed_comparators
if (
"allowed_operators" not in chain_kwargs
and structured_query_translator.allowed_operators is not None
):
chain_kwargs[
"allowed_operators"
] = structured_query_translator.allowed_operators
Creación de la cadena LLM
Con todo definido, ahora podemos crear nuestro constructor de consultas. En este paso, hacemos una llamada a la función load_query_constructor_runnable desde los constructores de consultas. Profundizaremos en este paso en otro artículo.
Necesitamos pasar el LLM, la descripción del contenido del documento, los campos de metadatos, si queremos o no habilitar el límite, y los argumentos de palabra clave para pasar a la cadena. Después de haber definido todos estos elementos, la función devuelve un objeto Runnable, que nos permite ejecutar un script especificado.
query_constructor = load_query_constructor_runnable(
llm,
document_contents,
metadata_field_info,
enable_limit=enable_limit,
**chain_kwargs,
)
Devolución de un recuperador de autoconsulta
Al final de este método de clase, debemos devolver el recuperador de autoconsulta. Este método devuelve una instancia de la clase de autoconsulta. Pasamos el constructor de consultas que acabamos de definir, junto con el almacén vectorial pasado, si usar o no la consulta original, el traductor y una lista de argumentos de palabra clave.
return cls(
query_constructor=query_constructor,
vectorstore=vectorstore,
use_original_query=use_original_query,
structured_query_translator=structured_query_translator,
**kwargs,
)
Resumen de cómo LangChain implementa la autoconsulta
En este artículo, hemos cubierto cómo LangChain implementa un concepto que etiqueta como “autoconsulta”. Es una forma de crear una aplicación sencilla de generación aumentada por recuperación (RAG). Utiliza todos los mismos componentes: un LLM, una base de datos vectorial y algunas indicaciones para interactuar con el LLM.
La autoconsulta es un bloque de código bastante grande en LangChain, pero este artículo cubre específicamente el método de clase from_llm. Este método nos permite crear una aplicación RAG pasando solo cuatro campos obligatorios. El LLM, la base de datos vectorial, una descripción de los documentos y la información de metadatos. ¿Quieres aprender más sobre los LLM y las bases de datos vectoriales? Ven a charlar con nosotros en Discord.
Sigue leyendo
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
Top 10 Context Engineering Techniques You Should Know for Production RAG
A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.
Vector Databases vs. Key-Value Databases
Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.