Claude Opus 4.7 для RAG: як я тестував модель на реальних документах

🎯 Кому взагалі має сенс брати Opus 4.7 у RAG

Якщо коротко: беріть тільки якщо ціна помилки у відповіді висока. Для внутрішнього FAQ це перебор, для юридичного асистента — ок, для бота на сайті інтернет-магазину — забагато.

Я тестував Opus 4.7 наступного дня після релізу. Тому не буду писати «зібрав величезну статистику» — Але прогнав достатньо реальних запитів , щоб зрозуміти основні речі.

Ось з ким Opus 4.7 реально допомагає:

• Юридичні компанії — там, де треба чітко сказати «такого пункту в договорі немає» замість вигадати відповідь
• Фінанси і бухгалтерія — коли клієнт питає про конкретний рядок у регламенті, і треба не помилитись
• Медичні центри — де відповіді формуються на протоколах, і галюцинація може коштувати здоров'я
• Бізнес, який планує давати AI-чат публічним клієнтам, і боїться prompt injection

А ось кому я б радив просто взяти Llama 3.3 70B або навіть щось простіше:

• Внутрішні асистенти для команди з 10-20 людей
• FAQ-боти на 30-50 типових питань
• Проекти, де клієнт чутливий до ціни і може пробачити одну-дві неточні відповіді
• Будь-що з жорсткими GDPR-вимогами — Opus тільки через API

Далі розберу конкретику — що саме показала модель у тестах, скільки це коштує і як я це інтегрував у свій сервіс. Якщо ще не читали огляд самої моделі — там технічні характеристики, бенчмарки і порівняння з GPT-5.4 та Gemini.

⚙️ Чому вибір моделі — це ще не весь RAG

LLM — це тільки фінальний шар. Якщо у вас поганий chunking або кволі embeddings, навіть Opus 4.7 не врятує. Спершу налаштуйте пошук, потім вже думайте про модель.

Дивлюсь на багато чужих RAG-систем — і майже в кожній одна й та сама помилка. Розробник підключив LangChain з дефолтними налаштуваннями, закинув туди GPT-4 або Claude і питає: «чому бот галюцинує?». Відповідь: тому що моделі подають сміття на вхід, ось вона і вигадує.

У RAG три критичних шари, і LLM — третій, не перший:

1. Як ви ріжете документи на шматки (chunking). Розбили таблицю посередині — модель не побачить контексту. Розрізали юридичний пункт між двома chunks — отримаєте відповідь без винятків. Детально про це я писав у статті про 7 стратегій chunking — там і числа дослідження .
2. Яку embedding-модель ви використовуєте для пошуку. Тут помилок найбільше — розробник бере text-embedding-ada-002 бо «OpenAI же» і не знає, що за ту саму ціну є моделі з вдвічі кращою якістю. Я розбирав вибір embedding-провайдерів тут.
3. Власне LLM, який генерує відповідь з контексту. Ось це вже Opus 4.7 або альтернатива.

Якщо перші два шари зламані — Opus 4.7 це не виправить. Він натомість впевнено видасть вам неправильну відповідь на основі неправильних chunks. Тому перед тим, як думати про вибір між Opus, Llama і Gemini — перевірте що ваш retrieval взагалі знаходить правильні фрагменти. Якщо ніколи не стикались з vector search — почніть з цієї статті для початківців.

📄 Що дає 1 мільйон токенів контексту на практиці

Так, контекст гігантський. Ні, це не означає що можна кидати туди всі документи і не робити chunking. Великий контекст — це не заміна retrieval, а підтримка для складних запитів.

У Opus 4.7 контекстне вікно 1 мільйон токенів. Це приблизно 750 сторінок тексту. Звучить спокусливо: можна ж просто засунути всю базу знань у промпт і не паритись з vector search, правда?

Ні, так не працює. Ось чому я все одно використовую RAG:

• Ціна. 1M input-токенів це $5. Якщо у вас 1000 запитів на день і в кожному ви повністю передаєте базу — це $5000 на день тільки на input. Prompt caching знижує до 90%, але все одно дорого для більшості клієнтів.
• Lost in the middle. Навіть фронтирні моделі гірше знаходять інформацію в середині довгого контексту. Stanford показав деградацію до 45% recall. Кидаєте 700 сторінок — отримуєте відповіді на основі початку і кінця, а важливе десь посередині.
• Оновлення. У базі знань документи змінюються. У RAG я просто переіндексовую один файл. З «засунемо все в контекст» — треба перебудовувати весь промпт.

Де великий контекст реально допомагає — це коли запит складний і потребує співставлення кількох документів. Наприклад, клієнт юрист питає: «порівняй пункти про відповідальність у цих трьох договорах». Раніше я робив це через окремі retrieval-запити і merge відповідей. З Opus 4.7 можу завантажити всі три договори цілком і поставити одне питання. Якість відповіді помітно краща.

Практичний поділ у AskYourDocs:

• Звичайні запити — RAG з chunking і top-k=5. Передаємо моделі тільки релевантні chunks, контекст 8-12K токенів.
• Складні аналітичні запити (порівняння, аналіз) — завантажуємо кілька цілих документів, контекст 50-200K. Це дорожче, але клієнт платить окремо за «advanced query».
• «Засунути все» — не використовую взагалі. Не бачу сценарію, коли це виправдано.

🎯 Галюцинації: що я побачив при порівнянні з Llama

Я помітив у тестах. Opus 4.7 чесно визнає, коли в документах немає відповіді. Llama 3.3 70B може видати правдоподібну вигадку і навіть не засумніватись.

Тестував на тестовій базі з ~400 публічних юридичних документів — зразки договорів з відкритих правових реєстрів, типові нормативні акти, шаблони угод. Такий набір я використовую для власних бенчмарків різних моделей, бо він дає реалістичну структуру документів без ризику для чиєїсь конфіденційності. Написав ~30 різних запитів — частина з відповідями в базі, частина навмисне без.

Ось типовий приклад різниці:

Запит: «Який термін розірвання договору без штрафних санкцій для клієнтів з корпоративним тарифом?»

У документах такого розділу немає — є тільки стандартний тариф і VIP.

Llama 3.3 70B: «Для клієнтів з корпоративним тарифом термін розірвання без штрафних санкцій становить 30 днів з моменту подання письмової заяви.» Звучить впевнено, цифра виглядає реалістично. Але це повна вигадка — такого пункту в жодному з 400 документів немає.

Opus 4.7: «У наданих документах я не знайшов окремих умов для корпоративного тарифу. Договори містять інформацію про стандартний і VIP тарифи — якщо вам потрібні деталі по одному з них, я можу відповісти.»

Різниця критична. Для юриста Llama-відповідь — це готова проблема: клієнт її процитує, потім виявиться що це неправда. Opus чесно говорить що не знає і пропонує уточнити.

Я не буду писати «у 15% випадків Llama вигадувала» — це було б облудою з такого короткого тестування. Але тенденція видна чітко на кожному десятку запитів без відповіді в базі. І це збігається з тим, що пишуть партнери Anthropic у ранньому доступі: Hex відзначили саме цю властивість — «модель чесно повідомляє про відсутність даних замість правдоподібних вигадок».

Друге важливе: Opus 4.7 слідує системному промпту буквально. Якщо пишу «відповідай тільки на основі наданого контексту, не використовуй загальні знання» — він справді так і робить. Llama у мене регулярно «дописує від себе» на основі того, що знає з тренування. У юридичному контексті це неприпустимо.

💰 Скільки це реально коштує у продакшені

Офіційна ціна $5/$25 за мільйон токенів. Але новий токенайзер додав мені 23% витрат на тих самих запитах. Llama 3.3 70B через OpenRouter у 10-15 разів дешевша. Для масових клієнтів це визначальна різниця.

Я порахував на типовому клієнтському профілі AskYourDocs: юридична компанія, ~20 співробітників, середнє навантаження 1000 запитів на день, середній контекст із RAG-вікна 8-12K токенів.

Цифри приблизні — залежать від кешування, розміру system prompt, частки output. Але порядок саме такий: Opus у 10-15 разів дорожче за Llama.

Тепер важлива деталь про новий токенайзер Opus 4.7. Одразу після анонсу один з моїх клієнтів попросив підключити нову модель для тесту — хотів побачити, чи покращить вона якість відповідей на їхній базі. Я переключив їх з 4.6 на 4.7 простою підміною model ID в конфігурації — буквально один рядок. Логіка системи не змінилась, промпти ті самі, документи ті самі. Але вартість обробки тих самих запитів виросла приблизно на 23%. Той самий текст — більше токенів. Anthropic офіційно попереджає що буде 1.0-1.35× на той самий текст, у мене вийшло ближче до верхньої межі.

Що з цим робити:

• Prompt caching обов'язково. Якщо у вас стабільний system prompt і великий контекст — кеш дає до 90% знижки на кешовані токени. У мене це зняло більшу частину приросту від нового токенайзера.
• Batch API для не-реалтайму. Якщо клієнт не потребує миттєвої відповіді (наприклад, нічний аналіз документів) — batch дає -50% на input і output.
• Task budgets. Нова фіча — жорсткий ліміт на витрати токенів для задачі. Обов'язкова річ, якщо у вас агент, який може запуститись у цикл і з'їсти місячний бюджет за годину.
• Переглянути system prompt. Я скоротив свій на ~30% — викинув дублювання, об'єднав схожі інструкції. Для 4.7 це ще критичніше, бо кожен зайвий токен дорожчий.

Мій практичний пресет для клієнтів, які мігрують з 4.6 на 4.7: закладайте на перший місяць +25% до API-бюджету, потім оптимізуйте на основі реальних даних.

🔧 Мій системний промпт для document Q&A

Ось мій актуальний промпт. Не ідеальний, але робочий — пройшов кілька ітерацій за останні дні:

Ти — AI-асистент компанії [COMPANY_NAME] для внутрішньої документації.

ТВОЄ ЗАВДАННЯ:
Відповідати на питання співробітників тільки на основі документів,
які я передам тобі у блоці <context>. Не використовуй загальні
знання про юриспруденцію, закони чи стандарти — тільки те, що
є у наданому контексті.

ПРАВИЛА ВІДПОВІДІ:
1. Якщо інформації у контексті немає — скажи прямо:
   "У наданих документах я не знайшов відповіді на це питання."
   Не вигадуй. Не "припускай". Не "за загальними правилами".
2. Якщо відповідь є — цитуй фрагмент документа і вказуй джерело
   (назва файлу, номер розділу/пункту).
3. Якщо відповідь часткова — дай те, що є, і чітко скажи, чого
   бракує: "У документах є інформація про X, але немає про Y".
4. Якщо питання юридично складне і вимагає трактування —
   не трактуй. Скажи: "Це питання потребує юридичної консультації,
   у документах є тільки формулювання пункту: [цитата]".

ФОРМАТ ВІДПОВІДІ:
- Спочатку пряма відповідь у 1-2 реченнях.
- Потім — цитата з документа у лапках.
- В кінці — джерело у форматі: [файл.pdf, розділ X.Y].

<context>
{retrieved_chunks}
</context>

Питання користувача: {user_question}

Чому саме так:

• Заборона використовувати загальні знання — в перших же рядках. Opus 4.7 слідує буквально, тому якщо написати «переважно на основі контексту», він почне додавати своє. «Тільки на основі» — і крапка.
• Точний сценарій для «не знаю». Даю готову фразу-відповідь. Модель її і використовує. Без цього вона може написати «на жаль, інформації недостатньо, але спробую припустити» — і це вже поганий знак.
• Формат цитування. Вимагаю посилання на джерело — тоді відповідь перевіряється клієнтом вручну за секунди.
• Заборона юридичного трактування. Важливо для правової сфери. Модель не має права «трактувати закон» — це робота юриста. Вона має тільки показати текст.

З Llama 3.3 70B цей же промпт працює гірше. Модель регулярно пропускає обмеження «тільки на основі контексту» і додає «за стандартним трактуванням такого пункту...». З Opus 4.7 такого не бачив — слухається буквально.

Як це виглядає в коді на Spring AI

Якщо у вас Spring Boot і ви використовуєте OpenRouter для гнучкості між моделями — ось приблизно як це виглядає:

У статтю я не буду викладати всю архітектуру сервісу — вона складна і комерційно чутлива. Але для наочності покажу ключову ідею мультивендорного RAG на Spring: вибір моделі — це значення в application.yml, а не change request у код. За рахунок @ConditionalOnProperty піднімається потрібний ChatClient — Opus 4.7, Llama через OpenRouter або локальна Ollama.

Конфігурація моделей через application.yml

# application.yml
rag:
  llm:
    provider: openrouter  # anthropic | openrouter | ollama
    model: anthropic/claude-opus-4.7
    temperature: 0.2
    max-tokens: 2048

  system-prompt: |
    Ти — AI-асистент компанії. Відповідай тільки на основі
    наданого контексту. Якщо інформації немає — скажи "не знайдено".
    ...

Умовне підключення провайдера

@Configuration
public class LlmProviderConfig {

    @Bean
    @ConditionalOnProperty(
        name = "rag.llm.provider",
        havingValue = "anthropic"
    )
    public ChatClient anthropicChatClient(
        @Value("${rag.llm.model}") String model,
        AnthropicApi anthropicApi
    ) {
        var options = AnthropicChatOptions.builder()
            .model(model)
            .temperature(0.2)
            .build();

        return ChatClient.builder(new AnthropicChatModel(anthropicApi, options))
            .build();
    }

    @Bean
    @ConditionalOnProperty(
        name = "rag.llm.provider",
        havingValue = "openrouter"
    )
    public ChatClient openRouterChatClient(
        @Value("${rag.llm.model}") String model,
        @Value("${openrouter.api-key}") String apiKey
    ) {
        // OpenRouter сумісний з OpenAI API, тому використовуємо OpenAiChatModel
        var openAiApi = new OpenAiApi("https://openrouter.ai/api", apiKey);
        var options = OpenAiChatOptions.builder()
            .model(model)
            .temperature(0.2)
            .build();

        return ChatClient.builder(new OpenAiChatModel(openAiApi, options))
            .build();
    }

    @Bean
    @ConditionalOnProperty(
        name = "rag.llm.provider",
        havingValue = "ollama"
    )
    public ChatClient ollamaChatClient(
        @Value("${rag.llm.model}") String model,
        OllamaApi ollamaApi
    ) {
        var options = OllamaOptions.builder()
            .model(model)
            .temperature(0.2)
            .build();

        return ChatClient.builder(new OllamaChatModel(ollamaApi, options))
            .build();
    }
}

Сам RAG-сервіс працює з будь-яким провайдером

@Service
@RequiredArgsConstructor
@Slf4j
public class DocumentQaService {

    private final ChatClient chatClient;
    private final VectorStore vectorStore;

    @Value("${rag.system-prompt}")
    private String systemPromptTemplate;

    public AnswerResponse answer(String question, String companyId) {
        var filter = new FilterExpressionBuilder()
            .eq("company_id", companyId)
            .build();

        List<Document> chunks = vectorStore.similaritySearch(
            SearchRequest.builder()
                .query(question)
                .topK(5)
                .filterExpression(filter)
                .build()
        );

        if (chunks.isEmpty()) {
            return AnswerResponse.notFound();
        }

        String answer = chatClient.prompt()
            .system(buildSystemPrompt(chunks))
            .user(question)
            .call()
            .content();

        return AnswerResponse.of(answer, extractSources(chunks));
    }

    private String buildSystemPrompt(List<Document> chunks) {
        String context = chunks.stream()
            .map(doc -> "[%s]%n%s".formatted(
                doc.getMetadata().get("source"),
                doc.getText()
            ))
            .collect(Collectors.joining("\n\n"));

        return systemPromptTemplate.replace("{context}", context);
    }
}

Краса підходу в тому, що сам DocumentQaService не знає і не хоче знати, яку модель він викликає. Він працює з абстракцією ChatClient. Хочу переключити клієнта з Llama на Opus 4.7 — міняю один рядок у application.yml:

rag:
  llm:
    provider: anthropic
    model: claude-opus-4-7

Перезапуск контейнера — і клієнт уже на Opus. Без змін у коді, без редеплою сервісу, без перевипуску інших компонентів. Для продакшен-середовища я тримаю ці конфіги в окремих профілях Spring (application-client-acme.yml), тому кожен клієнт отримує свою модель через зовнішню конфігурацію, а не хардкод.

У реальному сервісі над цим базовим скелетом ще є guardrails на вхід (детекція prompt injection), reranking після similarity search, circuit breaker з fallback на резервну модель, structured logging з correlation ID, і декілька інших шарів. Але ядро — саме це: тонка абстракція над провайдером і конфігурація у yml. Це те, що дозволяє мені обіцяти клієнтам «хочеш завтра іншу модель — міняємо без переписування коду».

Кілька важливих деталей у коді, на які варто звернути увагу:

• Один DocumentQaService — три провайдери. Сервіс працює з абстракцією ChatClient, а не з конкретною реалізацією. Spring сам піднімає потрібний @Bean залежно від значення rag.llm.provider. Додати нового провайдера — це ще один клас з @ConditionalOnProperty, без жодних змін у решті коду.
• OpenRouter через OpenAI API. Хитрість у тому, що OpenRouter сумісний з OpenAI-протоколом. Тому для нього я використовую OpenAiChatModel, просто підмінивши base URL. Це дозволяє через один OpenRouter-бін підключатись до Llama, Gemini, Mistral і десятків інших моделей — просто змінюючи rag.llm.model.
• Параметризований фільтр замість рядкової конкатенації. FilterExpressionBuilder().eq("company_id", companyId) — це правильний спосіб робити pre-filtering до vector search. У мультитенантному сервісі це критично: клієнт А ніколи не побачить документи клієнта Б. Наївна конкатенація через String.format — це injection-уразливість, особливо якщо companyId колись прилетить з user input.
• topK=5 з causa. Я зупинився на п'яти chunks після кількох ітерацій. Менше — ризик пропустити релевантну інформацію, більше — зайвий шум і проблема lost-in-the-middle, коли модель гірше бачить інформацію в середині довгого контексту. Stanford показав деградацію recall до 45% на серединних фрагментах — це не теорія, я це бачив на практиці.
• Переключення моделі без редеплою коду. Конфіги клієнтів живуть у окремих Spring-профілях (application-client-acme.yml). Коли клієнт хоче змінити модель — я міняю одне значення в yml і перезапускаю контейнер. Компіляція, тести, CI/CD — нічого не потрібно.

⚖️ Opus 4.7 vs Llama 3.3 70B для RAG: коли що брати

Llama 3.3 70B — дефолт для більшості клієнтів. Opus 4.7 — для ніш з високою ціною помилки. Не «або-або», а правильний інструмент під задачу. А між ними — ще купа варіантів для різних бюджетів.

Я це питання чую від клієнтів щотижня. Ось моя реальна таблиця рішень, без маркетингу:

Реально у продакшені я пропоную клієнтам ширший вибір, не тільки Llama або Opus. Ось які моделі я зараз раджу під різні бюджети і задачі:

• Ультра-бюджет, мінімальний поріг входу (<$20/міс): deepseek/deepseek-chat через OpenRouter. Несподівано хороша якість за копійки, особливо для простих document Q&A на 200-500 запитів на день.
• Малий бюджет з кращою якістю (<$50/міс): openai/gpt-4o-mini через OpenRouter. Стабільно виграє у DeepSeek на складніших запитах, але коштує дорожче.
• Середній сегмент, дефолт для більшості клієнтів (<$100/міс): meta-llama/llama-3.3-70b-instruct. Сильний баланс якість/ціна, вільна архітектура, при потребі переноситься на self-hosted.
• GDPR + чутливі дані: Llama 3.3 70B у self-hosted-режимі на сервері клієнта через vLLM або Ollama. Ніякого трафіку назовні. Це основа закритого контуру AskYourDocs для медичних і юридичних клієнтів.
• Юридичні/медичні документи, публічний чат-бот, висока ціна помилки: anthropic/claude-opus-4.7. Переплата виправдана чесністю моделі і стійкістю до prompt injection.
• Enterprise з тисячами запитів на день: гібрид. Простіші запити йдуть на дешевшу модель (GPT-4o mini або Llama), складні й чутливі — на Opus 4.7. Роутинг по типу запиту на рівні сервісу.

Технічно це реалізується мінімальною зміною конфігу. Ось як виглядає переключення провайдера у application.yml — тільки один рядок:

# application.yml

# Бюджетний варіант: DeepSeek через OpenRouter
spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:deepseek/deepseek-chat}

# Якісніший мід-тір: GPT-4o mini
# spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:openai/gpt-4o-mini}

# Дефолт для більшості: Llama 3.3 70B
# spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:meta-llama/llama-3.3-70b-instruct}

# Преміум для юридичних і медичних задач
# spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:anthropic/claude-opus-4.7}

Значення береться зі змінної середовища SPRING_AI_OPENAI_CHAT_MODEL з fallback на модель у конфігу. Це зручно для різних середовищ: у dev я ганяю DeepSeek (щоб не палити бюджет на тестах), а в продакшені клієнта — те, що ми домовились. Жодного редеплою коду при зміні моделі, змінюється тільки env-змінна у Railway або Docker-конфігу.

Якщо хочете спробувати Llama 3.3 70B локально на своєму залізі для тестів — у мене є окрема стаття про те, які моделі запускаються на 8GB RAM. Llama 70B там не піде — треба мінімум 64GB RAM для нормальної швидкості — але можна потестувати менші моделі сімейства для розуміння поведінки.

🏗️ Як я підключив Opus 4.7 в AskYourDocs

Коротко про архітектуру: Spring Boot + PostgreSQL з pgvector + OpenRouter як проксі до LLM. Opus 4.7 — одна з кількох моделей, між якими клієнт може перемикатись залежно від бюджету і вимог.

AskYourDocs я будував мультивендорно з самого початку. Позиціонування сервісу — «ваші документи, ваша модель, ваш сервер» — і це не маркетинг, а архітектурне рішення. Клієнт не прив'язаний до одного LLM-провайдера: сьогодні може бути Llama через OpenRouter, завтра Opus 4.7, післязавтра self-hosted модель на їхній інфраструктурі.

Ключові компоненти стеку:

• Spring Boot + Spring AI — основний бекенд. Spring AI дає абстракцію ChatClient над LLM-провайдерами, тому підключити нового — це новий бін із @ConditionalOnProperty, а не переписування сервісного шару.
• PostgreSQL + pgvector — векторна база. Для мого розміру вистачає з запасом. Окремий Qdrant або Pinecone додавати немає сенсу, поки в одну таблицю влазять мільйони chunks і latency пошуку <100ms.
• OpenRouter — проксі для зовнішніх LLM. Через нього одним API-ключем підключаюсь до Opus 4.7, Llama 3.3 70B, Gemini, GPT-4o mini, DeepSeek. Біллінг один, переключення моделі — зміна одного значення в env-змінній.
• Ollama та vLLM — для клієнтів із закритим контуром. Той самий Spring AI ChatClient, просто інший провайдер-бін.
• Railway — деплой. Простий, недорогий, підтримує secrets через env-змінні, що критично для мультитенантної конфігурації.

Схема роботи виглядає так:

Клієнт завантажує PDF
     ↓
[Indexing pipeline]
PDF → текст → chunking → embedding → pgvector
     ↓
(індекс готовий, не залежить від вибору LLM)

Клієнт задає питання
     ↓
[Query pipeline]
Question → vector search → top-K chunks → prompt → ChatClient → LLM
     ↓
LLM обирається через Spring-профіль клієнта
(Opus 4.7 / Llama / Gemini / інше)
     ↓
Відповідь + джерела

Принциповий момент — індексація не залежить від LLM. Клієнт може почати з Llama, місяць попрацювати, зрозуміти, що потрібна точніша модель, переключитись на Opus 4.7 — і не потрібно перебудовувати векторну базу. Це економить і час, і гроші (embedding документів коштує копійки, але займає час на великих обсягах).

По індексації — стандартний RAG-пайплайн: витяг тексту з PDF, chunking за моєю стратегією (recursive + metadata, параметри з моєї статті про chunking), embedding через OpenAI, збереження у pgvector з метаданими для pre-filtering. Вибір embedding-моделі — це окрема тема, і я писав про неї детально тут.

Решта — тонкі шари навколо цього ядра: guardrails, rate limiting на клієнта, логування з correlation ID, метрики споживання токенів для біллінгу, адмін-панель для управління документами. Але ключова ідея проста: тонка абстракція над LLM + добре налаштований retrieval = гнучкий RAG, що живе довше за будь-яку конкретну модель.

⚠️ Коли Opus 4.7 точно не потрібен для RAG

Чесно: для більшості RAG-проектів Opus 4.7 — це перестрілка з гармати по горобцях. Розбираю сценарії, коли можна спокійно брати дешевшу альтернативу.

На основі моїх тестів Opus 4.7 і попереднього досвіду з Opus 4.5/4.6 у роботі з клієнтами — ось сценарії, коли я не бачу сенсу брати преміум-модель:

• Внутрішній FAQ з 30-50 питаннями. Якщо у вас кілька десятків типових запитань і відповіді у документах прямі — Llama 3.3 70B впорається на 95% рівні якості за $30/міс. Переплачувати $400 на мою думку немає сенсу.
• GDPR-обмеження або корпоративна таємниця. Opus працює тільки через API Anthropic (або AWS/Google/Azure з їхніми термінами). Якщо у вас медичні, юридичні, фінансові дані і жорстка вимога «не виходять за периметр» — беріть Llama self-hosted. Це основне позиціонування AskYourDocs, до речі — можна розгорнути повністю закритий контур без жодних зовнішніх API.
• Обсяг 10K+ запитів на день. На такому масштабі Opus коштуватиме $4000+/міс. Рідко виправдано — на великих обсягах майже завжди краще комбінувати моделі (дешевша для простих запитів, Opus для складних).
• Web-research сценарії. Opus 4.7 просів на BrowseComp проти GPT-5.4 і Gemini 3.1 Pro. Якщо ваш агент живе на перегляді сайтів — я б дивився в інший бік.
• Retrieval ще не налагоджений. Якщо у вас recall 50% — Opus цього не виправить. Спочатку chunking, embedding, reranking. Потім уже думати про модель. Я це бачу постійно: розробники переключають LLM, очікуючи магії, а проблема в тому, що retrieval повертає нерелевантні chunks.
• Коли бізнес хоче, щоб бот завжди щось відповідав. Це рідкісний, але реальний запит — «нам потрібно, щоб модель не говорила "не знаю", інакше клієнти подумають, що бот зламаний». Opus 4.7 з його чесною поведінкою буде сприйматись як «гірший». Тут або перевиховувати замовника, або брати модель з вищою схильністю до генерації. Для Opus це просто не та задача.

❓ FAQ: Claude Opus 4.7 для RAG

Чи можна використовувати Claude Opus 4.7 для RAG-системи?

Так, і мої перші тести показують, що він добре справляється — особливо там, де важлива чесність моделі («я не знаю» замість галюцинації) і буквальне слідування system prompt. Головне питання не «чи можна», а «чи виправдано». Для більшості use cases дешевші моделі типу Llama 3.3 70B дають 90% якості Opus за 10% ціни.

Скільки коштує Opus 4.7 для реальної RAG-системи?

За моїми розрахунками на типовому профілі (приблизно 1000 запитів на день, контекст 8-12K токенів) — це близько $400-500/міс. У 10-15 разів дорожче за Llama 3.3 70B через OpenRouter. З prompt caching можна знизити на 30-40%, але все одно це преміум-сегмент.

Opus 4.7 чи GPT-5.4 для RAG?

Якщо дивитись на бенчмарки і ранні тести — Opus 4.7 сильніший там, де критична чесність і відсутність вигадок. GPT-5.4 виграє у web research і там, де треба поєднувати знання з контекстом. Для чистого document Q&A на закритій базі документів я б обрав Opus.

Чи допомагає 1M токенів контексту в Opus 4.7 замінити RAG?

Ні. Великий контекст — це доповнення до RAG, а не заміна. Засовувати всю базу в промпт дорого, моделі деградують на довгому контексті (lost in the middle ефект), і оновлення даних стає проблемою. RAG + селективно великий контекст для складних аналітичних запитів — оптимально.

Чи підходить Opus 4.7 для GDPR-чутливих даних?

Складно. Opus доступний тільки через API — Anthropic, AWS Bedrock, Google Vertex AI, Azure Foundry. Для деяких юрисдикцій і типів даних цього вже достатньо (Bedrock у регіоні EU), для інших — ні. Якщо у вас медичні або персональні дані з жорсткими обмеженнями — Llama self-hosted буде чистішим вибором. Opus як API просто не вміє «не виходити за периметр». Я детально розбирав цю тему в окремій статті про GDPR і AI на документах — там про штрафи, реальні кейси і конкретні кроки для бізнесу в ЄС.

Як інтегрувати Opus 4.7 у Spring Boot додаток?

Через Spring AI. Базово є два шляхи: напряму через Anthropic-провайдер (spring-ai-anthropic) або через OpenRouter як проксі (з spring-ai-openai, бо OpenRouter сумісний з OpenAI-протоколом). Другий варіант зручніший, якщо плануєте перемикатись між моделями — один API-ключ для Opus, Llama, Gemini і десятків інших.

Чи зменшуються галюцинації в RAG, якщо взяти Opus 4.7 замість Llama?

У моїх перших тестах — так, помітно. Opus 4.7 частіше визнає відсутність інформації в контексті замість її вигадування. Але це залежить від system prompt — якщо не заборонити моделі «доповнювати» загальними знаннями, навіть Opus буде це робити. На мою думку, правильний промпт у поєднанні з Opus важливіший, ніж просто вибір моделі.

Чи можна переключатись між Opus 4.7 і Llama без переіндексації документів?

Так. Індексація залежить від embedding-моделі, не від LLM. Поки ви не міняєте embedding — векторна база залишається та сама. Можна перемикати Opus ↔ Llama ↔ Gemini без жодних зусиль, і саме на цьому побудована мультивендорна архітектура AskYourDocs.

Чому Opus 4.7 став дорожчим, якщо ціна за токен не змінилась?

Через новий токенайзер. Той самий текст мапиться у 1.0-1.35× більше токенів. У моєму тестовому прогоні після підміни model ID зростання вартості вийшло приблизно 23% — без жодних змін у логіці. Частково виправляється prompt caching і скороченням system prompt.

Що використовувати для локальної розробки RAG-системи перед деплоєм на Opus 4.7?

Я використовую Ollama з меншими моделями (qwen2.5 7B або llama3.2 3B) для швидкого dev-циклу. Поведінка не ідентична Opus, але дозволяє тестувати pipeline без витрат на API. На staging уже переключаю на реальну модель — Llama через OpenRouter або Opus 4.7, залежно від задачі.

Якщо не впевнені, яку модель брати — почніть з демо AskYourDocs. Допоможу підібрати під ваш профіль документів і бюджет без зобов'язань.