DSPy Framework Vocabulary: англійська мова для декларативного програмування LLM

DSPy переосмислює те, як інженери будують системи, що працюють на LLM, замінюючи ручні підказки моделлю програмування, яка може оптимізувати себе. Замість того, щоб вручну писати і змінювати рядки підказок, ви визначаєте поведінку, яку ви бажаєте, і DSPy знаходить підказки і декілька прикладів, які допомагають вам досягти цієї поведінки.

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

---

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

Signature

** signature ** в DSPy є декларативною специфікацією того, що повинен робити виклик LLM: його поля вводу, поля виводу і опис задачі природною мовою. Замість написання необробленого запиту, ви визначаєте підпис, наприклад, "question -> answer", і DSPy обробляє побудову запиту.

“Замість підтримки крихкого рядка підказки, ми визначили підпис DSPy — якщо основна модель змінюється, ми просто перекомпіляємо, а не переписуємо всі наші підказки.”

Module

** Модуль ** є будівельним блоком програми DSPy. Кожен модуль обгортає виклик до моделі мови (або композиції викликів) і показує чистий інтерфейс Python. Модулі можна складати разом, так само як шари в нейронній мережі, щоб побудувати складні конвеєри.

• “Наш конвеєр складається з трьох модулів: модуля отримання, модуля обґрунтування і модуля форматування. Кожен з них може бути оптимізований незалежно.»*

Оптимізатор (Teleprompter)

** Оптимізатор ** (історично називався ** телепромектор ** у ранніх версіях DSPy) є алгоритмом, який автоматично покращує програму DSPy. За допомогою цього пункту можна шукати можливі підказки, інструкції і декілька демонстраційних кадрів, щоб максимально збільшити вибрану вами метрику. Приклади включають BootstrapFewShot, MIPRO, і BayesianSignatureOptimizer.

“Ми запустили оптимізатор BootstrapFewShot за ніч і він знайшов набір демонстрацій, які поліпшили нашу точність відповідей з 61% до 74% — без написання жодного прикладу вручну.”

Компіляційна програма

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

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

Невелика збірка віршів

** Компіляція з декількох випусків ** — це процес, за допомогою якого оптимізатор DSPy обирає і завантажує демонстраційні приклади (приклади з декількох випусків), які слід включити до підказок кожного модуля. Замість вручну збирати приклади, оптимізатор генерує кандидатські демонстрації, використовуючи сам конвеєр і оцінює, які з них покращують метрику.

“Оптимізатор запустив 50 кандидатських демонстрацій з нашого тренувального набору і обрав 8, які найбільше поліпшили точність перевірки — це компіляція з декількох випусків в дії.”

Ланцюг думки

** Ланцюг думки ** (CoT) є стратегією роздумів, де LLM запитує написати проміжні кроки роздумів перед тим, як дати свою остаточну відповідь. У DSPy, ChainOfThought є вбудованим модулем, який додає rationale вихідне поле до будь-якої підпису, автоматично запитуючи модель розуміти крок за кроком.

“Перехід з Predict до ChainOfThought для нашого багатокрокового модуля роздумів поліпшив точність на 12 відсоткових пунктів — помилки моделі відбувалися тому, що вона стрибала до висновків.”

Bootstrapping

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

• “Ми мали лише 20 прикладів з вручну вказаними мітками, але після запуску ми мали 400 високоякісних демонстрацій для роботи з оптимізатором.” *

Metric

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

• “Наша метрика перевіряє три речі: фактичну точність, присутність цитування і довжину відповіді. Ми витратили більше часу на розробку метрики, ніж на будівництво самого конвеєра»

---

Корисні фрази

• • “Сигнатура повідомляє DSPy, що модуль повинен зробити — оптимізатор визначає, як запитати у моделі, щоб вона це зробила.” *
• “Ми не торкалися необробленого рядка команди місяцями — все проходить через підписи DSPy, а оптимізатор займається рештою.”
• • “Перекомпіляція тривала близько двох годин на нашому наборі перевірки, але тепер програма автоматично пристосовується, коли ми змінюємо базову модель.” *
• “Модул ChainOfThought значно поліпшив продуктивність, але він приблизно удвічі збільшує використання токена — ми оцінюємо, чи вартий цей прибуток якості витрат.”
• • “Наша метрика є найважливішою частиною всієї системи — якщо метрика неправильна, оптимізатор з упевненістю створить неправильну програму.” *

---

Поширені помилки

Плутанина «компіляції» з традиційною компіляцією коду

Коли інженери вперше чують, що DSPy «компілює» програму, вони іноді думають, що це означає транспілювання коду Python або створення бінарних артефактів. У DSPy, компіляція є процесом оптимізації, який знаходить хороші підказки і демонстрації — не традиційний крок компіляції. Вивід — це набір рядків команди і прикладів, а не збірний код. Скажіть * “ми зібрали програму DSPy з нашим набором перевірки” *, а не * “ми зібрали бінарний файл DSPy” *.

Використання « teleprompter » у поточній документації

Ранні версії DSPy використовували термін teleprompter для того, що зараз називається оптимизатор. Якщо ви читали старі підручники або статті, ви знайдете цей термін. У поточній версії DSPy (v2. x) правильним терміном є ** optimizer **. Використання « телепромектор » в сучасному перегляді коду або документації може спричинити плутанину для читачів, які знають тільки новітню термінологію.

Розглядаючи метрику як додаток

Поширеною помилкою є створення конвеєра спочатку і швидке визначення приблизної метрики наприкінці. У DSPy, метрика * є * специфікацією — вона визначає, що означає «краще». Неясна або погано калібрувана метрика створює компіляцію програми, яка має високі оцінки за метрикою, але на практиці зазнає невдачі. Команди, які борються з DSPy часто мають проблему метрики, а не проблему конвеєра.

---

DSPy представляє собою значний зсув у тому, як розробляються програми LLM — від швидкого мистецтва до програмного забезпечення. Вказаний вище словник містить найважливіші поняття цієї моделі: ви декларуєте те, що ви бажаєте (підписи), складайте це у конвеєр (модулі), визначайте, що означає « добре » (метрики), і дайте оптимізатору знайти спосіб досягти цього (збірка). Після того, як ці концепції будуть описані, навігація документацією DSPy стане набагато простішою.

---

Пов’язані статті

• AI and Machine Learning Vocabulary: LLM, RAG, Embeddings Explained (англійською)
• AI Agents Vocabulary: Agent Loop, ReAct, Tool Calling, and Agentic Systems Explained (англійською)
• Галюцинації пояснені англійською

Розвиток мови: розробка мовного забезпечення для немовляти

Основна філософія DSPy — декларативне програмування для великих мов моделей — вже є зміною для багатьох розробників. Додати точність до вашого спілкування навколо нього, особливо коли йдеться про технічні обговорення і співпрацю над кодом, може бути значно складніше для тих, чия перша мова не є англійською. Ми часто зосереджуємось на * що* функціональності DSPy, але менше на нюансах того, як ці концепції обговорюються в професійних умовах. Це не просто про те, щоб знати, що «оптимізатор» перекладається як «оптимізація», це про розуміння контексту, очікуваного тону і фразування, що використовується при описі певної проблеми або рішення. Наприклад, колега може сказати: « Телепромектор витягує занадто багато контексту з початкового запитання — нам слід зменшити його обсяг ». Нерідкомовець може інтерпретувати це буквально як потребу фізично скористатися телепромектором, що призведе до плутанини. Аналогічно, дискусії навколо «компіляції з декількох кадрів» можуть швидко стати щільними з термінологією, якщо їх не пояснити ретельно. Ключовим є визнання того, що професійна англійська мова не тільки про окремі слова; це про ефективне і точне передання значення в рамках встановлених конвенцій. Ця розділ має на меті надати вам лексику і фрази, призначені для полегшення переходів для розробників з різними мовними знаннями. Ми зосередимося на ситуаціях, з якими ви можете дійсно зіткнутися, таких як перегляд коду або командне спілкування, пропонуючи конкретні приклади того, як ефективно сформулювати свої ідеї. Це про будівництво довіри і зменшення неоднозначності в колективному середовищі.

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

Проілюструємо це на практичному прикладі. Припустимо, що ви зневаджуєте проблему, у якій LLM постійно дає неправильні відповіді під час обробки складних запитів. Для перевірки потоку виконання модуля ви можете скористатися наступною командою у CLI DSPy:

dspy trace --module my_complex_module --depth 3

Ця команда запустить сеанс відстеження, який надає вам змогу перевірити кроки, виконані протягом my_complex_module під час обробки нагадування. Вивід, який може містити рядки типу « Teleprompter invoked with context size 128 » або « Optimizer applied euristic delta- one », можна використовувати як основу для подальшого обговорення. Ви можете пояснити: « За допомогою сліду можна побачити, що телепромектор отримує значну кількість контекстної інформації, що, можливо, перевищує можливості обробки основного модуля ». Ця фраза є більш точною і дійсною, ніж просто « телепромектор не працює ». Вона безпосередньо пов’ язана зі спостереженою поведінкою і дає змогу визначити потенційну область для оптимізації. Пам’ ятайте, чітке і конкретне спілкування зменшує неоднозначність і сприяє ефективній співпраці у вашій команді.

Нарешті, не вагайтеся задати прояснюючі питання - це завжди краще шукати розуміння, ніж робити припущення. Використання фраз на кшталт «Чи можете ви розібратися, що ви маєте на увазі під «гранулярним підписом» в цьому контексті?» демонструє бажання вчитися і запобігає нерозумінням. Створення словника навколо DSPy не просто про вивчення нових термінів; це про розвиток комунікаційних навичок, необхідних для процвітання в складній, швидко розвивається області.