Англійська для розробників Mistral AI

Mistral AI швидко став важливим гравцем у відкритому і комерційному ландшафті LLM, пропонуючи сімейство моделей, оптимізованих для різних завдань. Розробники, які інтегрують API Mistral або розгортають відкриті моделі, потребують точного англійського словника, щоб описати можливості моделі, функції API і архітектурні концепції чітко в перегляді коду, документації і обговореннях команди.

Ключовий словник

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

• “Ми увімкнули виклик інструменту, щоб модель могла отримати ціни на акції перед створення аналізу.” *

** Схема функції ** — об’ єкт JSON, який формально описує викликану функцію, включаючи її назву, опис і типи параметрів, передані моделі, щоб вона знала, які інструменти доступні.

• “Оновити схему функції, щоб додати додатковий параметр « currency » перед наступним спринтерським демонстраційним показом.” *

** Codestral ** — спеціалізована модель Mistral, оптимізована для створення коду, завершення і пояснення завдань. “Ми змінили додаток IDE на Codestral, оскільки його завершення заповнення-в-середині значно точніше для Python.”

Pixtral — мультимодальна модель Mistral, здатна обробляти як текст, так і зображення за допомогою одного запиту.

• “Аналізатор рахунків тепер використовує Pixtral для вилучення рядкових елементів безпосередньо зі сканованих зображень PDF.” *

** Le Chat ** — інтерфейс чату Mistral, аналогічний ChatGPT, корисний для посилання при поясненні компанії нетехнічним зацікавленим сторонам. “Le Chat є продуктом для кінцевого користувача; ми будуємо на основі API, який його живить.”

** Mixture-of-experts (MoE) ** — архітектура, де тільки підмножина параметрів моделі (експертів) активується на один токен, що дозволяє отримати велику кількість ефективних параметрів з меншою вартістю виведення. “Mixtral використовує суміш-експертів дизайн, тому він забезпечує якість класу GPT-4 за долю обчислювальної вартості.”

** Модель відкритої ваги ** — модель, вага якої публічно випущена, що дозволяє самостійне розміщення, налаштування і локальне розгортання без залежності від API.

• “Оскільки Mistral 7B є відкритою моделлю, ми можемо розгорнути її на нашій власній інфраструктурі, щоб задовольнити вимоги щодо резиденції даних.” *

Звичайні фрази

• «Модель маршрутизувала запит користувача до правильного інструменту на першій спробі.»
• «Ми повинні затягнути опис функції схеми, щоб модель не галюцинувала значення параметрів.»
• Codestral handles fill-in-the-middle really well for our TypeScript monorepo. — Процитовано 2011-09-14
• «Тільки два з восьми експертів активні на один токен, зберігаючи затримку низькою, незважаючи на велику кількість параметрів»
• «Ми оцінюємо Pixtral для трубопроводу розуміння документів»

Приклади висловлювань

Під час презентації інтеграції вашій команді: “Наш помічник використовує виклик інструменту для запитів до внутрішньої бази знань і API календаря перед написанням відповіді, отже він завжди має актуальний контекст.”

Під час написання документації API:

• “Передати схему функції у масиву інструментів запиту на завершення балачки. Модель поверне об’єкт tool_calls, коли вона визначить, що виклик функції є відповідним.”*

Під час обговорення вибору моделі з менеджером продукту:

• “Для завдань, що вимагають багато коду, ми рекомендуємо Codestral; для будь- чого, що стосується завантажених зображень або діаграм, Pixtral — правильний вибір.” *

Професійні поради

• Під час визначення ** схеми функції **, поле опису має бути коротким, але однозначним — модель використовує це поле для прийняття рішення * коли * викликати функцію, отже, нечіткі описи призведуть до неправильних або пропусчених викликів.
• Описати ** MoE ** для не-інженерів як “систему маршрутизації всередині моделі, яка активує тільки спеціалізовані підмережі, що відповідають кожному вводу, що робить її швидшою і дешевшою, ніж монолітна модель того ж розміру”
• Розрізняти open-weight від open-source у формальних документах — Mistral випускає ваги, але не завжди тренувальний код або дані, тому «open-weight» є більш точним.
• Посилання на ** API Mistral сумісну з OpenAI кінцеву точку ** при обґрунтуванні низьких зусиль з інтеграції до зацікавлених сторін; зазвичай це вимагає тільки зміни базового URL.

Практичні вправи

1. Менеджер продукту запитує, що означає «виклик інструменту». Напишіть пояснення у двох реченнях, не використовуючи жаргон, окрім « функція »
2. Вашій команді слід обрати між Codestral і Pixtral для нової можливості аналізу архітектурних діаграм. Який ви б порекомендували і чому? Напиши три речення.
3. Пояснити змішування експертів молодшому розробнику простою англійською, зосередившись на тому, чому це важливо для вартості і швидкості.

Націоналізація: націоналізація — це знищення нерухомого майна національних меншин

Світ професійної розробки програмного забезпечення сильно залежить від точного спілкування - не тільки про сам код, але і про те, як він обговорюється, переглядається і документується. Для розробників, чия перша мова не є англійською, це може бути значною перешкодою. Це не просто переклад слів; це розуміння наміру за фразами і оволодіння тонкими нюансами технічного дискурсу. Будьмо чесними, ви можете чудово розуміти * буквальний * сенс « розв’ язати цю проблему », але боретеся з очікуванням детального пояснення або кроків, які потрібно зробити, щоб досягти цього рішення. Цей розділ зосереджений на тих загальних областях труднощів і надає стратегії для плавнішої співпраці в екосистемі Mistral AI - особливо при роботі з такими інструментами, як Codestral, Pixtral, Le Chat, і розуміння моделей Mixture-of-Experts.

Одна з найчастіших проблем виникає з термінології навколо * tool call * і функціональних схем. Концепція функції, яка є «добре визначеною» або «надійною», може відчуватися абстрактною без чіткого розуміння того, як ці терміни використовуються на практиці. Розгляньте це повідомлення Slack: « Гей, команда, чи може хтось ще раз подивитися на інтеграцію Pixtral? Схема відповіді не повністю визначає очікуваний вивід — це призведе до періодичних помилок. » Ключовим у цьому випадку є використання « схеми відповіді » і « періодичних помилок ». Людина, для якої мова не є рідною, може негайно зосередитись на самій * схемі *, не звертаючи уваги на те, що проблема полягає у способі, у який інструмент * викликає * або використовує вивід функції. Аналогічно, обговорення навколо моделей Mixture-of-Experts часто включають складні поняття, такі як «маршрутизація» і «вибір експертів». Не бійтеся просити про пояснення – конкретно запитувати приклад того, як приймається рішення про маршрутизацію, може бути неймовірно корисним.

Крім того, навіть здавалося б прості фрази, такі як «переробити цей код» вимагають обережної інтерпретації. Це рідко * просто * про прибирання брудного коду; це майже завжди означає бажання поліпшити продуктивність, читабельність або підтримку. Хороший коментар до перегляду коду може звучати так: « Цей перероблений код покращує ефективність процесу отримання даних за допомогою більш оптимізованого запиту ». Це не просто косметична зміна; це твердження про * вплив * модифікації. Важливо розуміти, що розробники постійно оцінюють компроміси - швидкість проти використання пам’яті, простота проти гнучкості - і чітке формулювання цих виборів є ключовим для ефективного співробітництва.

Нарешті, пам’ ятайте, що документація і описи PR повинні бути точними і однозначними. Використання чітких дієслів («реалізувати», «перевірити», «інтегрувати») і уникнення жаргону значно поліпшить розуміння. Сфокусуйтеся на тому, щоб передати що робить код і чому, а не тільки як.

# Example: Pixtral function call with a specified schema
pixtral query --schema "user_profile" --input "{'name': 'Alice', 'age': 30}"

Ця команда показує основні способи взаємодії з інструментом pixtral, показуючи, як використовувати схеми і параметри вводу для запуску певних функцій. Відповідь буде структурована відповідно до визначеної схеми - в цьому випадку, об’ єкт JSON, що містить інформацію про профілі користувачів.