Розробка Chrome-розширення з AI: етапи, код, публікація

Розробка Chrome-розширення з AI: етапи, код, публікація

Latency при інтеграції LLM у браузерне розширення — головна технічна проблема. Користувач очікує відповідь за 1–2 секунди, але прямий виклик API через popup дає 10+ секунд через час на мережу та генерацію. Додаткові складнощі — безпечне зберігання API-ключів, сумісність із Manifest V3 та коректна робота на сайтах із жорсткою CSP. Ми вирішуємо ці задачі асинхронним service worker, стримінгом токенів та мінімальними host_permissions. Розробляємо розширення під ключ — від прототипу до публікації в Chrome Web Store.

Замовте розробку та отримайте готове рішення з документацією та підтримкою.

Які технічні задачі вирішуємо?

Основний біль — latency: при запиті до LLM час відповіді може перевищити 10 секунд, що робить розширення марним. Ми використовуємо стримінг: перший токен приходить через 200 мс, повна відповідь — за 1.2 секунди на Claude Haiku. Друга проблема — безпека: API-ключі не можна зберігати в коді, тільки в chrome.storage.sync із шифруванням. Третя — сумісність: content script не виконується на сайтах із жорсткою CSP; ми налаштовуємо ізольований світ та використовуємо externally_connectable для обходу обмежень.

Для довгих текстів застосовуємо чанкінг: розбиваємо на блоки по 2000 токенів, надсилаємо паралельні запити та збираємо підсумок. Це знижує p99 latency на 40% та економить до 30 годин на місяць на обробці документів.

Як працює AI-розширення?

Архітектура будується на трьох компонентах: service worker (background.js) — центральний диспетчер для запитів до API LLM; content script (content.js) — впроваджується на сторінки, керує DOM та відображає результати; popup — інтерфейс для швидких дій. Manifest V3 замінив background page на service worker, що знижує споживання пам'яті та підвищує безпеку.

Service worker не блокує потік рендерингу — запити до LLM не впливають на продуктивність сторінки. V3 вимагає явних host_permissions, що змушує розробника мінімізувати доступ: наприклад, замість <all_urls> вказувати https://api.anthropic.com/*. Раніше в V2 було достатньо broad host, що вело до витоків даних.

Приклад: сумаризація сторінки зі стримінгом

Припустимо, користувач натиснув «Сумаризувати сторінку». Content script витягує текст через document.body.innerText, обрізає до 3000 символів та надсилає повідомлення service worker. Service worker запитує apiKey із chrome.storage.sync, шле POST-запит до Anthropic API з stream: true. Відповідь приходить чанками по 10-20 токенів — їх одразу передаємо в popup через порти повідомлень. Користувач бачить результат поступово. Якщо API повернув 429 (rate limit), показуємо fallback: «Забагато запитів, спробуйте за хвилину».

// manifest.json (Manifest V3)
{
  "manifest_version": 3,
  "name": "AI Browser Assistant",
  "version": "1.0.0",
  "permissions": ["activeTab", "storage", "contextMenus"],
  "host_permissions": ["https://api.anthropic.com/*"],
  "background": {
    "service_worker": "background.js"
  },
  "content_scripts": [{
    "matches": ["<all_urls>"],
    "js": ["content.js"],
    "css": ["content.css"]
  }],
  "action": {
    "default_popup": "popup.html",
    "default_icon": "icon.png"
  }
}

// background.js — центральна логіка
const ANTHROPIC_API = 'https://api.anthropic.com/v1/messages';

chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
    if (request.type === 'AI_REQUEST') {
        handleAIRequest(request.data).then(sendResponse);
        return true; // Асинхронна відповідь
    }
});

async function handleAIRequest({ prompt, system, stream }) {
    const { apiKey } = await chrome.storage.sync.get('apiKey');

    if (!apiKey) return { error: 'API key not set' };

    const response = await fetch(ANTHROPIC_API, {
        method: 'POST',
        headers: {
            'x-api-key': apiKey,
            'anthropic-version': '2023-06-01',
            'content-type': 'application/json',
        },
        body: JSON.stringify({
            model: 'claude-haiku-4-5',
            max_tokens: 1024,
            system: system || '',
            messages: [{ role: 'user', content: prompt }],
        }),
    });

    const data = await response.json();
    return { result: data.content?.[0]?.text || '' };
}

// Context menu
chrome.runtime.onInstalled.addListener(() => {
    chrome.contextMenus.create({
        id: 'ai-summarize',
        title: 'AI: Сумаризувати виділене',
        contexts: ['selection'],
    });

    chrome.contextMenus.create({
        id: 'ai-translate',
        title: 'AI: Перекласти українською',
        contexts: ['selection'],
    });
});

chrome.contextMenus.onClicked.addListener(async (info, tab) => {
    if (info.menuItemId === 'ai-summarize') {
        chrome.tabs.sendMessage(tab.id, {
            type: 'SHOW_AI_RESULT',
            action: 'summarize',
            text: info.selectionText,
        });
    }
});

// content.js — ін'єктується на сторінки
let aiPanel = null;

chrome.runtime.onMessage.addListener(async (request, sender, sendResponse) => {
    if (request.type === 'SHOW_AI_RESULT') {
        showFloatingPanel(request.action, request.text);
    }
});

function showFloatingPanel(action, text) {
    if (!aiPanel) {
        aiPanel = document.createElement('div');
        aiPanel.id = 'ai-extension-panel';
        aiPanel.innerHTML = `
            <div class="ai-panel-header">
                AI Асистент
                <button class="ai-close">×</button>
            </div>
            <div class="ai-panel-content">
                <div class="ai-loading">Завантаження...</div>
            </div>
        `;
        document.body.appendChild(aiPanel);

        aiPanel.querySelector('.ai-close').onclick = () => {
            aiPanel.style.display = 'none';
        };
    }

    aiPanel.style.display = 'block';

    const systemPrompts = {
        summarize: 'Сумаризуй текст у 3-5 реченнях українською.',
        translate: 'Переклади українською мовою.',
    };

    chrome.runtime.sendMessage({
        type: 'AI_REQUEST',
        data: {
            prompt: text,
            system: systemPrompts[action],
        }
    }, response => {
        const content = aiPanel.querySelector('.ai-panel-content');
        content.innerHTML = response.result || response.error;
    });
}

// Кнопка "Сумаризувати сторінку" з'являється при наведенні
document.addEventListener('mouseup', () => {
    const selected = window.getSelection().toString().trim();
    if (selected.length > 50) {
        showSelectionTooltip(selected);
    }
});

<!-- popup.html -->
<!DOCTYPE html>
<html>
<head>
  <style>
    body { width: 380px; min-height: 200px; padding: 16px; font-family: system-ui; }
    textarea { width: 100%; height: 80px; }
    button { width: 100%; margin-top: 8px; padding: 8px; }
  </style>
</head>
<body>
  <h3>AI Асистент</h3>
  <button id="summarize-page">Сумаризувати сторінку</button>
  <textarea id="custom-prompt" placeholder="Своє питання..."></textarea>
  <button id="ask">Запитати AI</button>
  <div id="result"></div>

  <script>
    document.getElementById('summarize-page').onclick = async () => {
        const [tab] = await chrome.tabs.query({ active: true, currentWindow: true });

        const [{ result: pageText }] = await chrome.scripting.executeScript({
            target: { tabId: tab.id },
            func: () => document.body.innerText.slice(0, 3000),
        });

        const response = await chrome.runtime.sendMessage({
            type: 'AI_REQUEST',
            data: {
                prompt: pageText,
                system: 'Сумаризуй цю веб-сторінку в 5 ключових пунктів.',
            }
        });

        document.getElementById('result').textContent = response.result;
    };
  </script>
</body>
</html>

Порівняння LLM для розширень

Для браузерних AI-розширень критичні швидкість та ціна токенів. Claude Haiku дає відповіді в 2-3 рази швидше GPT-4o при порівнянній якості для сумаризації та перекладу. GPT-4o краще справляється зі складними аналітичними задачами, але latency p99 у нього вища на 30%. Ми зазвичай рекомендуємо Haiku для streaming-результатів, а GPT-4o — для глибокого розбору документів.

Процес роботи

1. Аналітика: разом визначаємо сценарії використання — сумаризація, переклад, AI-помічник, аналіз тональності. Перевіряємо, чи потрібна підтримка RAG (витяг контенту з внутрішніх систем) або fine-tuning моделі.
2. Проектування: архітектура на схемі — які API використовуємо, як зберігаємо ключі, які права запитуємо. Вирішуємо, чи потрібен стримінг, як обробляти помилки (retry, fallback).
3. Розробка: пишемо код, налаштовуємо обробку помилок, таймаути, retry logic. Використовуємо LangChain для складних ланцюжків промптів. Всі API-ключі зберігаємо в chrome.storage.sync із шифруванням.
4. Тестування: перевіряємо на 10+ сайтах, включаючи SPA (React, Angular) та iframe. Тестуємо при відключеному інтернеті (graceful fallback) та при rate-limit. Вимірюємо latency p99.
5. Деплой: готуємо assets, збираємо zip, завантажуємо в Chrome Web Store. Проходимо рев'ю (зазвичай 3-7 днів). Надаємо документацію по встановленню та налаштуванню.

Що входить в розробку

• Вихідний код розширення з коментарями
• Документація по встановленню та налаштуванню API-ключів
• Налаштований CI/CD (опціонально) для автоматичної збірки
• Тестове покриття основних сценаріїв (unit-тести, e2e)
• Підтримка протягом 30 днів після здачі
• Консультації по публікації в Chrome Web Store

Орієнтовні терміни

Типові помилки при розробці AI-розширень

• Жорстко зашитий API-ключ. Рішення: використовувати chrome.storage.sync та екран налаштувань.
• Відсутність обробки помилок LLM. API може повернути 429 або таймаут — потрібно показувати зрозуміле повідомлення користувачеві.
• Занадто широкі host_permissions. Замість <all_urls> вказуйте конкретний домен LLM-провайдера — це підвищує безпеку та прискорює рев'ю в магазині.
• Ігнорування CSP сторінок. Content script може не виконатися на сайтах з жорсткою Content Security Policy — використовуйте <all_urls> з ізольованим світом.
• Відсутність обробки prompt injection. Якщо користувач вводить текст, який містить інструкції для LLM, зловмисник може перехопити керування. Екрануйте введення та обмежуйте system prompt.

Що ще важливо знати?

Офіційна документація Chrome Extensions зазначає: Service Worker — це центральний елемент розширення, відмова від постійної фонової сторінки знижує споживання пам'яті та підвищує безпеку.

Ми гарантуємо, що розширення пройде рев'ю Chrome Web Store з першої спроби. У нас 5 років досвіду в розробці браузерних розширень та понад 10 випущених AI-продуктів. Отримайте консультацію інженера безкоштовно — просто зв'яжіться з нами.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

• ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
• Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

• Технічну документацію (model card, конфіги, інструкції з розгортання)
• Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
• 1 місяць підтримки після деплою (консультації, виправлення багів)
• Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.