Автор проекта в домашней лаборатории, использующий Lemonade для запуска моделей и терминальный интерфейс Crush, задался вопросом достоверности ответов локальных языковых моделей. Тестовый набор из 13 вопросов, включавший факты об актуальных релизах, вымышленные термины и контрольные данные, показал, что модель почти не склонна к «галлюцинациям». Вместо выдумок она демонстрировала честность, но при этом игнорировала события последних двух лет, так как её база знаний ограничивалась июнем 2024 года.
Ограниченность знаний моделей и попытка интеграции Vane
В ходе тестов модель правильно отвергла большинство вымышленных сущностей, например несуществующие флаги для Crush или маршрутизаторы Firewalla. Однако она лишь однажды дала уверенный, но полностью вымышленный ответ, когда её спросили о несуществующей подкоманде qm autoscribe. В остальных случаях при отсутствии знаний модель просто признавала некомпетентность. Это побудило автора внедрить систему поиска, выбрав для самохостинга проект Perplexica, который в марте 2026 года был переименован в Vane.
Инсталляция Vane в контейнере Docker на узле Proxmox прошла успешно, так как система теперь включает встроенный движок SearxNG. Важным нюансом при настройке стало указание адреса сервера Lemonade с обязательным добавлением /api/v1, иначе соединение сохранялось некорректно. Для реализации поиска внутри терминальной среды Crush потребовалось написание около 60 строк кода на Python для функции web_search. При этом возникла проблема с зависимостями: из-за изменений в MCP Python SDK версии 2.x пришлось зафиксировать версию пакета ниже 2.0, чтобы обеспечить совместимость с текущим кодом.
Препятствия при работе с поисковыми движками
Первые попытки поиска столкнулись с блокировками: большинство бесплатных движков в SearxNG (DuckDuckGo, Brave, Mojeek, Yep, Google, Startpage) либо возвращали CAPTCHA, либо ограничивали частоту запросов, либо выдавали ошибки доступа. Единственным рабочим вариантом оказался Bing, но и он быстро блокировал доступ из-за высокой интенсивности запросов, так как Vane преобразует один вопрос в серию поисковых операций. Дополнительные трудности возникали из-за некорректной конфигурации оборудования: использование Vulkan вместо ROCm приводило к низкой производительности и утечкам VRAM, а отсутствие ограничений по количеству токенов вызывало тайм-ауты при длинных ответах.
Особенности использования поискового агента
Эксперименты показали, что даже при настроенном поиске модель не всегда обращается к нему самостоятельно. При выполнении запросов без явного указания поиска модель использовала его лишь в 7 из 13 случаев, а при прямом указании «использовать веб-поиск» — в 12. Разные локальные модели демонстрировали различные типы сбоев: некоторые не могли корректно генерировать структурированные вызовы инструментов, необходимые для работы исследовательского агента Vane. Тем не менее, использование API-ключа Brave позволило устранить проблему поиска, предоставив доступ к качественным источникам, таким как руководства по обновлению Proxmox.
Итоговый опыт показал, что локальные модели способны давать точные ответы с опорой на источники, когда поисковый стек работает корректно. Однако реальность self-hosting решений сложнее, чем кажется: помимо необходимости настройки инфраструктуры, приходится сталкиваться с ограничениями внешних сервисов, несовместимостью API и специфическими требованиями моделей к формату данных.
Детали тестового набора и природа галлюцинаций
Тестовый набор из 13 вопросов был специально спроектирован так, чтобы выявить пробелы в актуальной информации. Он охватывал как изменения в фактах, произошедшие после завершения обучения модели, так и запросы на точные номера версий ПО. В контрольную группу вошли общеизвестные стабильные данные, а в список «фейков» — вымышленные сущности: несуществующий маршрутизатор Firewalla, подкоманда Proxmox и выдуманный флаг утилиты Crush.
Интересно, что без доступа к поиску модель отказывалась отвечать на 11 из 13 вопросов. Например, при запросе информации о последнем релизе Lemonade Server — программного обеспечения, на котором она сама же работала, — модель заявляла, что ей ничего не известно об этом проекте. Аналогичный ответ был получен при попытке выяснить, что представляет собой Crush от Charm. Единственный случай откровенной галлюцинации произошел с подкомандой `qm autoscribe`: модель уверенно и в правильном форматировании (Markdown/HTML) описала несуществующий функционал, якобы предназначенный для чтения конфигурации виртуальных машин. Этот «уверенный вымысел» оказался опаснее, чем честное признание в незнании фактов об iPhone 18 Pro, где модель корректно ссылалась на порог своих знаний (июнь 2024 года).
Технические тонкости настройки Vane
Установка Vane потребовала больше усилий, чем предполагалось изначально, в частности из-за того, что старые руководства указывают на имя Docker-образа, которое больше не актуально. Использование Vane упростило архитектуру, так как система теперь объединяет в себе SearxNG, избавляя от необходимости развертывания отдельного контейнера для поиска. При настройке провайдера Lemonade в панели управления Vane критически важно добавлять путь `/api/v1` к URL — в противном случае мастер настройки сохраняет конфигурацию, которая выглядит работоспособной, но на деле не позволяет установить связь с интерфейсом Lemonade.
Проблемы с библиотекой MCP возникли из-за того, что в версии 2.x SDK класс `FastMCP` был переименован. Если при установке пакета автоматически подтягивается свежая версия, код перестает импортироваться, а терминал Crush сообщает о закрытом соединении. Фиксация версии ниже 2.0 стала обязательным условием стабильности.
Проблемы «самостоятельности» и аппаратные барьеры
Даже при наличии всех инструментов, модель не всегда склонна использовать их по своей воле. В тестах модель, имея доступ к Vane, в средних результатах порой игнорировала поиск, а затем извинялась за отсутствие веб-доступа. Это демонстрирует, что наличие возможности поиска не является гарантией успеха: системный промпт лишь повышает вероятность использования инструмента, но предсказать, какой именно вопрос спровоцирует модель на поиск, невозможно.
Низкая производительность системы порой объяснялась тем, что Lemonade по умолчанию выбирал бэкенд Vulkan вместо ROCm. Разница в показателях была существенной:
- Vulkan: 10,7 токенов в секунду, занято 0,2 ГБ VRAM;
- ROCm: 33 токена в секунду, занято 6,7 ГБ VRAM.
Кроме того, отсутствие лимита вывода у reasoning-моделей приводило к тому, что ответы могли превышать 15 000 токенов, вызывая таймауты даже при нормальной работе GPU. Проблему также усугубляла переменная окружения, которая сбрасывалась при каждом открытии нового терминала, что приводило к повторным сбоям конфигурации.
Итоги работы исследовательского агента
После подключения API-ключа Brave поисковый агент начал стабильно возвращать от 26 до 55 источников за 12 секунд. Качество ответов при этом стало выше, чем у обычного поиска Bing: модель находила специфические страницы загрузок вики Proxmox и руководства по обновлению конкретных версий системы.
Тем не менее, эксперимент показал фундаментальную проблему: «исследовательский агент» Vane требует, чтобы модель выдавала структурированные вызовы инструментов (tool calls), но ни одна из локальных моделей автора не делала это в формате, пригодном для данного пайплайна. В результате часто наблюдался парадокс: система выполняла поиск, получала данные, но в итоговом ответе заявляла, что «не умеет искать в сети». Единственный успешный результат был достигнут с моделью класса Coder, которая, найдя старое имя образа в источниках, честно признала, что не может идентифицировать текущее, что является верной стратегией для быстро меняющейся инфраструктуры.
