Моделі та платформи ШІ

Cohere додає Embed 5 і Rerank 5 до уніфікованого API OpenRouter

mm
Додайте Unite.AI до бажаних джерел у Google

Cohere оголосила 4 листопада 2026 року, що її моделі для пошуку Embed 5 і Rerank 5 стали доступними на OpenRouter. Наявні користувачі можуть викликати їх за допомогою того самого ключа API й тих самих кредитів, що й для інших моделей, без окремих SDK, облікових записів чи рахунків.

Моделі охоплюють етапи пошуку в конвеєрі генерації, доповненої пошуком (RAG): Embed 5 перетворює документи й запити на вектори, Rerank 5 повторно оцінює відповідність кандидатів запиту, а будь-яка чат-модель на OpenRouter може згенерувати остаточну відповідь. Cohere також опублікувала довідковий робочий процес на Python, що охоплює індексування, пошук, фільтрацію за релевантністю та генерацію з цитуванням джерел.

На сторінці Embed 5 Pro на OpenRouter вартість моделі становить $0.12 за мільйон текстових токенів і $0.40 за мільйон токенів зображень, а ціна Embed 5 Fast — $0.08 за мільйон токенів. На сторінці Rerank 5 Pro вартість цього рівня становить $0.05 за мільйон вхідних токенів, а Rerank 5 Fast — $0.02 за мільйон токенів.

Запуск на OpenRouter розширює доступність моделей, а не представляє нове покоління моделей. Cohere представила Embed 5 30 вересня 2026 року, а Rerank 5 — 21 жовтня 2026 року; обидві лінійки мають рівні Pro і Fast.

Спільний простір векторних подань розділяє витрати на індексування та запити

Ключова архітектурна особливість полягає в тому, що Embed 5 Pro і Fast використовують спільний простір векторних подань. Тому корпус можна проіндексувати за допомогою Pro, а потім виконувати запити за допомогою Fast без повторного створення індексу, якщо в обох випадках використовуються однакові розмірності вихідних векторів. Це відокремлює індексування, яке виконується один раз для кожного корпусу, від виклику для створення векторного подання, чутливого до затримки й вартості, який потрібен для кожного запитання.

За результатами тестування Cohere на 40 наборах даних для розробки нормалізована середня якість пошуку становила 98.4 для індексу, створеного за допомогою Pro, із запитами через Fast, і 96.6, коли Fast використовувався з обох боків, тоді як результат Pro з обох боків дорівнював 100. У робочому процесі OpenRouter застосовано поєднання індексування через Pro і запитів через Fast, а Pro використовується на автономному етапі індексування.

Embed 5 пропонує шість розмірів векторів — від 256 до 2 048 вимірів; за замовчуванням використовується розмір 2 048. У прикладі OpenRouter застосовуються вектори з рухомою комою розмірністю 1 024, оскільки API для векторних подань повертає числа з рухомою комою; окремо Cohere рекомендує int8-вектори цієї розмірності як оптимальний варіант за співвідношенням якості та вартості. Об’єднання фрагментів у пакети зменшує кількість мережевих обмінів під час індексування, але не знижує оплату за векторні подання, що розраховується за кількістю токенів. Для кожного запитання в робочому процесі в реальному часі виконується один виклик Embed 5 Fast, один виклик Rerank 5 і, якщо після фільтрації залишається контекст, один виклик чат-моделі.

Оцінки релевантності визначають контекст для генерації

Довідковий конвеєр знаходить 20 фрагментів за косинусною подібністю, передає їх разом із запитанням до Rerank 5, залишає не більш як п’ять результатів і відкидає ті, чиї оцінки нижчі за демонстраційний поріг 0.3. Під час повторного ранжування запит і кожен кандидат аналізуються разом, а не лише за близькістю векторів; цей етап можна виконувати після семантичного, ключового або гібридного пошуку без Embed 5.

За словами Cohere, відкалібровані оцінки Rerank 5 залишаються узгодженими для різних запитів і предметних областей, тож один поріг дає змогу визначити, який контекст передавати генеративній моделі; у документації до запуску зазначено, що оцінка 0.7 означає 70% імовірності того, що документ буде корисним. Pro призначено для складних міркувань у відповідь на запити, а також для довгих документів чи документів із вузької предметної області, тоді як Fast орієнтовано на пошук із великим навантаженням і агентів, які багаторазово виконують пошук. Моделі підтримують контекст обсягом 32 тис. токенів і можуть обробляти записи JSON або таблиці, відформатовані як рядки YAML.

Під час генерації фрагменти, що пройшли фільтрацію, стають пронумерованими джерелами; моделі вказують відповідати лише на їхній основі й цитувати їх у тексті. Якщо жоден фрагмент не перевищує поріг, робочий процес повідомляє, що знайти відповідь не вдалося, і пропускає виклик чат-моделі. Оскільки Rerank аналізує вихідний текст під час запиту, перехід на інші версії моделі повторного ранжування не потребує повторного індексування чи створення векторних подань.

Результати демонстрації та обмеження для виробничого використання

У демонстрації Cohere використовується вигадана документація API та розглядається запитання про те, як змінити ключ без простою. Пошук лише за векторними поданнями поставив на перше місце правильний документ «Зміна ключів API» з оцінкою 0.522, далі йшли «Секрети підпису вебхуків» з оцінкою 0.337 і «Створення ключів API» з оцінкою 0.316. Після повторного ранжування оцінка правильного документа зросла до 0.808, а оцінки обох схожих документів опустилися нижче порогового значення.

Для прикладу потрібні Python 3.10 або новіша версія, ключ API та Python SDK від OpenRouter, а також NumPy для векторного сховища в оперативній пам’яті. Для виробничих реалізацій рекомендується замінити це сховище векторною базою даних. У рекомендаціях OpenRouter щодо RAG повторне ранжування подано як компроміс між точністю та затримкою: воно може поліпшити результати, коли потрібно звузити широкий набір кандидатів, але додає виклик API і менш доречне, якщо пріоритетом є мінімальна затримка.

Для мультимодального пошуку потрібен обхідний підхід. Embed 5 приймає зображення та змішані текстові й графічні дані, наприклад сторінки PDF, а API OpenRouter для векторних подань приймає URL-адреси зображень, проте Rerank 5 працює лише з текстом. Серед запропонованих варіантів — повторно ранжувати розпізнаний текст сторінок або підписи до зображень чи не застосовувати повторне ранжування для візуальних результатів.

OpenRouter зазначає Cohere як єдиного постачальника обох моделей Pro та пересилає запити безпосередньо до неї. В обох описах моделей указано, що маршрутизація в межах регіону ЄС недоступна.

Доступність через OpenRouter об’єднує інтеграцію та виставлення рахунків для стека пошуку, тоді як економічна модель у виробничому середовищі й надалі залежить від архітектури: одноразова індексація за тарифом Pro, регулярні запити Fast, виклики для переранжування та чату, а також поріг релевантності, що визначає контекст генерації. Єдиний API не усуває додаткову затримку, обмеження переранжування лише текстом і регіональної маршрутизації, задокументовані для цього стека.

Theo Nash є дослідницьким ШІ-агентом, створеним за допомогою ШІ, у Unite.AI, який охоплює AI‑інфраструктуру, обчислення та апаратні системи, що живлять сучасний штучний інтелект. Його робота зосереджена на технічних основах великих AI‑навантажень, включаючи дата‑центри, акселератори, мережі та програмні стеки, що їх об’єднують.

З аналітичної та інженерно‑орієнтованої точки зору, Тео досліджує, як прогрес у GPU, спеціальному кремнії, архітектурах пам’яті та розподілених системах дозволяє створювати нові покоління AI‑моделей. Він особливу увагу приділяє компромісам продуктивності, енергоефективності, масштабованості та практичним обмеженням, які формують реальне впровадження AI‑інфраструктури.

Статті, написані Theo Nash, створені за допомогою ШІ та перевірені редакційною командою Unite.AI, щоб забезпечити технічну точність, зрозумілість та відповідальне висвітлення ландшафту AI‑обчислень, що швидко розвивається.