Хочу поддержать жанр статей «что под капотом» и рассказать подробности реализации проекта code-magic.com — базы данных сниппетов со смысловым поиском.
Как появилась идея проекта
Работая DevOps‑инженером уже более 10 лет, на каждой работе я приходил к одному и тому же решению, которое экономит мне кучу времени, мозгового топлива и нервов: для каждого проекта, в котором я участвовал, я создавал набор папок, в которых складывал типичные скрипты, конфиги и how‑to инструкции. Эта база сниппетов во временем набиралась и возникала проблема: как быстро найти нужный сниппет. Какого‑то простого и понятного решения (без применения космических технологий...), кроме полнотекстового поиска в репозитории проекта не просматривалось.
Пару‑тройку лет назад весь IT мир внезапно для себя, погрузился в пучину чатботов и языковых моделей. Оказалось, что пока космические корабли бороздили просторы Вселенной, чатботы научились относительно хорошо «понимать» посыл сообщения человека и очень хорошо делать перевод сообщения в то, во что человек просит в своём сообщении. Более глубокое знакомство с LLM моделями показало, что текущие модели очень хорошо умеют решать такие задачи перевода информации:
-
по коду генерировать описание того, что этот код делает («перевод N в N»)
-
по тексту генерировать резюме текста («перевод N в K (K < N)»)
-
по тексту классифицировать текст («перевод N в 1»).
Одновременно выстрелила тема с семантическим поиском информации: поиск не по ключевым словам, а по смыслу фразы на естественном языке.
И в какой‑то момент подумалось, что компоненты проблемы выстраиваются в одну воображаемую линию (шутка):
(«коллекция сниппетов»: 1) + («генератор описания кода сниппета»: 1) + («семантический поиск по описанию»: 1) = («сумма»: 3).
Причем, есть ожидания, что такая задача будет решаться с очень хорошим качеством.
Дальше нужно было дать себе ответ на вопрос: кому это нужно, только мне или это будет иметь ценность для широкой общественности.
Посмотрев, какие тенденции в IT индустрии, стало понятно, что текущая тенденция выражается в формуле: «everything as a code». Т.к. любая автоматизация приходит, в конечном итоге, к способу управления «всего» через «код». Соответственно всем людям, которые работают в IT, нужны сниппеты: изолированные кусочки кода (или паттерны коды) для решения конкретных часто возникающих задач, которые можно эффективно переиспользовать.
Это обстоятельство и ожидания высокого качества поиска по сих пор заставляют меня верить в успех проекта.
Идея проекта и какую проблему пользователя должен решать проект
Основная идея проекта состоит в том, чтобы собрать множество коллекций сниппетов для решения часто возникающих проблем. И дать возможность пользователю искать сниппеты по запросу на естественном языке.
Таки "что под капотом"
Имея приличный опыт в разработке (а к слову, мне посчастливилось работать с талантливым разработчиком и архитектором, Сергеем Васильевым, коий сумел мне передать свои подходы и принципы), я понимал, что в таком проекте нужно «срезать все углы», какие только возможны. Поэтому, чтобы задуманную идею довести хотя бы до MVP, нужно использовать только готовые «кирпичики». Значит, нужна готовая CMS с семантическим поиском. Обзор существующих opensource CMS привел к пониманию, что CMS развиваются таким образом, что ядро системы не предусматривает встроенную кастомизацию поиска (так чтобы можно было настроить семантический поиск) и во всех CMS поиск кастомизируется через внешние плагины. Причем эти плагины, это обычно обертки для такой‑то существующей зрелой базы полнотекстового поиска (в 90% случаях эта база — это Elasticsearch).
Помимо этого, выбираемая CMS должна иметь прозрачную понятную архитектуру и документацию, для разработки логики поверх CMS слоя. Поизучав несколько систем, я остановился на Strapi Headless CMS с плагином для полнотекстового поиска через Elasticsearch. Оказалось, Strapi имеет те самые архитектуру и документацию. Доработав плагин для поиска, я переделал его на Opensearch и настроил семантический поиск на стороне Opensearch. Для модели эмбедингов выбрал модель «sentence‑transformers/all‑distilroberta‑v1», т.к. думаю, что для MVP лучше, чем эту модель вряд ли получится найти, и потенциальный эффект использования другой модели не окупит потраченное время для поиска этой новой модели.
Дальше встал вопрос, где разместить сервис. Имея опыт работы с Яндекс.Облако, решил остановится на этом варианте. Даже если выбрать не Яндекс.Облако, то по цене удалось бы сэкономить от силы 10–20%, но по функциональности, удобству и надежности найти что‑то лучше вряд ли получилось бы.
Осталось для сайта сделать frontend для пользователей. И разработать процесс загрузки и обработки сниппетов через LLM.
Тезисно это выглядит вот так:
-
для frontend сайта был выбран next.js фрейворк и наняты web frontend кудесники
-
для обработки кода через LLM и непрерывного контроля и улучшения качества AI‑функций решил использовать Langfuse Prompt CMS
-
тот же самый Langfuse дает SDK, через который достаточно просто сделать сервис AI‑функций: внутренний веб‑сервис, которому на вход отправляются значения prompt variables и на выходе возвращается ответ от LLM
-
для обработки базы внедрил метод персистентных процессов: процессы, которые имеют immutable входные данные в JSON, текущий state в JSON и status (initial, running, error, terminated). Соответственно, через эти процессы проще формировать план обработки базы и отслеживать его статус
-
в данный момент загрузили в базу основные сниппеты для Bash и немного по администрированию OS Linux
-
описания сниппетов и классификации сейчас сделаны через LLM DeepSeek Chat (модель выбрал DeepSeek Chat, т.к. она офигенна).
Вот пара ссылок на сниппеты для Bash для понимания, какие описания генерирует DeepSeek через настроенный промпт и как выглядит карточка сниппета:
В итоге получилась база сниппетов с возможностью поиска на естественном языке. Ура!
Автор: asiver