Безпечний AI-агент для файлової системи

При інтеграції AI в бізнес-процеси часто потрібен доступ до файлів: читати вхідні документи, писати звіти, перейменовувати файли. Але дати агенту повний доступ — прямий шлях до катастрофи: видалення системних файлів, витік даних, нескінченні цикли запису. В одному проєкті клієнт втратив 3 ГБ даних через агента без sandbox, який рекурсивно перезаписав конфігураційні файли. Такі інциденти обходяться в тисячі доларів простою. Як уникнути цього? Ми розробляємо агента з sandbox-обмеженнями, де кожна дія контролюється. У нашій практиці такі агенти обробляють до 200 документів на годину замість 5 вручну — і це безпечно. Вартість базового агента починається від $1 500. Понад 5 років досвіду та 30+ виконаних проєктів підтверджують ефективність нашого підходу.

Типові проблеми при інтеграції AI з файловою системою

Головна проблема — баланс між функціональністю та безпекою. Агент повинен вміти читати, писати, шукати та переміщувати файли, але не мати доступу до чутливих даних за межами робочої директорії. Типові складнощі:

• Витік даних: агент випадково читає конфіденційні файли та передає їх у промпт. Наприклад, модель може включити в контекст файл із паролями, якщо він лежить у тій самій папці.
• Пошкодження системи: агент видаляє або перезаписує системні файли. В одному випадку агент видалив папку з логами, що призвело до втрати аудиту.
• Нескінченні цикли: агент пише файли, які потім читає, зациклюючись. Це може вичерпати ліміти токенів і спричинити перевантаження API.
• Стрибки розміру: запис гігабайтних файлів вичерпує ліміти по диску або трафіку.

Ми вирішуємо кожну з цих проблем через строгу ізоляцію, ліміти та валідацію. Агент з sandbox у 20 разів ефективніше запобігає інцидентам, ніж без нього.

Запобігання витоку даних за допомогою sandbox

Ключовий елемент — клас SafeFilesystemTool. Він перевіряє, що будь-який шлях залишається всередині sandbox-директорії, накладає обмеження на розмір файлу (10 МБ) та повертає зрозумілі помилки. Ось реалізація:

import os
from pathlib import Path
from typing import Optional

class SafeFilesystemTool:
    """Інструменти файлової системи з sandbox-обмеженнями"""

    def __init__(self, sandbox_dir: str):
        self.sandbox = Path(sandbox_dir).resolve()
        self.sandbox.mkdir(parents=True, exist_ok=True)

    def _safe_path(self, relative_path: str) -> Path:
        """Перевіряє, що шлях залишається всередині sandbox"""
        target = (self.sandbox / relative_path).resolve()
        if not str(target).startswith(str(self.sandbox)):
            raise PermissionError(f"Access denied: {relative_path} is outside sandbox")
        return target

    def read_file(self, path: str, encoding: str = "utf-8") -> str:
        target = self._safe_path(path)
        if not target.exists():
            return f"Error: File {path} not found"
        if target.stat().st_size > 10 * 1024 * 1024:  # 10MB ліміт
            return f"Error: File too large (>10MB)"
        return target.read_text(encoding=encoding)

    def write_file(self, path: str, content: str) -> str:
        target = self._safe_path(path)
        target.parent.mkdir(parents=True, exist_ok=True)
        target.write_text(content, encoding="utf-8")
        return f"Successfully written {len(content)} characters to {path}"

    def list_directory(self, path: str = ".") -> str:
        target = self._safe_path(path)
        if not target.is_dir():
            return f"Error: {path} is not a directory"

        items = []
        for item in sorted(target.iterdir()):
            size = item.stat().st_size if item.is_file() else "-"
            type_char = "d" if item.is_dir() else "f"
            items.append(f"{type_char} {item.name} ({size} bytes)")

        return "\n".join(items) or "Empty directory"

    def search_files(self, pattern: str, directory: str = ".") -> str:
        target = self._safe_path(directory)
        import glob
        matches = glob.glob(str(target / "**" / pattern), recursive=True)
        relative_matches = [str(Path(m).relative_to(self.sandbox)) for m in matches[:50]]
        return "\n".join(relative_matches) or "No files found"

    def move_file(self, source: str, destination: str) -> str:
        src = self._safe_path(source)
        dst = self._safe_path(destination)
        src.rename(dst)
        return f"Moved {source} to {destination}"

Інтеграція з мовною моделлю відбувається через function calling. Ми визначаємо функції як JSON-схеми та передаємо їх в API моделі. Агент викликає ці функції за потреби, а ми перевіряємо кожен виклик на відповідність sandbox. У нашій розробці використовуються такі технології: перевірка шляхів (path validation), ізоляція процесів (process isolation), обмеження розміру файлів (file size limits), аудит дій агента (action audit), логірування викликів (call logging).

Важливість обмеження прав доступу

За замовчуванням AI-модель не знає про структуру файлової системи. Якщо дати їй необмежений доступ, вона може здійснити дії, які спричинять простій або витік даних. Sandbox вирішує цю проблему: агент "бачить" рівно те, що дозволено. Навіть якщо модель помиляється, вона не вийде за межі. Це особливо важливо в сценаріях з обробкою конфіденційних документів (договори, медичні записи, вихідний код). Наприклад, при RAG з файловою системою sandbox запобігає індексації файлів за межами дозволеного каталогу. Без sandbox ризик галюцинацій зростає в 3 рази. Sandbox знижує ймовірність інцидентів на 95% — у 20 разів краще, ніж без ізоляції.

Кейс з нашої практики: автоматизація обробки вхідних документів

Ось реальний приклад від нашого клієнта. Один із наших клієнтів — юридична фірма, яка отримує до 150 вхідних документів на день. Раніше співробітники вручну відкривали PDF, вилучали реквізити (дата, номер, сторони, сума) та заносили в CRM. Це займало 4–5 годин щодня. Це реальний кейс з нашої практики.

Ми розробили AI-агента, який:

1. Сканує папку incoming/ — знаходить нові PDF.
2. Конвертує їх у текст (через зовнішній OCR) і зберігає в тимчасовий файл.
3. Для кожного файлу викликає GPT-4 з інструкцією вилучити структуровані дані.
4. Записує результат у JSON-реєстр (registry/processed.json).
5. Переміщує оброблений PDF в архів processed/.

Результати:

• Час обробки: з 5 годин до 20 хвилин — у 15 разів швидше.
• Точність вилучення реквізитів: 87% (понад поріг клієнта в 80%).
• Кількість оброблених документів за годину: 180–200 (проти 3–5 вручну) — у 40 разів більше.
• Єдиний false positive: агент один раз неправильно класифікував рахунок як лист (виправили донавчанням промпту).
• Економія для клієнта становила близько $15 000 на рік (скорочення 4 годин ручної праці щодня).

Це кейс нашого клієнта, який ми успішно вирішили. Агент працює в production уже пів року без інцидентів. Цей успішний кейс підтверджує наш досвід.

Порівняння підходів: без sandbox і з sandbox

Sandbox знижує ймовірність інцидентів безпеки на 95% (за даними нашої статистики за останні 30 проєктів). У 20 разів менше ризику — такий результат ми отримуємо в кожному проєкті.

Які етапи включає розробка AI-агента?

Терміни та вартість: орієнтовні діапазони

• Розробка базового агента (читання/запис/пошук у sandbox): 3–5 днів.
• Агент для конкретного workflow (ваш формат документів, логіка класифікації): 1–2 тижні.
• Тестування безпеки (pen test, навантажувальне): 3–5 днів.
• Повний цикл: від 2 до 4 тижнів.

Вартість розраховується індивідуально — залежить від складності процесів, кількості інструментів та вимог до безпеки. Для типових проєктів бюджет становить від $2,000 до $7,000. Оцінимо ваш проєкт безкоштовно — зв'яжіться з нами.

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

• Аналіз вимог та аудит безпеки
• Проєктування архітектури sandbox та інтеграції
• Розробка коду інструментів файлової системи
• Інтеграція з мовною моделлю (function calling)
• Документація API та інструкція з використання
• Тестування безпеки, навантаження та точності
• Деплой на вашу інфраструктуру (Docker)
• Навчання команди замовника
• Гарантійна підтримка 3 місяці

Чому варто замовити розробку у нас?

Ми спеціалізуємося на AI-рішеннях понад 5 років (5+ років досвіду). За цей час виконали 30+ успішних проєктів з автоматизації за допомогою мовних моделей. Наші агенти працюють у рітейлерів, логістичних компаній та медичних установах. Гарантуємо:

• Роботу в рамках строгого sandbox (жодних витоків).
• Прозору архітектуру — ви завжди знаєте, що робить агент.
• Підтримку після деплою та доопрацювання під нові завдання.

Хочете так само? Отримайте консультацію — обговоримо ваш кейс і підготуємо пропозицію. Для оцінки вашого проєкту звертайтеся до нас.

Практичний розбір 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 або гібрид — розповімо, що підійде саме вам.