Работы фрилансеров в категории AI — искусственный интеллект

Клиент — бухгалтерский аутсорсинг, 200+ документов в день (счета, акты, договоры поставки). Операторы вручную переносили реквизиты в 1С — 5–8 минут на документ, ошибки в ИНН и суммах приводили к сверкам и штрафам. OCR давал текст, но структурировать его приходилось вручную. Задача: набор промптов со structured output (JSON Schema) — извлечение полей из текста документа с confidence и флагом «требует проверки». Человек подтверждает спорные поля. Реализация: • 4 prompt-шаблона: счёт, акт, договор поставки, доп. соглашение; • JSON Schema: контрагент, ИНН/КПП, сумма, НДС, дата, номер, срок оплаты; • post-validation: checksum ИНН, сумма прописью vs цифрами, формат даты; • few-shot на «грязных» сканах: печати, таблицы, переносы строк; • confidence per field: < 0.85 → highlight в UI для оператора; • eval: 200 размеченных документов, field-level accuracy; • prompt changelog: что менялось при падении accuracy на конкретном типе. Стек: промпт-инжиниринг, OpenAI structured outputs, JSON Schema, Python, OCR-текст на вход. Приёмка: field accuracy > 94% на счетах, > 89% на договорах. Итог: ввод документа ~1–2 минуты (проверка) вместо 5–8; ошибки в реквизитах −80%. NDA: компания не публикуется.

Клиент — SaaS-платформа (логистика), 400+ тикетов в день. Маршрутизация вручную: оператор читал обращение и ставил тег — 30–60 секунд на тикет, ошибки маршрутизации ~12%, SLA страдал. Классификатор на ключевых словах не справлялся с вариативностью формулировок. Задача: система few-shot промптов для классификации намерения и приоритета — 14 категорий, confidence score, fallback «не уверен → general queue». Без автоответа клиенту — только routing. Реализация: • taxonomy: 14 intent-классов (статус, оплата, баг, интеграция, billing, churn risk и др.); • few-shot промпт: 3–5 примеров на класс, hard negatives для путаницы «оплата vs billing»; • structured output JSON: intent, priority, confidence, suggested_queue; • порог confidence: < 0.7 → ручная разметка + пополнение few-shot; • eval на 500 размеченных тикетах: precision/recall по классам; • итерации v1→v4: анализ confusion matrix, добавление edge cases; • документация: как добавить новый intent без переобучения модели. Стек: промпт-инжиниринг, OpenAI API, JSON Schema, Python eval, Zendesk webhook. Приёмка: macro-F1 > 0.88 на hold-out выборке. Итог: время маршрутизации ~2 сек вместо 30–60; ошибки routing −70%. NDA: продукт не публикуется.

Клиент — fintech-сервис с публичным чат-ботом на сайте (~5 000 диалогов в месяц). После запуска всплыли проблемы: бот обещал несуществующие тарифы, отвечал на jailbreak-запросы, уходил в политические темы. Команда закрывала дыры точечными правками — регрессии повторялись каждые 2–3 недели. Задача: система prompt-guardrails — многослойная защита, red-team набор атак, политики и процесс регрессионного тестирования перед каждым деплоем промпта. Реализация: • system prompt v2: роль, границы, запрет финансовых обещаний, формат «не знаю → эскалация»; • policy layer: 40+ правил (regex + LLM-check) — PII, конкуренты, юридические советы; • red-team набор: 150 атак (jailbreak, role-play, prompt injection, social engineering); • regression suite: прогон перед деплоем, отчёт pass/fail, блокировка при < 95% success; • output validator: проверка ответа на стоп-фразы и галлюцинированные тарифы; • playbook для команды: как добавить правило, как разбирать инцидент; • метрики: block rate, false positive, инциденты по неделям. Стек: промпт-инжиниринг, OpenAI API, Python (test runner), YAML policies, CI/CD hook. Приёмка: red-team пройден, 0 critical находок в prod-shadow 2 недели. Итог: инциденты с «опасными» ответами −90%; деплой промптов — с регрессией, а не «на глаз». NDA: сервис не публикуется.

Клиент — контент-агентство, 8 SEO-редакторов и сетка сайтов (медицина, финансы, B2B). Тексты писали через «универсальный промпт в ChatGPT» — результат нестабилен: то переспам, то вода, то нарушение медицинских дисклеймеров. Редакторы тратили 40–60 минут на правку каждого черновика. Задача: библиотека промптов под типы материалов + eval-набор для измерения качества до публикации. Не автопостинг — редактор получает черновик и чек-лист, финальное слово за человеком. Реализация: • 12 prompt-шаблонов: лендинг, статья, FAQ, обзор, comparison, news — с переменными (ниша, ключи, tone, объём); • блок E-E-A-T в каждом промпте: экспертность, источники, disclaimer под YMYL-ниши; • eval-набор (80 эталонных заданий): метрики — keyword density, readability, структура H2–H3, уникальность формулировок; • автоматический scorer (LLM-as-judge + rule-based): pass / revise / reject; • negative examples в few-shot: «как не писать» для каждой ниши; • документация для редакторов: когда менять шаблон, как добавить ключи; • версионирование промптов в Git; changelog при правках. Стек: промпт-дизайн, OpenAI/Claude API, Python (eval runner), Google Sheets, JSON Schema для выхода. Приёмка: 3 эталонных текста сверены с работой senior SEO. Итог: правка черновика ~15–20 минут вместо 40–60; стабильность структуры и compliance в YMYL. NDA: домены клиента не публикуются.

Клиент — retail-сеть (80+ магазинов), отдел аналитики и региональные менеджеры. Простой отчёт «выручка по регионам за квартал» требовал заявки в BI-команду и занимал 1–2 дня. SQL знали единицы; дашборды в Looker покрывали только типовые срезы, ad-hoc вопросы оставались в очереди. Задача: copilot для аналитики — вопрос на русском → безопасный SQL → таблица и график. Только read-only к витрине данных; без доступа к сырым PII и без возможности изменять данные. Реализация: • semantic layer: описание таблиц, метрик, связей на языке бизнеса (dbt/docs); • агент NL→SQL: генерация запроса + валидация (только SELECT, whitelist таблиц и колонок); • sandbox: лимит строк (TOP 1000), timeout 30 сек, EXPLAIN перед выполнением; • ответ: таблица + auto-chart (bar/line/pie) + кнопка «показать SQL» для аудита; • история запросов, избранное, шаринг ссылки на отчёт внутри компании; • роли: менеджер (агрегаты) / аналитик (детализация) / admin; • audit log всех запросов; блок JOIN к PII-таблицам и опасных конструкций. Стек: Python, FastAPI, LangChain, PostgreSQL/ClickHouse, React, Plotly, Docker, SSO. Приёмка: 40 business-вопросов сверены с этalon SQL senior-аналитика. Итог: 80% типовых отчётов — самообслуживание; очередь к BI-команде −60%. NDA: компания не публикуется.

Клиент — маркетплейс услуг с UGC (отзывы, фото работ, комментарии). Команда модерации из пяти человек не успевала обрабатывать 800+ публикаций в день; жалобы на спам, контакты в тексте и неуместные фото росли. Ручная модерация — узкое горло роста платформы. Задача: AI-агент модерации — автоматическая первичная проверка текста и изображений, маршрутизация в очередь модератора или авто-решение по правилам. На старте спорный контент не публикуется без human review; пороги confidence калибруются по feedback. Реализация: • пайплайн: новая публикация → текст (токсичность, спам, PII, контакты) + vision (NSFW, водяные знаки конкурентов); • policy engine: правила клиента (стоп-слова, ссылки, запрещённые темы); • решения: approve / reject / escalate с confidence score и объяснением; • очередь модератора: приоритет по риску, side-by-side AI-verdict + контент; • feedback: модератор меняет решение → лог для калибровки порогов; • алерт при всплеске reject rate; rate limit на пользователя, бан-листы; • API для мобильного приложения; latency < 3 сек на текст, < 8 сек с изображением. Стек: Python, FastAPI, OpenAI Vision + LLM, PostgreSQL, Redis, React (mod queue), Docker. Приёмка: 500 размеченных примеров, precision/recall согласованы с клиентом. Итог: ~60% публикаций проходит без ручной проверки; время модерации −50%, SLA на публикацию — минуты. NDA: площадка не публикуется.

Клиент — сеть стоматологических клиник (4 филиала). Администраторы тратили до 30% смены на входящие звонки «записаться / перенести / уточнить адрес»; в нерабочее время заявки терялись, клиенты уходили к конкурентам. Пропущенных звонков — до 25% в вечерние часы. Задача: голосовой AI-агент для записи на приём — принимает входящий звонок, уточняет услугу, филиал и время, создаёт запись в CRM. При нестандартном запросе (жалоба, срочная боль) — перевод на администратора с кратким саммари разговора. Реализация: • SIP-транк → STT (streaming) → диалоговый агент (слоты, врачи, филиалы); • TTS с естественной русской озвучкой; barge-in (клиент может перебить); • интеграция с МИС/CRM: проверка свободных слотов, создание записи, SMS-подтверждение; • сценарии: запись, перенос, отмена, FAQ (адрес, парковка, подготовка к приёму); • fallback: «соединяю с администратором» + whisper-саммари для оператора; • админка: прослушивание звонков, правка скриптов, статистика conversion и drop-off; • запись разговоров с согласием; хранение аудио в контуре клиента (152-ФЗ). Стек: Python, Asterisk/VoIP, STT/TTS API, FastAPI, PostgreSQL, CRM API, Docker, VPS. Приёмка: 25 тестовых сценариев звонков, success rate > 90%. Итог: ~45% записей без участия администратора; пропущенных звонков в нерабочее время — 0. NDA: сеть не публикуется.

Клиент — IT-компания (~120 сотрудников), активный найм разработчиков и аналитиков. HR получала 200+ откликов на вакансию; ручной скрининг резюме занимал 3–5 минут на кандидата, часть релевантных CV терялась в потоке. Time-to-hire для hot-позиций превышал месяц. Задача: AI-агент первичного скрининга — оценка соответствия вакансии, краткое резюме для рекрутёра, флаг «приоритет / отказ / уточнить». Без автоматического отказа кандидату без проверки HR; агент только ранжирует и объясняет решение. Реализация: • интеграция с hh.ru / Huntflow API: новый отклик → очередь агента; • парсинг CV (PDF/DOCX), извлечение опыта, стека, локации, зарплатных ожиданий; • скоринг по матрице вакансии (must-have / nice-to-have), объяснимый score 0–100; • карточка кандидата: summary, сильные/слабые стороны, 3–5 вопросов для интервью; • guardrails: игнор фото, пола, возраста; только профессиональные критерии; • дашборд HR: фильтры, ручная переоценка, feedback loop для калибровки промптов; • SLA: обработка отклика < 2 минут; алерт при сбое интеграции. Стек: Python 3.11, FastAPI, LangChain, OpenAI API, PostgreSQL, React, REST API ATS, Docker. Приёмка: 50 CV сверены с оценкой senior-рекрутёра, расхождение score < 15%. Итог: время первичного отбора −70%; HR фокусируется на топ-20% кандидатов. NDA: компания не публикуется.

Клиент — производственная компания, закупки и юротдел. На согласование ежемесячно поступают десятки договоров и КП от поставщиков; юристы тратили 2–4 часа на первичный разбор каждого документа. Ошибки на этапе «быстрого просмотра» приводили к спорам по штрафным санкциям и срокам поставки. Задача: мультиагентная система первичной проверки — извлечь условия, найти риски, сравнить с шаблоном и эталонным КП. Финальное решение всегда за юристом; система готовит структурированный отчёт с цитатами из текста. Реализация: • Агент 1 «Извлечение»: PDF/DOCX → структура (стороны, сумма, срок, штрафы, расторжение, форс-мажор); • Агент 2 «Риски»: чек-лист компании + LLM — отклонения от типового договора, severity high/medium/low; • Агент 3 «Сравнение»: два КП или версии договора — diff по ключевым полям в таблице; • Агент 4 «Отчёт»: executive summary + список рисков с номерами страниц и цитатами; • веб-панель: загрузка файла, статус пайплайна, комментарий юриста, история версий; • версионирование промптов и отчётов; аудит всех прогонов; • запрет автоотправки контрагенту; доступ по ролям (закупки / юрист / admin). Стек: Python, LangChain, FastAPI, PyMuPDF/unstructured, PostgreSQL, React, Docker, VPS. Приёмка: 10 эталонных договоров сверены с разбором юротдела. Итог: первичный разбор за 5–10 минут вместо 2–4 часов; юристы фокусируются на спорных пунктах. NDA: компания не публикуется.

Клиент — интернет-магазин электроники (B2C, ~15 000 заказов в месяц). Поддержка из шести операторов не справлялась в пиковые часы: очередь в онлайн-чате до 40 минут, одни и те же вопросы про статус заказа, возврат и гарантию. NPS падал из‑за долгого ожидания первого ответа. Задача: AI-агент первой линии на сайте — отвечает по базе знаний и данным заказа, при сложном кейсе передаёт оператору с полным контекстом. Без обещаний компенсаций, без доступа к платёжным данным и без «выдуманных» статусов. Реализация: • виджет чата (JS): WebSocket, история сессии, кнопка «Оператор», мобильная вёрстка; • оркестратор агента: классификация намерения → RAG по FAQ → запрос статуса в OMS API → ответ или эскалация; • guardrails: стоп-темы (юридические претензии, chargeback), лимит сообщений, проверка тона; • RAG: инструкции, политика возврата, FAQ; цитаты источника в карточке для оператора; • эскалация: тикет в helpdesk с транскриптом, тегами и черновиком ответа; • админка: правка промптов, просмотр диалогов, метрики deflection rate и CSAT; • A/B-тест: агент vs только оператор на 10% трафика до полного rollout. Стек: Python 3.11, FastAPI, LangChain, PostgreSQL, Redis, OpenAI API, WebSocket, Docker, VPS. Документация для саппорта: когда эскалировать вручную. Приёмка: 30 сценариев из чек-листа QA. Итог: ~55% обращений закрывается без оператора; среднее время первого ответа — секунды вместо 15–40 минут ожидания. NDA: магазин не публикуется.