Anthropic випустила Claude Sonnet 5 — майже як Opus 4.8, але дешевше

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Anthropic представила Claude Sonnet 5 — нову модель середнього класу, яку компанія називає найбільш агентною серед усього Sonnet-сімейства. Sonnet 5 ближча до Opus 4.8 за можливостями, але дешевша для щоденної роботи. Це не флагман, та досить потужний інструмент для рутинних сценаріїв.

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

Ранні користувачі відзначали, що Sonnet 5 краще доводить складні багатокрокові задачі до завершення. Також модель краще відмовляється від шкідливих запитів та менше галюцинує та підлаштовується під користувача.

Водночас Opus 4.8 залишається сильнішим для задач, де потрібна вища точність. Тож Anthropic фактично пропонує розділення: Sonnet 5 — для масових агентних сценаріїв та щоденної автоматизації, Opus 4.8 — для дорожчих та складніших випадків.

Claude Sonnet 5 уже є у всіх планах — за замовчуванням для Free та Pro, а також доступна користувачам Max, Team та Enterprise. Модель також з’явилася в Claude Code та Claude Platform. В API її можна викликати як claude-sonnet-5.

Коштує $2 за мільйон вхідних токенів та $10 за мільйон вихідних токенів до 31 серпня 2026 року. Це у 2,5 раза дешевше за Opus 4.8 та в 5 разів дешевше за Fable 5. Втім, у вересні ціна має зрости до $3 за мільйон вхідних токенів та $15 за мільйон вихідних.

Тут використовується оновлений токенізатор, через що той самий текст може перетворюватися на більшу кількість токенів — приблизно у 1-1,35 раза залежно від типу контенту. Anthropic пояснює, що вступна ціна має зробити перехід на Sonnet 5 приблизно нейтральним за витратами.

Окремо у компанії зазначають, що Sonnet 5 не тренували на кіберзавданнях. Модель може виконувати рутинні безпечні задачі, але у небезпечніших сценаріях, наприклад створенні експлойтів, суттєво поступається Opus 4.8 та Mythos 5. Втім, через загальне посилення можливостей версію все одно запускають із кіберзахистом, увімкненим за замовчуванням.

Будете переходити на Claude Sonnet 5 заради економії чи залишитесь на Opus 4.8?
👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ТЕХНІЧНЕ ЗАВДАННЯ

Проєкт: Pattern-Based Ontology Builder (PB-OB)

1. Мета системи

Створити систему, яка:
1. Будує онтологію як граф патернів.
2. Автоматично розширює знання через:
— запити до користувача;
— (опційно) пошук у зовнішніх джерелах.
3. Перетворює будь-який вхідний текст у структуровані патерни.
4. Підтримує «brainstorm mode» — генерацію невідомих елементів онтології.

2. Основна ідея моделі даних

Уся система базується на 4 типах сутностей.

2.1 Entity

{
  "id": "string",
  "name": "string",
  "type": "string"
}

2.2 Relation (патерн)

{
  "subject": "Entity.id",
  "predicate": "string",
  "object": "Entity.id",
  "context": "string (optional)"
}

2.3 Attribute

{
  "entity": "Entity.id",
  "key": "string",
  "value": "string | number | boolean"
}

2.4 Event

{
  "id": "string",
  "type": "string",
  "participants": ["Entity.id"],
  "context": "string"
}

3. Основні модулі системи

3.1 Pattern Extractor

Функція: перетворює текст у структури (entities, relations, attributes, events).

Вхід:
«UFO часто спостерігають вночі»

Вихід:

{
  "entities": ["UFO"],
  "relations": [
    {
      "subject": "UFO",
      "predicate": "observed_in",
      "object": "night"
    }
  ]
}

3.2 Ontology Graph Storage

Вимоги:
— зберігання у вигляді графа (nodes + edges);
— підтримка запитів: знайти всі зв’язки Entity, знайти невідомі поля (NULL slots).

3.3 Pattern Query Engine

Підтримує запити виду: «What is UFO?», «How is X represented?», «What does X have?».

Перетворює запит у:

(unknown) --relation--> X

3.4 Brainstorm Engine (ключовий модуль)

Функція: генерує «дірки» в онтології.

Алгоритм для кожного Entity:
1. Перевірити відсутні типові зв’язки:

is-a
has
part-of
causes
located-in
used-for
observed-by
2. Якщо відсутні — створити запит:
"What is UFO --is-a-- ?"
"What UFO --causes-- ?"
3. Додати ці питання у queue.

3.5 Knowledge Ingestion Engine

Вхід: user input, (optional) web text.

Процес:
1. NLP → entity extraction.
2. mapping → relation fitting.
3. validation.
4. storage.

3.6 Abstraction Engine

Функція: об’єднує повторювані патерни:

A --related_to--> B
C --related_to--> D
→ abstraction: "related_to cluster"

4. Основні операції системи

4.1 Add Knowledge

add(input_text)

4.2 Query

query("How is UFO represented?")

4.3 Brainstorm

brainstorm(entity)

4.4 Expand Ontology

expand(entity)
→ generates missing slots

5. Критично важливий принцип

Все є патерном:
— факт = relation;
— питання = incomplete relation;
— знання = заповнений граф;
— контекст = підграф.

6. Мінімальні технології (рекомендовано)

Backend: Java / Python / Node.js.

Storage: Graph DB (Neo4j) або PostgreSQL (JSON + relations).

Optional: vector search (для similarity).

7. MVP (мінімальна версія)

Програміст має реалізувати:
1. CRUD для Entity та Relation.
2. Graph storage.
3. Text → relation parser (простий).
4. Brainstorm generator зі списком шаблонів:

is-a
has
part-of
used-for
observed-in
5. CLI або REST API.

8. Результат системи

Система повинна дозволяти:
— створити онтологію з нуля;
— поступово її «донавчати»;
— автоматично генерувати питання до себе;
— будувати граф знань.

9. Ключова ідея для пояснення програмісту

Скажи йому так:

«Ми не будуємо базу даних. Ми будуємо систему, яка перетворює будь-який текст у граф патернів і постійно запитує, яких патернів не вистачає.»

Якщо хочеш, я можу далі зробити ще більш практичну річ:
— SQL schema (готову);
— або Neo4j graph model;
— або Java архітектуру класів під це ТЗ.

P.S. Розмова з ChatGPT що зробила можливим це ТЗ:
chatgpt.com/...​d4-83ed-bb9c-b4cca51d9b0c

До речі, ця версія ТЗ по словам Сонет 5 є досить поверхневою. І він швиденько накидав мені version 2.0 З уточненнями і доповненнями і оцінкою деяких ризиків.

Та кого ці бенчмарки хвилюють. Через місяць все одно отуплять її. Це ж антропік, дасть вам першу дозу — якісні ШІшки, а потім буде непомітно підсовувати бадяжені.

Звісно це з розряду «я знаю але не можу довести». Але й як пояснити чому їх моделі настільки нестабільні по якості, я не знаю.

Чому б не створити wayback machine але для моделей, чим ще можна довести?

А чому б не створити

wayback machine

але для людського життя)?

Тому що інференс або робота моделі це рантайм процес, який вимагає багато потужного заліза прямо зараз. Це не згадуючи всієї software інфраструктури навколо «голої» ЛЛМ.

Тримати це увімкненим для зберігання попередніх версій моделей це щось на грані фантастики і навряд є фізично можливим.
Хіба контора повністю відмовляється від подальшого розвитку і перейде в перманентний мейтененс.

Я мабуть не дуже гарно пояснив свою думку. Мав на увазі якусь апку яка буде кожну неділю робити однаковий реквест до всіх доступних на цей час моделей і зберігати результат. Так можна буде наглядно показати чи найобує нас Даріо, точніше наскільки саме.

Ідея сама по собі цікава, але майже не реалізуєма через те, як працюють сучасні LLM.

LLM по своїй суті це стохастична система, тобто така, поведінка якої містить елемент випадковості, через що вона може видавати різні результати для одного й того самого запиту, навіть якщо ставити температуру 0, це лише частково допомагає.
Тобто, навіть відправка одного й того ж самого тестового промту до однієї і тієї ж версії буде видавати різні результати. Так, вони, скоріше за все, будуть логічно однаковими (або дуже схожими), але не ідентичними.
Але це якщо міряти лише «голу» LLM.
Сервіси, такі як ChatGPT та інші це ще додаткові програмні монструозні надбудови над LLM, які можуть включають бази даних, різні балансири, черги, політики, системні промти приховані від користувача, використання агентів, тулзи та багато чого іншого, що приховано за одним простим рядком, який ви бачите при заході на веб-весрію чату чи клоду.
І це як в задачі трьох тіл: навіть мінімальне відхилення дуже сильно може спотворити кінцевий результат.
А ці системи щодня змінюються, навіть якщо сама ЛЛМ лишається стабільною.

Тому вимірювати можна, але я не впевнений, що саме ми отримаємо в результаті цих вимірювань, точніше впевнений, що там окрім власне ЛЛМ буде намішано ще купа всього, що може як погіршити так і покращити результат мовної моделі.
Тобто результат тут завжди буде спектром, від якогось і до якогось значення.
Ключове тут правильно визначити метрики і допустиме відхилення для цих метрик, ось це дійсно є сенс міряти.
Але треба тоді ще дати відповідь «Навіщо»)?

P.S. Я буквально зараз дописую чергову наукову статтю де досліджую методи забезпечення відтворюваності результатів у системах на основі LLM.
Підписуйтесь на мій Linkedin, я там періодично публікую результати досліджень.

Indeed, щоб це спрацювало знадобиться експертиза @Dmytra щоб

«я знаю але не можу довести»

Так, хоч і не зовсім в тему, але мені здається, що QA, які вміють працювати з АІ та вирифікувати його роботу, скоро отримають друге дихання і будуть дуже затребувані.

Мені здається ця навичка скоро буде дефолтна на стільки ж як «впевнений користувач пк»

Ще більше моделей, штучних, але «красівих і прєкрасних» :)))

Підписатись на коментарі