Портфолио и кейсы фрилансеров по созданию RAG и баз знаний

На трёх вымышленных внутренних документах собрал локальный прототип поиска ответов с указанием источника. Цель примера — показать, как система может опираться на проверяемый документ и честно отказываться от ответа, когда данных нет. Это демонстрация метода, а не внедрённый бот клиента. Прототип обработал 4 учебных вопроса. На 3 вопроса он нашёл текстовые основания и вернул выдержку с ID документа; по вопросу о стоимости доставки не нашёл подтверждения и ответил, что в базе нет достаточных данных. Исходные документы, код и JSON-отчёт позволяют воспроизвести этот результат локально. Перед рабочим внедрением нужно согласовать состав и актуальность документов, права доступа, поисковое качество на реальных вопросах и правила эскалации сомнительных ответов сотруднику. Здесь нет персональных данных, подключения к корпоративной базе, генеративной модели, Telegram-бота или измерений качества на документах заказчика. Иллюстрации построены на вымышленных материалах.

Задача: разобраться в техническом состоянии интернет-магазина одежды и определить, какие доработки каталога и карточек товаров нужны в первую очередь. Моя работа: аудит публичного сайта, анализ структуры и контента, подготовка плана работ. Проверены метаданные, заголовки, канонические адреса, карта сайта и товарная разметка. Подготовлены рекомендации по SEO, поиску через ИИ и удобству покупки. Результат этапа — аудит и план доработок. Рекомендации не представлены как внедрённые изменения. Бренд и коммерческие условия клиента не раскрываются.

Задача: представить услуги AI-инженерии и связать сайт с разбором задачи в Telegram для трёх сегментов бизнеса. Моя работа: продуктовая логика, структура, тексты, дизайн и разработка сайта; сценарии трёх отдельных ботов с общей серверной частью. В бета-версии реализованы поиск компании по ИНН, чтение сайта и уточняющие вопросы. Передача согласованного обращения человеку реализована, но полный путь передачи и ответа ещё требует финальной проверки. Сайт поддерживает светлую и тёмную темы и мобильные экраны. Боты находятся в бета-тестировании. В примере работы — интерфейс сайта. Серверный зал используется как иллюстрация, а не фотография собственной инфраструктуры.

Задача: обновить сайт компании, которая занимается ремонтом, строительством и умным домом. Представить услуги и проекты, добавить калькулятор состава работ. Моя работа: структура, тексты, дизайн, разработка и публикация сайта. Результат: 29 страниц на Astro — услуги, портфолио, видеообзоры и калькулятор. Добавлены светлая и тёмная темы, адаптивное меню и поля, удобные на телефоне. Проверены мобильные экраны и доступность интерфейса. В примере работы — разработанный сайт. Изображение первого экрана передаёт визуальную концепцию и не является фотографией выполненного объекта.

Задача: первая линия поддержки не успевала обрабатывать поток типовых вопросов клиентов (тарифы, документы, статусы) по нескольким продуктовым линейкам финансовой компании. Ответы операторов были медленными и неодинаковыми. Решение: бот встроен в существующий канал поддержки (виджет на сайте, Chatwoot): вопрос клиента → семантический поиск по базе знаний в векторной базе (Qdrant) → ответ формулирует LLM с учётом роли и продукта клиента. Если вопрос сложный или эмоциональный — бот сам создаёт тикет и передаёт оператору с контекстом диалога. База знаний ведётся в Markdown, обновление — одним API-запросом, без программиста. Система масштабирована с одного продукта на шесть — добавлением конфигурации, без переписывания кода. Стек: TypeScript, Mastra, Qdrant, OpenRouter/LiteLLM, Chatwoot, Docker. Результат: production-эксплуатация; автоматические ответы на типовые вопросы с маршрутизацией на оператора. Под NDA не публикую метрики — на созвоне покажу архитектуру и живой разбор логики.

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

Демонстрационный образец: товарная накладная вымышленной компании, совпадения с реальными организациями случайны. Задача: перенести реквизиты и строки накладной в таблицу без ручного ввода. Как сделано: изображение → локальная модель Qwen3.6 35B-A3B находит реквизиты и таблицу → код сверяет суммы строк с итогом документа и помечает сомнительные поля для проверки человеком. Результат на образце: 6 реквизитов и 4 позиции распознаны верно, сумма строк 38 790,00 ₽ совпала с итогом, сомнительных полей нет. На ваших документах начинаю с пилота и измеряю долю верных полей до основной работы.

Собственный проект. Задача: заметки, ссылки и файлы из Telegram теряются в переписке. Решение: бот раскладывает сообщения по темам, распознаёт изображения, строит семантический поиск и ставит напоминания. Заметки складываются в базу Obsidian. Результат: модели работают на домашнем сервере: Qwen3.6 35B-A3B, эмбеддинги bge-m3, поиск в Qdrant.

Собственный инструмент. Задача: заказы приходят с нескольких площадок, большинство не подходят, а часть — мошенничество или «тестовые задания» с вредоносным кодом. Решение: сервис собирает заказы, отсеивает их правилами и по смысловой близости к профилю (эмбеддинги bge-m3), затем модель оценивает пригодность и риски: мошенничество, вредоносные вложения, подсказки-инъекции в тексте. Подходящие сразу приходят в Telegram. Результат: разбор одного заказа — около 13 секунд облачной моделью и около 30 секунд локальной. Работает на домашнем сервере в Docker Compose, данные в PostgreSQL. Та же схема подходит для входящих заявок и писем компании: тип, срочность, кому передать, черновик ответа.

Демонстрационный образец: регламент вымышленной компании (отпуска, командировки, возврат товара). Как сделано: текст регламента и вопрос → локальная модель Qwen3.6 35B-A3B формулирует ответ и называет пункт → код проверяет ссылку на пункт. Результат на образце: 4 вопроса — 4 ответа со ссылкой на верный пункт (2.1, 3.1, 3.2, 4.2). Так же устроен ассистент по базе документов для сотрудников: у каждого ответа есть источник, который можно открыть и проверить.