Глава 18. Поиск по коду и по документам

Агент, работающий с реальным проектом, большую часть ходов просаживает не на решение задачи, а на поиск: где лежит нужное, что с чем связано, что уже сделано. От устройства поиска зависят и счёт, и качество.

Глава про два разных поиска, которые постоянно путают: по коду и по документам.

Поиск по коду Есть три способа объяснить агенту, что где лежит.

Обычный текстовый поиск. Ищет строку. Дёшево, работает везде, не понимает ни хуя. На вопрос, где вызывается эта функция, вываливает всё подряд, где встретилось её имя, включая комментарии и похожие названия. Разгребай сам.

Языковой сервер. Тот же механизм, что подсказывает переходы в редакторе. Понимает язык, знает, где определение и где использования. Точный, но требует настройки и не для всех языков живёт одинаково хорошо: где-то заебись, где-то хуй проссышь.

Индекс по синтаксическому дереву. Разбирает код в структуру и позволяет искать по конструкциям: все обработчики маршрутов, все вызовы такого-то метода, все места, где перехватывается ошибка.

ЧТО ВЫБИРАТЬ За языковой сервер. Он точен, потому что понимает язык по-настоящему. Настроен у тебя, значит дополнительные индексы могут и не понадобиться. За синтаксический индекс. Он не зависит от окружения, работает на разнородных базах и отвечает быстрее. На больших монорепозиториях разница во времени ответа становится решающей. Что показало сравнение. Люди, которые не спорили, а замерили, получили разницу во времени в десятки раз при близком качестве ответов. То есть выбор чаще про скорость и удобство, чем про правильность.

Практический совет, который повторяли: не гоняй фронтир-модель по навигации. Для поиска по коду хватает небольшой локальной модели, можно каскадом: сначала дешёвая сужает область, потом дорогая работает по сути. Хождение по файлам самой сильной моделью это самая жирная строка в счёте.

И ещё один приём, который стоит копейки: есть индекс, запрети текстовый поиск хуком. В правилах написать это можно, но модель на них положит хуй.

Поиск по документам Здесь сложнее, и здесь же живёт главный спор корпуса.

Поиск по коду и по документам

ЧТО ТАКОЕ ПОИСК С ПОДСТАНОВКОЙ Идея простая. У тебя куча документов, которые в контекст не влезают. Ты режешь их на куски, для каждого куска считаешь числовое представление и складываешь в базу. Приходит вопрос, ты считаешь представление вопроса, находишь похожие куски и подставляешь их в запрос к модели. Подход называют поиском с подстановкой. Он появился, когда контекст был маленьким, и с тех пор его несколько раз объявляли мёртвым.

Спор о том, нужен ли он Позиция за отмену. Контекст вырос настолько, что проще положить всё целиком и не еби мозг. Резать документы на куски значит терять связи, а поиск по числам мажет ровно там, где нужен смысл.

Позиция за сохранение. Целиком влезает не всё и не всегда, а платить за миллион токенов на каждый вопрос никто в здравом уме не станет. Плюс есть класс задач, где документы меняются каждый день, и перекладывать их в контекст бессмысленно.

Разрешение, к которому пришли. Это не мода и не пережиток, а инструмент под определённый профиль задачи: много документов, они меняются, вопросы к ним разные и заранее неизвестны. Профиль другой, инструмент нахуй не нужен.

Что кладут в кусок Самая практичная часть главы. Качество поиска определяется не алгоритмом, а тем, что ты положил в кусок вместе с текстом.

Что добавляют Зачем

Путь по оглавлению Кусок перестаёт быть безымянным абзацем

Заголовки разделов выше Появляется контекст, откуда это

Теги и ключевые понятия Работает поиск по синонимам

Дата и источник Можно отсеять устаревшее и оценить доверие

Краткое описание куска Модель понимает, что перед ней, не читая целиком

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

Поиск по коду и по документам

ГЛАВНОЕ ПРО НАРЕЗКУ Куски лучше делать моделью, а не фиксированным алгоритмом. Нарезка по числу символов рвёт таблицы посередине и отрывает заголовок от содержания. Модель режет по смыслу и заодно дописывает к куску метаданные. Дороже на этапе подготовки, дешевле на каждом последующем вопросе. Подготовка делается один раз, вопросы задаются всегда.

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

КУДА ОТПРАВИТЬ ДОКУМЕНТ

Документ пришёл на разбор

Офисный формат в лёгкий конвертер Скан или изображение в тяжёлый разбор

структура уже есть, надо не проебать распознавание, макет, порядок чтения

Обе ветки сходятся в одном представлении, из которого дальше получают текст для модели, структурированные данные или куски для поиска.

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

Разница не в скорости ни разу. Разница в том, что именно первый вариант попадает в куски и в глаза модели, когда человек прикрепил коммерческое предложение. Модель видит кашу и отвечает по каше.

Порог отсечения Про него говорилось в главе о памяти, но повторим, потому что это общая беда обоих поисков.

Любой фиксированный порог близости одновременно слишком строгий и слишком мягкий. Близость по числам не равна релевантности.

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

Поиск по коду и по документам

Третий вариант недооценён зря. Модель вполне нормально переваривает лишний кусок, если он явно помечен как найденное по запросу, а не выдан за истину в последней инстанции.

НАСТРОЙКА ПОИСКА ПО ДОКУМЕНТАМ 1. Проверь разбор на самом сложном документе. Разваленная таблица это твой потолок качества. 2. Добавь в каждый кусок путь по оглавлению и дату. 3. Включи расширение запроса: один дешёвый вызов перед поиском. 4. Не подбирай идеальный порог. Пропускай с запасом и переранжируй. 5. Пометь подставленное как результат поиска, а не как истину.

Что запомнить Поиск по коду и поиск по документам это разные задачи с разными инструментами.

Навигацию по коду отдавай дешёвой модели. Иначе это самая дорогая строка в счёте.

Есть индекс, запрети текстовый поиск хуком: про правило модель забудет.

Поиск с подстановкой нужен там, где документов до хуя, они меняются и вопросы заранее неизвестны.

Качество определяется тем, что ты положил в кусок: путь по оглавлению, дата, теги, описание.

Офисные форматы через распознавание не гоняй. Структура там уже есть, задача её не проебать.

И проверяй разбор на самом сложном документе, потому что развалившаяся таблица это ровно то, что увидит модель.

Модуль 5. Делегирование Три главы про то, кому и что отдавать.

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

Модуль нужен, когда задачи перестали влезать в один разговор.

← Память: файлы, векторы, нити · оглавление · Субагент: когда помогает, когда мешает →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.