Как LangChain реализует самостоятельное формирование запросов
LangChain — это суперпопулярная open-source библиотека для оркестрации LLM. Недавно они добавили ретривер “Self Query”. Ретривер “Self Query” позволяет использовать LangChain для запросов к векторной базе данных, такой как Milvus. Давайте посмотрим, как реализован этот self-query ретривер. Мы рассмотрим строки с 189 по 233 файла base.py в папке self-query. В этом посте также рассматривается from_llm, единственный метод класса.
В этом посте мы рассмотрим:
- Определение метода класса Self Query
- Разбор параметров Self-Query
- Создание LLM Chain
- Возврат Self Query Retriever
Определение метода класса Self query
Единственный метод класса для базового класса self query — это from_llm. Есть восемь заданных параметров и один, позволяющий передавать именованные аргументы (kwargs). Вы можете заметить, что первый “параметр” класса — это cls. Если у вас нет формального обучения Python, разница между cls и self, согласно PEP8, сводится просто к стилю и использованию.
Для создания класса self query требуются четыре обязательных параметра: llm, vectorstore, document_contents и metadata_field_info.
llmиспользуется для передачи языковой модели.vectorstoreиспользуется для передачи векторного хранилища, такого как Milvus.- Название параметра
document_contentsнемного вводит в заблуждение. Оно относится не к фактическому содержимому сохраненных документов, а скорее к их краткому описанию. metadata_field_info— это последовательность объектовAttributeInfo, словарей, содержащих информацию о данных в векторной базе данных.
После обязательных параметров идут необязательные параметры. Их также четыре: structured_query_translator, chain_kwargs, enable_limit и use_original_query. Первые два по умолчанию равны None, а вторые — False.
Параметр structured_query_translator позволяет передать транслятор. Трансляторы преобразуют выражения в операторы фильтрации для каждой векторной базы данных. Эти операторы фильтрации передаются в chain_kwargs как “allowed_comparators” или “allowed_operators” в зависимости от их использования. У каждого векторного хранилища есть уникальные компараторы и операторы. Например, вот разрешенные булевы выражения для Milvus.
Используя параметр enable_limit, мы можем решить, включать ли оператор limit. Этот оператор является встроенной функцией LangChain, которая ограничивает количество документов, подлежащих извлечению. Последний параметр — use_original_query, который определяет, хотим ли мы использовать наш исходный запрос или запрос, сгенерированный 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":
Разбор параметров self query
Позвольте объяснить, как мы обрабатываем параметры. На основе переданных параметров мы используем серию операторов if, чтобы определить, что делать.
Сначала мы проверяем, существует ли уже определенный structured query translator. Если нет, мы используем встроенный транслятор для заданного векторного хранилища.
Далее мы проверяем именованные аргументы цепочки. Мы можем установить для них переданные значения или оставить пустым словарем. Мы продолжаем проверять эти аргументы в следующих двух операторах if. Два ключа, которые мы ищем, — это разрешенные компараторы и операторы. Эти ключи определяют, как мы можем записывать выражения фильтра.
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
Создание цепочки LLM
Когда всё определено, мы можем создать наш конструктор запросов. На этом шаге мы делаем вызов функции load_query_constructor_runnable из конструкторов запросов. Мы подробнее рассмотрим этот шаг в другой статье.
Нам нужно передать LLM, описание содержимого документа, поля метаданных, указать, хотим ли мы включить ограничение, и передать именованные аргументы в цепочку. После того как мы определили все эти элементы, функция возвращает объект Runnable, который позволяет нам выполнить указанный скрипт.
query_constructor = load_query_constructor_runnable(
llm,
document_contents,
metadata_field_info,
enable_limit=enable_limit,
**chain_kwargs,
)
Возврат self query retriever
В конце этого метода класса нам нужно вернуть self query retriever. Этот метод возвращает экземпляр класса self query. Мы передаем конструктор запросов, который только что определили, вместе с переданным векторным хранилищем, указанием, использовать ли исходный запрос, транслятором и списком именованных аргументов.
return cls(
query_constructor=query_constructor,
vectorstore=vectorstore,
use_original_query=use_original_query,
structured_query_translator=structured_query_translator,
**kwargs,
)
Краткое изложение того, как LangChain реализует self querying
В этой статье мы рассмотрели, как LangChain реализует концепцию, которую они называют “self-querying.” Это способ создать простое приложение retrieval augmented generation (RAG). Оно использует все те же компоненты: LLM, векторную базу данных и несколько промптов для взаимодействия с LLM.
Self querying — это довольно большой блок кода в LangChain, но эта статья специально рассматривает метод класса from_llm. Этот метод позволяет нам создать RAG-приложение, передав всего четыре обязательных поля. LLM, векторную базу данных, описание документов и информацию о метаданных. Хотите узнать больше о LLM и векторных базах данных? Приходите пообщаться с нами в Discord.
Читать далее

A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.

Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.

Zilliz Cloud Audit Logs Goes GA: Security, Compliance, and Transparency at Scale
Zilliz Cloud Audit Logs are now GA, giving enterprises real-time visibility, compliance-ready trails, and stronger security across AWS, GCP, and Azure.



