Словник AI та машинного навчання, який повинен знати кожен розробник
Практичний посібник з лексики штучного інтелекту і LLM для розробників — символи, RAG, тонка настройка, галюцинації, контекстне вікно і багато іншого з реальними прикладами використання.
Вам не потрібно бути дослідником машинного навчання, щоб працювати з системами штучного інтелекту. Але вам дійсно потрібно розуміти словниковий запас — щоб читати документацію, обговорювати інтеграції зі своєю командою і розумно оцінювати інструменти. Цей посібник містить основні слова та вирази з ШІ та LLM, які повинен знати кожен розробник, що працює з системами ШІ.
Словник мови льон (англ.)
| Term | Definition | Practical note |
|---|---|---|
| Token | The basic unit of text an LLM processes — roughly 0.75 words in English | API costs are usually priced per token |
| Context window | The maximum amount of text (in tokens) an LLM can process at once | Longer context = more expensive but more aware |
| Temperature | A setting controlling how random the model’s outputs are (0 = deterministic, 1+ = creative) | Use low temperature for code generation, higher for creative tasks |
| Hallucination | When an LLM generates confident-sounding but incorrect or fabricated information | Always verify LLM outputs for factual claims |
| Prompt | The input text you send to an LLM | Prompt engineering is the skill of crafting effective prompts |
| System prompt | Instructions given to the model before the user’s message | Used to set behaviour, tone, and constraints |
Ретроспективний огляд (рос.)
** RAG ** це шаблон, за допомогою якого відповідні документи витягуються з бази знань і надаються LLM як контекст перед тим, як він створює відповідь. Це ґрунтує вивід моделі на реальних даних і зменшує галюцинації.
Ключовий словник:
- ** Вбудовування ** — Числовий вектор, що представляє частину тексту, використовується для пошуку подібності
- ** Векторна база даних ** — База даних, оптимізована для зберігання і запиту вбудованих даних
- ** Пошук ** — Крок пошуку відповідних документів за запитом користувача
- ** Розбиття на шматки ** — розбиття документів на менші частини для вбудовування і отримання
- ** Заземлення ** — З’ єднання відповіді LLM з конкретними отриманими джерелами
- “Ми реалізували RAG, щоб запобігти галюцинаціям асистента щодо деталей продукції — тепер він отримує відповідну специфікацію продукції перед створення відповіді.” *
Словник-довідник
Досконала настройка означає тренування існуючої попередньо тренованої моделі на основі ваших власних даних. Це пристосовує його до певного домену або завдання.
| Term | Meaning |
|---|---|
| Base model | The original pre-trained model before any fine-tuning |
| Fine-tuning | Continuing training on a domain-specific dataset to adapt the model’s behaviour |
| LoRA | Low-Rank Adaptation — an efficient fine-tuning technique that updates fewer parameters |
| Instruction tuning | Training a model to follow instructions, typically using question-answer pairs |
| RLHF | Reinforcement Learning from Human Feedback — used to align models with human preferences |
Точне налаштування потужне, але дороге. Багато команд вважають, що ** швидка інженерія ** і ** RAG ** можуть досягти своїх цілей без витрат і складності тонкої настройки.
Оцінка моделі
| Term | Meaning |
|---|---|
| Benchmark | A standardised test used to compare model performance |
| Precision | Of all items the model labelled positive, how many were actually positive? |
| Recall | Of all actual positive items, how many did the model correctly identify? |
| F1 score | The harmonic mean of precision and recall — useful when both matter |
| Evals | Short for evaluations — the process of measuring an LLM’s output quality |
Напис на «Евересті»
У розробці LLM, «запуск evals» став стандартним словником. Це означає систематичне тестування вихідних даних моделі з очікуваними відповідями або критеріями якості. На відміну від традиційного тестування програмного забезпечення, evals часто включають людських оцінювачів або суддів моделей (інша LLM використовується для оцінки першого).
Приклади речення
- «Контекстне обмеження вікна означає, що ми не можемо подавати весь документ до моделі за раз — нам потрібно буде реалізувати розбиття і пошук»
- «Ми помітили, що модель галюцинує назви кінцевих точок API, тому ми додали документацію API до системного запиту, щоб заземлити його відповіді»
- «Температура встановлена на 0,2 для функції генерації коду, тому що ми хочемо детерміновані, відтворювані виходи.»
- «Після запуску оцінок на 500 репрезентативних запитах, ми виявили, що конвеєр RAG поліпшив фактичну точність на 34% порівняно з базовою моделлю»
- «Досконала настройка нашого внутрішнього квитка підтримки тривала три дні і поліпшила здатність моделі класифікувати тяжкість проблеми, але RAG було б швидше встановити»
Мова мови: мова для ненароджених розробників
Терміни, які ми використовуємо в штучному інтелекті і машинному навчанні - токен, точне налаштування, галюцинація - можуть відчуватися особливо щільними, коли ви будуєте свій професійний англійський словник. Це не просто розуміння визначення; це про використання їх точно і впевнено в технічному контексті, особливо при співпраці з міжнародними командами. Часто нерозуміння виникають просто з тонких відмінностей у фразування або очікувань щодо того, як ці поняття обговорюються. Розглянемо деякі звичайні пастки. Наприклад, старший інженер може сказати: «Давайте оптимізуємо підказку для кращої продуктивності», в той час як розробник, який не має досвіду в цій області, може інтерпретувати це як необхідність поліпшити фактичний код безпосередньо. «Оптимізація» тут відноситься до створення більш ефективного запиту - ключова відмінність, яка може призвести до марних зусиль, якщо не розуміти. Аналогічно, термін «надійність» в тренуванні моделей стосується не тільки стабільності; він часто передбачає стійкість до несподіваних вхідних даних або варіацій, що часто ігнорується при початковому перекладі концепції.
Інша часто зустрічається область плутанини виникає з рівня деталей, очікуваних в комунікації. У деяких культурах, коротке резюме є кращим, в той час як інші цінують докладні пояснення. При описі проблеми, наприклад, просто сказати «модель галюцинує» може бути цілком прийнятним для рідного мовця, але не рідний розробник може отримати користь від додавання контексту: «Модель генерує фактично неправильну інформацію - конкретно, вона стверджує, що [неправильні деталі], коли докази вказують на інше.» Цей рівень розробки забезпечує ясність і уникнення потенційних неправильних тлумачень щодо тяжкості або природи проблеми. Крім того, пам’ятайте, що сам технічний жаргон може відрізнятися в різних спільнотах ШІ. Те, що вважається стандартною термінологією в одній дослідницькій групі, може не бути широко використаним в інших. Завжди краще підтвердити розуміння, ніж прийняти спільну інтерпретацію.
Нарешті, пам’ ятайте, що документація і повідомлення про верифікацію є ключовими каналами зв’ язку. При описі змін, пов’ язаних з RAG (Retrieval- Augmented Generation), наприклад, уникайте простого зауваження « Реалізований RAG ». Замість цього, чітко сформулюйте * як * налаштований процес пошуку - яку базу знань використовується, як часто її оновлюють, і які параметри контролюють змішування отриманої інформації з існуючими знаннями LLM. Цей рівень деталізації дозволяє рецензентам оцінити вплив зміни і проактивно визначити потенційні проблеми.
Ось приклад, який показує, як ви можете описати просте завдання інженерного підказування у повідомленні Slack:
# Prompt Engineering - Retrieval Augmentation
# Refining the query for improved context window utilization.
# Specifically, we're adding explicit instructions to focus on recent data.
# This helps avoid irrelevant responses and improves accuracy.
python -m langchain.chains.qa_with_sources -q "What is the current weather in London?" --retriever my_custom_retriever
Ця проста команда демонструє, як швидка інженерія, особливо в середовищі LangChain, може бути врахована для ясності при обговоренні реалізації RAG.