Журнал «Отинофф»
Схема ускорения полнотекстового поиска по журналам AI-агентов с помощью инвертированного индекса и интернирования строк

Полнотекстовый поиск по журналам AI-агентов: ускорение в 2,2 раза от LangChain

ИИ-инструменты 7 июля 2026 г.

Представьте: ваша команда запускает десятки тысяч AI-агентов в день. Каждый агент оставляет след — что получил на входе, что выдал на выходе. Когда нужно найти конкретный сбой, вы открываете систему наблюдения и начинаете искать. Поиск по журналам занимает минуты, а иногда и часы. Данные разбросаны по разным файлам, JSON-структуры глубокие и вложенные, а каждый новый запрос требует перебора всего объёма.

Источник: langchain.com

Команда LangChain столкнулась с этой же проблемой в своей платформе SmithDB — системе для отслеживания работы AI-агентов. 25 июня 2026 года они опубликовали вторую часть технического описания того, как построили полнотекстовый поиск по журналам агентов. Главное достижение: новые записи становятся доступными для поиска за секунды, а построение индекса ускорилось в 2,2 раза за счёт замены строковых сравнений на числовые идентификаторы.

Для бизнеса это означает: если ваша команда использует AI-агентов и тратит время на поиск по журналам, техники из SmithDB можно применить в собственной системе наблюдения. Но прежде чем внедрять, стоит понять, какие именно методы дали ускорение и какие ограничения остались.

Что именно изменилось в SmithDB

Раньше, когда агент завершал работу, его данные — большие поля ввода и вывода — сохранялись в объектное хранилище. Чтобы найти что-то по тексту, системе приходилось делать запрос в хранилище, ждать ответа и только потом показывать результат. Это занимало время и создавало нагрузку.

В новой версии индекс строится прямо во время записи данных. Как только агент завершает работу, его журнал становится доступным для поиска через несколько секунд. Свежие данные остаются на том же сервере, где были записаны, поэтому первые запросы читают их с локального диска, а не через сетевое хранилище.

Ключевое изменение — способ разбора JSON-данных. Вместо того чтобы разбирать каждое поле отдельно, инженеры LangChain создали «ленту JSON» — плоский массив токенов, где все строки хранятся в одном непрерывном буфере. Это позволило отказаться от выделения памяти под каждое поле и от преобразования чисел. Один проход по документу превращает вложенные объекты в плоские пары «путь — значение».

Например, запись {"agent": "deep agents", "tags": ["langchain", "engine"]} превращается в три строки: agent → "deep agents", tags → "langchain", tags → "engine". Массивы схлопываются в родительский ключ, вложенные объекты — в точечные пути.

Как ускорение в 2,2 раза влияет на стоимость

Самое заметное улучшение — метод, который инженеры называют «интернированием строк». Звучит сложно, но суть проста: вместо того чтобы сравнивать длинные строки при каждой сортировке, системе присваивают каждому уникальному слову короткий числовой идентификатор.

Представьте, что вам нужно отсортировать тысячу карточек с названиями городов. Если сравнивать названия буква за буквой — «Санкт-Петербург» и «Саратов» — это занимает время. Но если каждому городу присвоить номер: Москва — 1, Санкт-Петербург — 2, Саратов — 3, то сортировка превращается в сравнение чисел. Это работает в разы быстрее.

В SmithDB этот приём дал ускорение построения индекса в 2,2 раза по сравнению с обычным подходом. Для бизнеса это означает: меньше времени на обработку данных, меньше затрат на вычислительные ресурсы, быстрее ответы на запросы.

Инженеры выбрали для хеширования библиотеку ahash — она оказалась на 20% быстрее стандартной и на 30% быстрее альтернативы MurmurHash2. Все строки хранятся в одном непрерывном буфере, а каждая строка хешируется ровно один раз.

Три порога, которые защищают от перегрузки

Любая система поиска сталкивается с проблемой: некоторые слова встречаются очень часто. В журналах AI-агентов это могут быть слова вроде «агент», «запрос», «ответ» или даже просто цифра «5». Если накапливать все вхождения такого слова перед записью, память закончится.

LangChain решили эту проблему тремя порогами сброса данных на диск:

  • Группа строк: 32 мегабайта записей, 500 тысяч терминов или 64 мегабайта сырых строк. Этот порог настроен так, чтобы построитель индекса не превышал доступную память.
  • Выровненный блок: около 2 мегабайт. Записи и позиции сбрасываются на одинаковых границах документов, чтобы при чтении можно было получить непрерывный диапазон байтов одним запросом.
  • Сброс внутри термина: 8 мегабайт. Это запасной выход для слов, которые встречаются сотни миллионов раз. Если слово «5» накопило слишком много позиций, система сбрасывает их, не дожидаясь завершения термина.

Каждый порог прямо связан с размером одного запроса к хранилищу и с максимальным потреблением памяти. Для бизнеса это означает предсказуемую стоимость хранения и предсказуемое время ответа.

Что осталось за кадром: ограничения и риски

Статья LangChain — это техническое описание от разработчиков продукта. Она показывает, как они решили свою задачу, но не отвечает на вопрос, подойдёт ли это решение для вашей компании.

Первое ограничение: методы описаны на высоком уровне. Чтобы воспроизвести их в своей системе, потребуется дополнительная инженерная работа. В статье нет точных версий библиотек (ahash, hashbrown, FST), а производительность в 2,2 раза получена на конкретном тесте — ваши результаты могут отличаться.

Второе ограничение: SmithDB — это продукт LangChain, и статья может содержать маркетинговый контент. Утверждения о производительности стоит проверять самостоятельно на своих данных.

Третье ограничение: система оптимизирована для журналов AI-агентов. Если ваши данные имеют другую структуру — например, короткие сообщения или бинарные поля — эффективность методов может снизиться.

Что проверить до внедрения

Прежде чем переносить эти техники в свою систему наблюдения, задайте четыре вопроса:

  1. Какова структура ваших данных? Если ваши журналы содержат глубоко вложенные JSON-объекты с большими полями ввода-вывода, техники SmithDB применимы. Если данные плоские или короткие, выигрыш может быть меньше.
  2. Как часто повторяются одни и те же строки? Интернирование строк даёт наибольший эффект, когда одни и те же пути и значения встречаются в каждом документе. В журналах AI-агентов это так. В других системах — не обязательно.
  3. Какой объём данных вы обрабатываете? Если у вас тысячи записей в день, ускорение в 2,2 раза может не окупить затрат на внедрение. Если миллионы — стоит присмотреться.
  4. Готовы ли вы к инженерной работе? Воспроизведение методов потребует времени команды. Оцените, сколько стоит час разработки и сколько вы сэкономите на ускорении поиска.

Практический чек-лист для руководителя

Что проверить Как проверить Почему это важно
Структура журналов Откройте 10 типичных записей. Есть ли вложенные JSON-объекты? Методы SmithDB оптимизированы для глубоких структур
Повторяемость строк Подсчитайте, сколько уникальных путей и значений в 1000 записей Интернирование эффективно при высокой повторяемости
Объём данных в день Оцените количество записей и средний размер каждой Пороги сброса настроены на определённые объёмы
Текущее время поиска Замерьте, сколько занимает типичный запрос Цель — секунды, а не минуты
Стоимость хранения Оцените затраты на объектное хранилище Новый индекс может изменить структуру затрат

Что делать на этой неделе

  1. Соберите образец данных. Возьмите 10 000 записей из вашей системы наблюдения за AI-агентами. Оцените средний размер, глубину вложенности, количество уникальных строк.
  2. Проверьте текущее время поиска. Замерьте, сколько занимает типовой запрос — поиск по тексту в поле ввода или вывода. Если больше 10 секунд, проблема актуальна.
  3. Оцените стоимость. Посчитайте, сколько вы тратите на хранение и обработку журналов сейчас. Сравните с потенциальной экономией от ускорения в 2 раза.
  4. Примите решение. Если данные подходят и экономия значима — выделите неделю на прототип. Если нет — отложите до появления более подходящего инструмента.

Источники

Что почитать дальше

Теги

Андрей Отинов

Рекомендуем