🎯 О чём этот конспект: Разбор концепции «Context Engineering» и перехода от классического RAG к агентному поиску. В видео объясняется, почему 80% успеха контекста зависит от инструментов поиска, и как комбинировать специализированные инструменты (semantic search) с универсальными (shell/bash, SQL) для создания надежных ИИ-систем.

👤 Кому будет полезно: Разработчикам ИИ-агентов, вайбкодерам и инженерам, которые сталкиваются с ограничениями стандартного векторного поиска и хотят научить агентов работать с базами данных и локальными файлами напрямую.

✨ Что получите: Понимание того, как настраивать описания инструментов, использовать «навыки» (agent skills) для обучения агентов сложным синтаксисам (ESQL/SQL) и как интегрировать терминал (bash) для гибкого поиска по файловой системе.

1. От фиксированного RAG к Agentic Search

Контекст: Традиционный RAG (Retrieval-Augmented Generation) имеет жесткий пайплайн: запрос пользователя напрямую идет в векторную базу, достаются чанки, и всё это летит в LLM. Это неэффективно, если контекст не нужен или если требуется несколько шагов поиска (multi-hop). Агентный подход превращает поиск в инструмент, который LLM вызывает только при необходимости и может переформулировать запрос, если первый результат был неудачным.

Тайминг: [02:28]

Выгода: Экономия токенов (агент не вызывает поиск зря) и повышение точности ответов за счет итеративного уточнения запросов.

Как применить:

• Шаг 1: Оберните поиск в инструмент — Вместо прямой функции поиска в коде, создайте описание инструмента (tool definition), чтобы агент сам решал, когда его вызвать.
• Шаг 2: Добавьте логику рассуждения — Используйте системный промпт, чтобы обязать агента проверять достаточность полученных данных.

2. Проблема «хрупкости» стандартного семантического поиска

Контекст: Семантический поиск (векторный) часто пасует перед специфическими терминами, аббревиатурами или когда нужен точный поиск по ключевым словам. Автор показывает пример: запрос про «GDPA» (опечатка или специфический термин) возвращает нерелевантные данные о моделях «Gemma», так как векторы оказались близки, но смысл потерян.

Тайминг: [21:01], [22:12]

Выгода: Понимание ограничений векторных баз и переход к гибридным методам поиска.

Как применить:

• Шаг 1: Анализ ошибок — Если агент возвращает «галлюцинации» на основе неверного контекста, проверьте топ-K результатов поиска.
• Шаг 2: Внедрение точного поиска — Добавьте инструмент, использующий классический Keyword Search (BM25) или прямой доступ к БД через запросы.

3. Обучение агента сложному синтаксису через Agent Skills

Контекст: Дать агенту инструмент execute_sql — это полдела. LLM часто ошибается в синтаксисе конкретных диалектов (например, путает wildcards в SQL и ESQL). Вместо того чтобы раздувать системный промпт, автор предлагает использовать «навыки» (skills) — документацию, которая подгружается в контекст только тогда, когда агент собирается использовать конкретный инструмент.

Тайминг: [28:34], [31:12]

Выгода: Снижение ошибок синтаксиса без перегрузки контекстного окна на каждом запросе.

Как применить:

• Шаг 1: Создайте файл навыка — Опишите правила синтаксиса в Markdown.
• Шаг 2: Настройте взаимосвязь — В описании инструмента укажите, что перед вызовом нужно обязательно прочитать «навык».

Пример промпта для описания инструмента:

Always use the 'elasticsearch_esql_skill' to generate a valid ESQL query before calling the 'execute_esql_query' tool. ESQL has specific rules for wildcards (*) and string literals (double quotes).

4. Shell Tool: Терминал как универсальный поисковик

Контекст: «Всё, что нужно агенту — это shell и доступ к файлам». С помощью bash-команд (grep, ls, find) агент может исследовать структуру проекта и искать данные без предварительной индексации в векторную базу. Это делает агента невероятно гибким в задачах кодинга и анализа локальных данных.

Тайминг: [34:44], [38:52]

Выгода: Возможность работать с «сырыми» данными в реальном времени без затрат на эмбеддинги.

Как применить:

• Шаг 1: Подключите ShellTool — В LangChain это делается одной строкой.
• Шаг 2: Обеспечьте безопасность — Критически важно: запускайте такого агента только в Docker-контейнере или песочнице (sandbox), так как он может удалить файлы.

Пример использования агентом:

# Агент сам пишет цепочку команд для поиска
ls -R ./session_data | grep "GDPA"
grep -r "regulatory constraints" ./session_data/workshops

5. Стратегия «Low Floor, High Ceiling» (Низкий порог, высокий потолок)

Контекст: Автор рекомендует балансировать набор инструментов. «Low Floor» — это простые специализированные инструменты (например, get_user_by_id), где агент почти не может ошибиться. «High Ceiling» — это мощные общие инструменты (Shell, SQL), которые позволяют решать нетривиальные задачи ценой сложности и риска ошибок.

Тайминг: [46:42]

Выгода: Стабильность системы на простых задачах и гибкость на сложных.

Как применить:

• Шаг 1: Начните с General Purpose — Дайте агенту Shell или SQL инструмент.
• Шаг 2: Логируйте поведение — Если видите, что агент делает 5+ вызовов для одной и той же простой задачи, создайте для неё специализированный «быстрый» инструмент.

FAQ

В: Безопасно ли давать агенту доступ к Shell? О: Нет, это крайне рискованно. Автор подчеркивает, что агент должен работать в изолированной среде (Sandbox), так как он может выполнить команду rm -rf /.

В: Почему агент ошибается в SQL-запросах, если он «умный»? О: LLM часто путают синтаксис разных диалектов (PostgreSQL vs MySQL vs ESQL). Помогают «Agent Skills» — краткие инструкции по синтаксису, подгружаемые в момент вызова инструмента.

В: Что лучше: векторный поиск или поиск через Grep в терминале? О: Зависит от задачи. Векторный поиск хорош для поиска по смыслу (синонимы), Grep — для точных совпадений и кодов. Гибридный подход (как в инструменте gina-grep) объединяет оба метода.

В: Как избежать переполнения контекста при использовании многих инструментов? О: Используйте «Progressive Disclosure» (прогрессивное раскрытие). В системном промпте держите только названия и краткие описания, а полные инструкции (skills) подгружайте только при выборе инструмента.

В: Нужно ли переходить с обычного RAG на агентный? О: Если ваш текущий RAG справляется — нет. Агентный поиск нужен там, где требуется сложная логика, фильтрация данных на лету или работа с несколькими источниками (БД + файлы + веб).

Ресурсы и ссылки

• Elasticsearch — база данных и поисковый движок — https://www.elastic.co/
• LangChain — фреймворк для создания агентов — https://www.langchain.com/
• Jina Grep — CLI инструмент для семантического поиска по файлам — упомянут в видео
• ESQL (Elasticsearch Query Language) — язык запросов, использованный в примерах — упомянут в видео
• Llama Index (Sam Tools) — альтернативные инструменты поиска — упомянуты в видео

Конспект создан на основе видео «Agentic Search for Context Engineering» канала AI Engineer. Все права на оригинальный материал принадлежат авторам. Источник: https://youtu.be/ynJyIKwjonM