Bel-Geek - гэта адкрытая пляцоўка для публікацыі артыкулаў розных аўтараў на беларускай мове на свабодныя тэмы.

Перад тым як прыступіць да стварэння ўласнага артыкула, трэба аўтарызавацца. Калі ў вас няма акаунта, то трэба зарэгістравацца на сайце па спасылцы: https://bel-geek.com/register.

Далей трэба націснуць на тры кропкі ў шапцы сайта, каб з'явілася меню. Выбраць пункт "Стварыць артыкул", і перайсці на старонку рэдактара, ці скарыстацца спасылкай: https://bel-geek.com/editor/add

Пры стварэнні артыкула абавязкова трэба дадаць назву артыкула, імя аўтара ды тэгі ў адпаведныя палі формы, пажадана дадаць апісанне.

Напрыклад:

Як бачна на малюнку, з правага боку будзе панэль, на якой знаходзіцца прадагляд артыкула. З левага боку - рэдактар.

Важна!

Захоўвайце час ад часу свае артыкулы з дапамогай кнопкі "Захаваць" (працуем над аўтазахаваннем), каб выпадкова не згубіць напісанае. Таксама можна захаваць напісанае і адкласці работу з артыкулам на іншы дзень.

Калі вы ўжо вядзеце блогі ў іншых сацыяльных сетках, то дадавайце спасылкі на іх у сваіх артыкулах, каб чытачы маглі знайсці больш цікавай ім інфармацыі.

Калі артыкул будзе гатовы, трэба перавесці перамыкач над рэдактарам тэксту "Паказваць усім" у актыўнае становішча і націснуць кнопку "Захаваць".

PS. Калі вы ствараеце пераклад - то абавязкова пакідайце спасылкі на арыгінал.

---

Карысныя спасылкі, якімі можна карыстацца падчас напісання артыкулаў:

Мноства слоўнікаў: https://slounik.org/

Правапіс слоў у розных склонах і ліках: https://starnik.by/

Гэты артыкул - абагульненне некалькіх артыкулаў пра новы напрамак, які ўжо зараз ператвараецца у новую прафесію , якая з часам будзе вельмі запатрабаванай.

Context Engineering: Новая прафесія на скрыжаванні інтэлекту і інфармацыі

1. Чаму гэта важна?

Сённяшнія LLMs — гэта не проста тэкставыя генератары. Гэта магутныя сістэмы, здольныя:

• аналізаваць інфармацыю;
• будаваць лагічныя ланцужкі;
• прымаць рашэнні;
• падтрымліваць складаныя дыялогі.

Аднак іх здольнасці абмяжоўваюцца толькі тым, які кантэкст яны атрымліваюць. І нават самая дасканалая мадэль будзе марнаваць свой патэнцыял, калі “не зразумее”, што ад яе патрабуецца.

Кантэкст — гэта не проста запыт. Гэта цэлае інфармацыйнае асяроддзе, у якім працуе ШІ: дакументы, прыклады, накіраванні, ранейшыя размовы, — усё, што ўплывае на разуменне і прыняцце рашэння. І тое, як мы ствараем і падаем гэты кантэкст, — вызначае эфектыўнасць усяго ўзаемадзеяння з мадэллю.

Так з’явілася цэлая галіна — context engineering. Яна вырасла з prompt engineering і ператварылася ў асобную прафесію, якая спалучае тэхналогіі, логіку і інфармацыйны дызайн. Гаворка ідзе пра сістэмны падыход да працы з кантэкстам: ад яго пошуку да кіравання ім у рэжыме рэальнага часу.

⸻

2. Аснова context engineering — што яна сабой уяўляе?

Калі prompt engineering — гэта пра тое, як сфармуляваць запыт, то context engineering — гэта пра стварэнне ўмоў для разумнага адказу. Гэта як не проста задаць пытанне, а даць чалавеку дакументы, факты, прыклады і мову, якой варта карыстацца.

Context engineering ахоплівае тры асноўныя кампаненты:

2.1. Context retrieval and generation

На першым этапе трэба знайсці і падаць мадэлі патрэбную інфармацыю:

• Prompt engineering — базавыя запыты і іх структура.
• In-context learning — метады накшталт zero-shot, few-shot, chain-of-thought, калі мадэль вучыцца на прыкладах унутры кантэксту.
• Retrieval знешніх ведаў — напрыклад, з баз дадзеных ці дакументаў (retrieval-augmented generation).
• Дынамічныя шаблоны — адаптыўныя запыты (напрыклад, CLEAR framework), якія змяняюцца ў залежнасці ад сітуацыі.

2.2. Context processing

Далей — апрацоўка інфармацыі:

• Працэсінг доўгіх паслядоўнасцей — мадэлі, здольныя працаваць з тэкстамі на тысячы токенаў (Mamba, LongNet).
• Самаўдасканаленне — мадэлі, што вучацца з уласных адказаў і карэктуюць кантэкст.
• Мультымадальнасць — камбінацыя тэксту, гуку, выяваў, табліц.
• Аптымізацыя ўвагі і памяці — тэхнікі сціску, sparsity, забывання непатрэбнага.

2.3. Context management

І, нарэшце, кіраванне кантэкстам у часе:

• Памяць: кароткатэрміновая (размова), доўгатэрміновая (біяграфія карыстальніка), знешняя (базы дадзеных).
• Context compression — аўтакодэры, рэкурэнтнае сцісканне.
• Paging — падзел кантэксту на старонкі з доступам да патрэбнай інфармацыі.
• Маштабаванае кіраванне — для складаных сцэнароў з некалькімі агентамі.

3. Як гэта працуе: архітэктурныя рашэнні

Context engineering ужо ўвасабляецца ў канкрэтныя тэхнічныя мадэлі і архітэктуры. Вось некалькі прыкладаў:

3.1. Retrieval-augmented generation (RAG)

Калі мадэль не мае патрэбнай інфармацыі — яна можа “запытаць” яе звонку. RAG дазваляе LLM:

• шукаць дадатковыя звесткі;
• выкарыстоўваць іх у рэжыме рэальнага часу;
• абапірацца на факты пры генерацыі адказу.

3.2. Сістэмы памяці

LLM з памяццю — гэта мадэль, што не “забывае”:

• можа весці працяглыя дыялогі;
• успамінае вашыя папярэднія пытанні;
• адаптуецца да вашых інтарэсаў (напрыклад, MemGPT).

3.3. Інструментальныя агенты (tools, agents)

Мадэль, што не толькі адказвае, але і дзейнічае:

• запускае код;
• шукае інфармацыю ў інтэрнэце;
• узаемадзейнічае з API.

3.4. Шматагентныя сістэмы

Некаторыя задачы патрабуюць каманды. Шматагентныя сістэмы:

• падзяляюць ролі;
• абменьваюцца кантэкстам;
• працуюць сінхронна для вырашэння складаных задач.

4. Што яшчэ не зроблена: асноўныя праблемы

Тэхналогія развіваецца імкліва, але ёсць і праблемы:

• Разрыў разумення і генерацыі — LLM можа зразумець складаны кантэкст, але не заўсёды здольны стварыць якасны вынік на яго аснове.
• Метрыкі ацэнкі — класічныя метрыкі (BLEU, ROUGE) недастатковыя для ацэнкі reasoning або кааперацыі агентаў.
• Мультымадальная інтэграцыя — цяжка аб’яднаць тэкст, гук, выявы, табліцы ў адзінны лагічны ланцуг.
• Бяспека і этыка — кантэкст можа быць скажоны, маніпулятыўны або прыватны.

5. Напрамкі будучыні: што чакае context engineering

Што будзе развівацца:

• Уніфікаваная тэорыя — фармалізацыя прынцыпаў context engineering.
• Новая генерацыя памяці — мадэлі, што памятаюць не толькі тэкст, але і сэнс.
• Поўная мультымадальная інтэграцыя — тэкст + відэа + аўдыё + графы.
• Лепшыя метады ацэнкі — метрыкі, што ўлічваюць логіку, паслядоўнасць, адаптыўнасць.
• Этычнае разгортванне — празрыстасць, тлумачальнасць, справядлівасць.

6. Рэзюмэ

Context engineering — гэта не проста новы трэнд. Гэта аснова новай хвалі штучнага інтэлекту:

• разумнага;
• адаптыўнага;
• карыснага;
• адказнага.

І калі вы працуеце з LLM, то хутчэй за ўсё — вы ўжо context engineer. Пытанне толькі ў тым, ці робіце вы гэта інтуітыўна — ці свядома і прафесійна.

Крыніцы

1. https://github.com/Marktechpost/AI-Tutorial-Codes-Included
2. https://www.marktechpost.com/2025/08/03/a-technical-roadmap-to-context-engineering-in-llms-mechanisms-benchmarks-and-open-challenges/
3. https://arxiv.org/abs/2507.13334

1. Першае знаёмства: уваход у вайб-кодынг

Не так даўно я выпадкова натрапіў на відэа, дзе нейкі распрацоўшчык за некалькі хвілін стварыў цэлы дадатак з дапамогай штучнага інтэлекту. Сэрвіс называўся bolt.new. Ну і, як не цяжка здагадацца, я вырашыў сам выпрабаваць гэтага звера.

Першыя ўражанні былі, скажам шчыра, вельмі натхняльнымі. Ты даеш каманду — атрымліваеш код. Як у марах юнага дэвелопера: без мітынгаў, рэв’ю і вечаровых званкоў ад праектавага менеджара. Але, як гэта бывае ў казках, усё ішло добра… да пэўнага моманту.

Калі ўзнікла патрэба штосьці змяніць у кодзе — пачаліся праблемы. Bolt вельмі хутка “з’ядае” токены, а з пошукам і выпраўленнем памылак у яго, скажам мякка, праблемы. У выніку — выдатны інструмент для хуткага MVP, але ніяк не для падтрымкі або маштабавання. Так пачалася мая вайб-кодынгавая эпапея.

2. План Б: Copilot і боль у сэрцы

Пасля першага расчаравання я перанёс распрацоўку на лакальны кампутар. Уключыў VS Code, падключыў Copilot — і зноў у бой. Па змаўчанні ён працуе з мадэллю GPT-4.1. Для простых задач — піша, каментуе, дапамагае. Усё выглядае нядрэнна.

Але варта было папрасіць яго зрабіць нешта сур’ёзнае — напрыклад, прааналізаваць некалькі файлаў і прапрацаваць логіку — як усё пачало сыпацца. Памылкі, некансістэнтнасць, кодавы кактэйль з глюкаў. Стала відавочна: праблема — у абмежаваным кантэксце. У рэжыме “агента” мадэль не цягне вялікі аб’ём дадзеных.

Я пераключыўся на Claude Sonnet 3.7 — і тут ужо было лепш. З’явілася надзея. Потым выяыіў што ёсць Sonnet 4 — і тут сапраўды пачалася магія: мадэль пісала код, правярала лінтары і выпраўляла сва ж памылкі, запускала скрыпты ў тэрмінале… Але — так, вы ўжо здагадаліся — токены скончыліся.... І свет зноў стаў шэрым.

3. Cursor: другая спроба магіі

Пасля чарговага фіяска, калі токены скончыліся, а душа — апусцела, я не здаўся. Я вырашыў: “Хопіць гэтага здзеку!” І пайшоў качаць Cursor. Купіў PRO-версію і адразу — у бой.

Cursor у спалучэнні з Sonnet-4 + Max(пашырае кантэкст) працаваў нармальна. Не так глянцава, як Copilot, але дастаткова эфектыўна. Пачаў ствараць дадатак: адзін файл, другі, трэці… Усё ішло добра. Пакуль не стала зразумела — нават з Max мадэль пачынае “забывацца”: губляе кантэкст, выдаляе важныя часткі кода, забывае пра логіку папярэдняй ітэрацыі. Але пакуль — трывожны, але не крытычны сігнал.

Крытычна стала… на наступны дзень. Вы не паверыце — зноў скончыліся токены! Я забіў іх за два дні на 10-экранным дадатку. Было адчуванне, быццам я гляджу, як мая зарплата проста ператвараецца ў пустэчу. Але не здаўся! Купіў Cursor Pro+ і працягнуў (зарплата - да сустрэчы). Бо вайб-кодзінг — ён такі.

4. Момант ісціны: архітэктура ці хаос

Калі дадатак стаў выглядаць як нешта жывое, я вырашыў правесці код-рэв’ю сам сабе. І — жах! Кожны экран быў асобнай “планетай”, ніякіх шаблонаў, усе элементы дубляваліся, як быццам нейкая таямнічая сіла вырашыла паказаць мне, што такое пекла для UI-дызайнера. Кожны асобны экран хоць і быў падоны да папярэдняга але не.

Звычайныя рэчы — кшталту афсэтаў ці водступаў — трэба было выпраўляць рукамі на кожным экране. Прасіць мадэль зрабіць гэта аўтаматычна — марная справа. Яна выпраўляла ў адным месцы, і адначасова ламала у іншым. У гэты момант я ўсвядоміў сваю галоўную памылку: я не прапрацаваў архітэктуру дадатку з самага пачатку.

Па сутнасці, я далей я ўвесь час працаваў як “сеньёр, што на хаду дрэсіруе мадэль-джуна”: “Не! Гэта — асобны кампанент! Тут — вынесем стылі! Не пхай чатыры кампаненты ў адзін файл!” (былі файлы больш за 1000 радкоў). І гэта, канешне, крыху выбівала з каляі.

5. Рэкамендацыі: як не патануць у вайбе

Пасля ўсіх гэтых перыпетый я вырашыў — трэба падзяліцца досведам. Вось некалькі парад тым, хто хоча вайб-кодзіць, але не трапіць у багну:

1. Стварыце структуру. Адразу вызначце, як будуць выглядаць папкі і файлы.
2. Правярайце стылі. Пасля кожнай ітэрацыі сачыце за кансістэнтнасцю.
3. Выносіце кампаненты. Калі нешта паўтараецца — у асобны файл! Але дакладна ўказвайце, куды.
4. Адна задача — адзін промпт. Інакш атрымаеце салянку.
5. Цярпенне — ключ. Мадэль часам бачыць памылку і сама яе выпраўляе. Не спяшайцеся.
6. Каміт — ваш сябра. Калі нешта працуе — фіксуйце. Наступны крок можа ўсё зламаць.
7. Абнуляйце кантэкст. Пачынаеце новую фічу? Стварыце новы чат. І не забывайце пра git commit!

І галоўнае — не губляйце кантроль над грашыма. Гэтыя звяры любяць есці токены, як галодны студэнт — піцу. Не паспееш азірнуцца — усё скончылася. Зноў.

6. Вынікі: без прафесіяналаў — няма магіі

Пасля ўсяго перажытага, адна рэч стала цалкам зразумелай: на дадзены момант без прафесіяналаў штучны інтэлект не здольны ствараць сапраўды якасныя прадукты. Так, ШІ значна паскарае распрацоўку, выконвае шмат руціннай працы, дапамагае “выплюхнуць” MVP у рэкордна кароткія тэрміны. Але ўсё гэта працуе толькі пры ўмове, што побач ёсць чалавек, які ведае, што робіць.

Без правільнага кіравання, мадэлі губляюць кантэкст, паўтараюцца, робяць “выпадковыя” архітэктурныя рашэнні — і вынік нагадвае кодавых маўпаў, якія з нейкай верагоднасцю усё ж напішуць кнігу. Таму, як бы гэта парадаксальна ні гучала, каб не пісаць код — трэба ўсё яшчэ добра яго разумець.

У будучыні, відавочна, мы будзем усё менш і менш пісць код уручную. Але каб сапраўды эфектыўна выкарыстоўваць ШІ, мы павінны вучыцца думаць як інжынеры і кіраваць працэсам — а не проста “размаўляць з ботам”.

І так, халера, токены зноў скончыліся. Але цяпер вы хаця б будзеце ведаць, што рабіць далей.

Прывітанне! Спадарства!

Працягваем наш цыкл артыкулаў пра ШІ (Штучны інтэлект) і як ім карыстацца. Сёння наш артыкул будзе больш тэарытычны. Мы паспрабуем разабрацца, што такое мадэлі, якія яны бываюць, як іх выкарыстоўваць, і якія яны маюць асаблівасці.

Калі вы не чыталі нашыя папярэднія артыкулы - раю пачытаць.

• 🔗 1. Zero-Shot, One-Shot і Few-Shot: Як працаваць з промптамі
• 🔗 2. Grounding або “Як прымусіць мадэль слухацца”
• 🔗 3. Асновы промпт-дызайну: як пісаць эфектыўныя запыты да штучнага інтэлекту
• 🔗 4. Як працаваць з фідбэкамі ў промптынгу: жывы гайд з прыкладамі
• 🔗 5. Як навучыць штучны інтэлект чытаць вашыя дакументы і адказваць на пытанні па іх
• 🔗 6. Першае знаемства за AI-агентамі! Вучым мадэлі узаемадзейнічаць са знешнімі API. Ч1 + Практыка.

Спадзяюся вам будзе цікава, таму паехалі!

І так, як звычайна (ну падаецца ж так у школе рабілі) - давайце разбярэмся з паняццем ШІ-мадэлі.

---

Штучны інтэлект — гэта не чараўніцтва, гэта матэматыка на стэроідах

Калі чуеце “ШІ-мадэль”, можа здацца, што гаворка пра нешта накшталт робата, які думае, як чалавек. Але насамрэч усё куды прасцей (і складаней адначасова). ШІ-мадэль — гэта матэматычная канструкцыя, якая вучылася на даных, каб пасля прадказваць, класіфікаваць ці нават генераваць новыя тэксты, выявы ці коды.

Прыкладам, калі вы карыстаецеся перакладчыкам, атрымліваеце рэкамендацыі ў Spotify або фільтруеце спам у пошце — там працуе адна ці некалькі такіх мадэляў. Але важна разумець: мадэль — гэта не сам алгарытм, а вынік яго прымянення да даных.

Звычайна працэс выглядае так: вы бераце алгарытм (напрыклад, градыентны бустынг, нейронную сетку ці SVM), “корміце” яго дадзенымі — і атрымліваеце мадэль. Потым гэтая мадэль ужо можа самастойна прымаць рашэнні — напрыклад, вызначыць, ці ёсць на здымку котка, ці гэта проста пухнаты коўдрык.

У гэтым артыкуле мы разбярэмся глыбей: чым розныя мадэлі адрозніваюцца, навошта патрэбныя фундаментавыя мадэлі (як GPT,Claude і г.д.), і чаму без магутных GPU сёння не зварганіш нават простага чат-бота.

---

Як ШІ-мадэль “запамінае” інфармацыю: вектары, прасторы і матэматычная магія

Добра, мы ўжо ведаем, што мадэль — гэта вынік навучання на даных. Але ўзнікае лагічнае пытанне: а як яна ўсё гэта захоўвае? Ці не захоўвае, як Google Docs?

Не. ШІ-мадэль нічога не запамінае “па-людску”. Яна не ведае, што “котка” мякае, а “піцца” смачная. Замест гэтага яна ўяўляе сабе свет праз вектары — гэта матэматычныя аб’екты, якія складаюцца з набораў лікаў. Груба кажучы, кожнае слова, карцінка, запыт ці нават паняцце пераўтвараецца ў лічбавы код — набор значэнняў у прасторы з сотнямі ці тысячамі вымярэнняў.

---

🧠 Прыклад:

“котка” = [0.12, -0.98, 3.45, …]

Калі мадэль “думае” пра слова “котка” (звыяайна яна стварае вектары для цэлых выразаў), яна працуе не з тэкстам, а з яго вектарным уяўленнем. Тое ж самае са словам “сабака”, “пухнаты”, “мурлыкае” і г.д.

---

(Візуалізацыя вектараў. Зверху злева - вектары тэкстаў пра промптынг. Знізу справа - вектары тэкстаў пра беларускую мову. )

---

Цікава, што вектары, блізкія ў гэтай шматмернай прасторы, азначаюць паняцці, блізкія па сэнсе. Напрыклад, калі вектар “котка” побач з “сабака”, гэта значыць, што мадэль навучылася бачыць нешта агульнае паміж імі (жывёлы, хатнія, пухнатыя).

Як вектары параўноўваюцца?

Мадэль вымярае косінуснае падабенства або эўклідаву адлегласць паміж вектарамі. Прасцей кажучы — яна вылічвае, наколькі “паралельныя” ці “блізкія” вектары адзін да аднаго. Чым меншая адлегласць або большы косінус, тым мацней сувязь паміж паняццямі.

Так, напрыклад, у вялікіх мовахвых мадэлях (LLM) тыпу GPT:

• “Мінск” + “Беларусь” ≈ “Парыж” + “Францыя”
• “Кніга” + “чытаць” — “папера” ≈ “электронная”

І навошта гэта трэба?

Усё, ад разумення пытанняў карыстальніка да генерацыі адказаў, адбываецца праз маніпуляцыю гэтымі вектарамі. Калі вы пішаце ў чат: “парай фільм як Inception”, мадэль шукае вектар “Inception”, знаходзіць яго суседзяў у прасторы (напрыклад, “Interstellar”, “Tenet”), і на аснове гэтага генеруе рэкамендацыю.

Не ўсе ШІ-мадэлі аднолькавыя: як іх падзяляюць

Разнастайнасць мадэляў уражвае. Так можна знайсці мадэлі якія займаюцца аналізам мапаў ці выяўленнем хвароб па здымках.

Давайце паспрабуем неяк тыпізаваць ШІ мадэлі.

Пачнем з таго, што мадэлі могуць падзяляцца па тыпах дадзеных з якімі яны працуюць:

🧠 Моўныя мадэлі (LLM)

Працуюць з тэкстам: разумеюць, працягваюць, аналізуюць, генеруюць. Сучасныя прыклады:

• Qwen 3 — падтрымлівае як dense, так і Mixture-of-Experts архітэктуры.
• Gemma 3 — кампактная, эфектыўная, працуе нават на 1 GPU.
• DeepSeek-R1 — робіць упор на разважанне і лагіку.
• LLaMA 3.3 / 4 — новыя open-source LLM.

---

👁 Візуальныя мадэлі (Computer Vision / Multimodal Vision)

Працуюць з выявамі: распазнаюць, аналізуюць, генеруюць.

• LLaMA 4 Vision — разумее малюнкі і можа адказваць на пытанні па візуальным кантэксце.
• Gemma Vision — маштабаваная візуальная мадэль ад Google.
• DALL-E

🎤 Гукавыя і маўленчыя мадэлі

Для распазнавання маўлення, генерацыі голасу, эмоцый і г.д. (Пакуль найноўшых open-source канкурэнтаў Whisper або VALL-E не шмат, але чакаюцца.)

🔀 Мультымадальныя (Multimodal)

Здольныя апрацоўваць некалькі тыпаў дадзеных: тэкст + выява, тэкст + аўдыё і інш. Напрыклад LLaMA 4 — аб’ядноўвае моўную мадэль з магчымасцю анвлізаваць выявы і падтрымлівае агенты (Пра іх у наступных артыкулах).

---

🧰 Па функцыянальнасці мадэлі можна падзяліць:

1. Адназадачныя мадэлі (Task-specific) Тонка адаптаваныя пад адну задачу (напрыклад, генерацыя SQL, аўтаматычны медыцынскі аналіз).
2. Шыроказадачныя мадэлі (General-purpose) Выконваюць мноства задач без спецыфічнай адаптацыі. Сюды адносяцца ўсе сучасныя флагманскія мадэлі: Qwen 3, LLaMA 3.3, Gemma 3, DeepSeek-R1.
3. Агенты з інструментамі (Tool-augmented models) Могуць карыстацца раўзам з калькулятарамі, пошукам, базамі даных, нават іншымі ШІ. Прыклад: GPT-4 Turbo з інструментамі, LLaMA 4 Agents, DeepSeek Agent (на базе R1).

---

🏋️ Па памеры мадэлі можна падзяліць па колькасці параметраў якія яны падтрымліваюць (В - Мільярды):

• Tiny / Small (0.6B – 4B параметраў) — працуе на лакальных прыладах.
• Medium (7B – 14B) — патрабуе GPU, працуе стабільна.
• Large (30B – 70B) — для дата-цэнтраў або энтузіястаў з кластарамі.
• Ultra-large (100B – 700B+) — патрэбен спец-абсталяванне.

---

Давайце разгледзім асаблівасці мадэляў, пра якія вы магчыма і не ведалі.

🧠 Мадэль — не чалавек. Яна нічога не “памятае”

Можна падумаць, што калі мадэль адказвае на вашы пытанні з улікам папярэдніх, то яна “памятае” размову. Але гэта ілюзія. У рэчаіснасці мадэль — гэта матэматычная функцыя, якая не мае памяці ў чалавечым сэнсе.

---

Кантэкст — вось дзе “жыве” ўся памяць

Кожны раз, калі вы адпраўляеце запыт у мадэль, разам з ім перадаецца так званы кантэкст — тэкст папярэдніх размоў, дакументаў, інструкцый. Гэта як калі б вы далі чалавеку шпаргалку перад тым, як нешта спытаць. І калі наступны запыт не ўтрымлівае папярэдні тэкст — мадэль усё “забывае”.

📌 Мадэль не захоўвае ніякай інфармацыі пасля адказу. Усё, што яна “ведае”, — гэта тое, што вы ёй перадалі ў бягучы момант.

---

Чаму гэта важна?

Бо гэта азначае, што мадэль не можа запамінаць карыстальнікаў, кантэкст размовы ці падзеі. Мадэль памятае толькі тыя дадзеныя якім яе навучылі пад час навучання ці файн-цюнінгу. Калі вам здаецца, што яна “памятае”, гэта не заслуга мадэлі, а сістэмы вакол яе, якая:

• захоўвае кантэкст,
• дынамічна яго падгружае,
• або выкарыстоўвае вектарныя базы даных ці іншыя інструменты, каб аднавіць патрэбную інфармацыю.

🧊 Мадэль — гэта “замарожаная матэматыка”

Калі вельмі спрасціць: мадэль — гэта функцыя, якая пераўтварае ўваход (запыт + кантэкст) у выхад (адказ). І ўсё. У ёй няма ніякай унутранай дынамікі, якая б змянялася паміж выклікамі. (У больш простых мадэлях можна заўважыць што на адзін і той жа промпт будзе адзін і той жа адказ)

Гэта як калькулятар: вы ўвялі 2 + 2 — атрымалі 4. Калі хочаце атрымаць 4 зноў — трэба зноў увесці 2 + 2.

Усё, што звязана з “памяццю”, “асабістай гісторыяй”, “ўзгадваннем”, — гэта архітэктурныя надбудовы. Напрыклад, агенты з “памяццю” працуюць так:

1. Увесь дыялог захоўваецца звонку (у базе, файле ці вектарнай сістэме).
2. Пры кожным новым запыце, агент адшуквае адпаведныя фрагменты з “памяці”.
3. Ён дадае іх у кантэкст, і толькі потым перадае ўсё мадэлі.

Сама мадэль нават не “ведае”, што гэты тэкст з памяці — для яе гэта проста яшчэ адна частка ўваходу.

🙅‍♂️ Ці можа мадэль навучацца падчас размовы?

Не. Тыповая ШІ-мадэль (у тым ліку GPT, Claude, LLaMA) не мяняе сябе падчас працы. Каб яна нешта “навучылася”, трэба прайсці працэс рэтрэйнінгу або файнт’юнінгу, і гэта цэлы асобны этап, які не адбываецца падчас чата.

Нават калі мадэль 100 разоў адказала няправільна — яна працягне рабіць тое ж самае, пакуль вы самі не створыце новую мадэль або не зменіце кантэкст.

📏 Кантэкст не гумавы: чаму мадэль не можа “прачытаць усё”

Адна з найбольш частых памылак карыстальнікаў у разуменні ШІ — ілюзія, што мадэль можа працаваць з “усёй кнігай”, “усёй базай даных”, ці “вялікай колькасцю дакументаў адначасова”. Але гэта не так. Мадэлі маюць строгае абмежаванне на памер кантэксту, які яны могуць апрацаваць за раз.

---

Што такое кантэкст у тэхнічным сэнсе?

Кантэкст — гэта ўвесь набор інфармацыі, якую вы перадаеце мадэлі пры адным выкліку: ваш запыт, інструкцыі, дакументы, гісторыя дыялогу і г.д. Гэта не проста “тэкст”, а набор токенаў — спецыяльных адзінак, на якія разбіваецца тэкст для апрацоўкі.

Прыклад:

Слова “котка” — гэта 1 токен. Слова “аўтамабілебудаванне” — можа змяшчаць 2-3 токены. Англійскае “The quick brown fox jumps over the lazy dog.” — гэта 9 токенаў.

Колькі токенаў “могуць трымаць” сучасныя мадэлі?

1. GPT-3.5 - 4 096 токенаў
2. GPT-4 - 8 192 - 32 000 токенаў
3. GPT-4o - да 128 000 токенаў
4. Claude 3 - да 200 000 токенаў
5. LLaMA 3 - звычайна - 8k - 32k токенаў

128 000 токенаў — гэта прыкладна 300 старонак тэксту. Здаецца шмат? Але гэта хутка скончваецца, калі вы дадаеце, напрыклад, тэхнічную дакументацыю або код.

🧨 Што адбываецца, калі перадаць занадта шмат?

1. Промпт не змесціцца — мадэль адмовіцца апрацоўваць яго або абрэжа частку (звычайна пачатак) і згубіцца частка дадзеных.
2. Калі вы падаеце занадта доўгія тэксты, важныя часткі могуць быць “адсунуты” за межы бачнасці.
3. Меншая дакладнасць — нават калі ўся інфармацыя змяшчаецца, мадэль можа “згубіцца” ў аб’ёме і прапусціць важнае.

---

Чаму проста не зрабіць “бясконцы кантэкст”?

Праблема ў тым, што ўсе токены апрацоўваюцца разам — і чым іх больш, тым:

• больш памяці патрабуецца на GPU (Працэсары якія апрацоўваюць дадзеныя),
• больш часу займае вылічэнне,
• горш працуе ўвага (attention): мадэль “распыляецца” і не разумее, на што глядзець.

Як працаваць з вялікімі дадзенымі?

Калі тэкст не ўмяшчаецца ў кантэкст, існуюць рашэнні:

1. 🔍 RAG (Retrieval-Augmented Generation) — выбар найбольш рэлевантных кавалкаў перад кожным запытам
2. 📚 Вектарны пошук — знаходжанне блізкіх па сэнсе тэкстаў
3. 🪓 Разбіццё — вы даяце інфармацыю часткамі
4. 🧠 Агент з памяццю — выкарыстоўвае знешнюю базу, каб “узгадваць” ранейшае

✨ Падвядзем вынікі…

Фух! Калі вы дачыталі да гэтага моманту — вы ўжо амаль эксперт 😎 Давайце яшчэ раз коратка прабяжымся па галоўным:

✅ ШІ-мадэль — гэта не магія, а матэматыка, якая вучылася на даных ✅ Усе “веды” мадэлі захоўваюцца не як у чалавечай памяці, а ў вектарах ✅ Мадэль не памятае вас — уся “памяць” жыве ў кантэксце ✅ Ёсць шмат розных мадэляў: па тыпу дадзеных, функцыянальнасці і памеры ✅ Кантэкст абмежаваны — і гэта не баг, а фіча, з якой трэба працаваць ✅ “Навучыць мадэль у размове” — пакуль не зусім рэальнасць

Так што, калі вам здаецца, што ШІ “разумее” або “памятае” — успомніце, што на самой справе перад вамі вельмі разумны калькулятар, а не віртуальны Ян Баян з амнэзіяй 🙂

---

✍️ ЗЫ: Хочаце стаць суаўтарам?

Калі вы чытаеце гэта і думаеце: “О, я б таксама мог/магла напісаць пра што-небудзь па-беларуску!” — мы вас чакаем! Хутка будзе новы артыкул пра агентаў і інструменты, але мы адкрытыя да новых тэм, голасаў і ідэй. Калі ласка далучайцеся да нас! Пішыце, прапаноўвайце, далучайцеся! Ну і вы можаце падтрымаць нашы высілкі праз кнопку "Падтрымаць праект" у версе старонкі

Прывітанне, спадарства!

Сёння працягваем цыкл артыкулаў пра ШІ.

• 🔗 1. Zero-Shot, One-Shot і Few-Shot: Як працаваць з промптамі
• 🔗 2. Grounding або “Як прымусіць мадэль слухацца”
• 🔗 3. Асновы промпт-дызайну: як пісаць эфектыўныя запыты да штучнага інтэлекту
• 🔗 4. Як працаваць з фідбэкамі ў промптынгу: жывы гайд з прыкладамі
• 🔗 5. Як навучыць штучны інтэлект чытаць вашыя дакументы і адказваць на пытанні па іх

I на гэты раз мы з вамі занырнем у бязконцую тэму ШІ-агентаў (ці проста агентаў). А што гэта такое і куды мы будзем занырваць мы даведаемся ніжэй! І так пачынаем!

Як мы ўжо пісалі у папярэдніх артыкулах, ШІ-мадэлі (далей проста мадэлі) адарваныя ад сусвету гэтак жа як племя індзейцаў у Амазоніі. Мадэлі не маюць уласнай караткачасовай памяці і не могуць самастойна узаемадзейнічаць з інтэрнэтам і іншым сусветам. І вось тут у гульню урываюцца агенты.

(Нашчасце не гэтыя)

Добра ўсё ўмець, ды не ўсё рабіць.

Гэтая народная мудрасць добра пасуе і да свету штучнага інтэлекту. Мадэлі валодаюць велізарнымі ведамі і могуць падрабязна распавесці, як выканаць амаль любую задачу. Але — як і сапраўдны мудрэц — самі ў справы не ўмешваюцца. Іх справа — ведаць, тлумачыць, планаваць. А ўжо рабіць павінны іншыя — у нашым выпадку, агенты.

Агент слухае парады мадэлі і бярэ справу ў свае рукі:

• выкарыстоўвае інтэлект мадэлі, але і ўмее самастойна:
• рабіць запыты да API,
• чытаць і пісаць файлы,
• працаваць з базамі дадзеных,
• аўтаматызаваць задачы і кіраваць працэсамі.

Калі параўноўваць з жыццём — мадэль як вопытны архітэктар: плануе, раіць, у дэталях распісвае, што і як павінна быць. А агент — гэта будаўнічая брыгада, якая бярэ чарцяжы і ўзводзіць дом. Такім чынам камбінацыі мадэляў ды агентаў могуць рабіць вялікую колькасць рэчаў якія недасяжныя проста мадэлям.

Калі вы карыстаецеся чатам GPT - то магчыма заўважылі што Яго магчымасці не абмежаваныя толькі напісаннем тэкста. Ен можа напрыклад, і csv файл стварыць і нешта намаляваць. Гэтыя і іншыя яго магчымасці рэалізаваныя праз агенты.

Хто дарогу пытаець, той не блукаець.

Каб не заблытацца ў тэрмінах, давайце адразу разбярэмся, хто ёсць хто ў гэтым свеце.

• Функцыі (Functions) — гэта канкрэтныя дзеянні, якія можа выканаць агент. Напрыклад, зрабіць API-запыт, захаваць файл, правесці разлік ці нават намаляваць графік. Гэта як асобныя інструменты ў скрыні: малаток, адвёртка, ключ — кожны мае сваё прызначэнне. Часцей за ўсё функцыі - тое ж што і ў праграмаванні
• Тулы (Tools) — гэта наборы функцый (ці адна), сабраныя для пэўнай задачы. Напрыклад, тул для працы з API можа мець функцыі для GET і POST запытаў, а тул для працы з файламі — функцыі чытання і запісу CSV або JSON. Іншымі словамі, тул — гэта як добра ўкамплектаваная скрыня інструментаў для канкрэтнай працы.
• Агенты (Agents) — гэта арганізатары ўсяго гэтага працэсу. Агент атрымлівае задачу, аналізуе, якія тулы і функцыі патрэбныя, і кіруе іх выкарыстаннем. Ён, быццам прараб на будоўлі, раздае каманды: «Ты ідзі зрабі API-запыт», «Ты прачытай файл», «Ты згенеруй справаздачу».

📌 Важна! Агент сам не выконвае працу — ён кіруе працэсам і прымае рашэнні, калі і што трэба выкарыстоўваць.

Трэба адзначыць што розніца паміж туламі і функцыямі вельмі абстрактная і ў многіх артыкулах выкарыстоўваецца ці адно ці другое. Таму калі што - то будзеце ведаць што розніцы амаль няма.

Пачынаем ствараць сусвет з блэкджэкам і ... агентамі

І так практыка. Шмат коду пісаць не будзем, баяцца не трэба. Але я б рэкамендаваў стварыць тэлеграм бота для зручнасці тэсціравання і выкарыстання нашага бота.

Паехалі!

Першае - ствараем бота:

Каб стварыць бота - дастаткова перайсці ў афіцыйны бот тэлеграма https://t.me/BotFather - і націснуць кнопку "старт". Затым са спісу каманд выбраць /newbot і ўвесці імя бота. (Павінна скончвацца на _bot). У выніку мы атрымаем спасылку на нашага бота і HTTP API. Усё! Бот створаны. зараз трэба заставіць яго працаваць. (Ключ нам спатрэбіцца - не выдаляем)

Другое - наладжваем асяроддзе

Бярэм гатовы код з https://github.com/bel-frontend/RAG у тэчцы lesson4_agent ствараем файл .env. І запісваем туды свой ключ

TELEGRAM_BOT_TOKEN=your_token 

Далей выконваем каманду у тэрмінале

bun install

Калі ў цябе bun не ўсталяваны - то глядзі тут

Не забываем пра ollama. Калі не ўсталявана - глядзім там жа і правяраем каб была ўсталявана мадэль mistral-small3.1

(Яе абраў таму, што гэта мадэль падтрымлівае tools і яна бясплатная. Так, не ўсе мадэлі могуць працаваць з агентамі):

ollama list

У спісе няма гэтай мадэлі? - усталёўваем

ollama run mistral-small3.1

Ну, лічы ўсё гатова.

Трэцяе - запускаем чатбота. Надвор'е, прыказкі і сабачкі.

Ну што, даражэнькія, вось мы і дабраліся да самага цікавага — глядзім, на што наш агент здатны! 😎

Запускаем бота камандай у тэрмінале:

bun  index.ts

І… пагналі тэставаць яго ў тэлеграме!

• «Якое надвор’е ў Менску?» — спойлер: як заўсёды — хмурна і вільготна. Нічога новага, Менск жыве па сваіх правілах! 🌧️
• «Пакажы сабачку!» — і экран імгненна напаўняецца пазітывам у выглядзе мілай сабачай мордачкі 🐶. Ну скажыце, хіба можна не ўсміхнуцца?
• «Дай прыказку пра сяброўства» — тут хацелі як лепш, але атрымалася… ну, як атрымалася.🤷

📸 Глядзіце, вось наш агент з MISTRAL у справе:

Як бачна, з надвор’ем і сабачкамі ён спраўляецца на ўсе сто. А вось з народнай мудрасцю — мудрасці не завезлі (і беларускай мовы, калі па праўдзе 😅).

Але не спяшаемся засмучацца! Давайце правядзём невялічкі батл: наш агент з мадэллю mistral-small3.1 супраць нашага агента з GPT-4o!

📸 Вось як спраўляецца ён жа з GPT-4o (хто б сумняваўся — значна лепш):

Вынікі батлу - 3:2 на карысць GPT-4o.

Так што галоўная выснова — чым больш магутная мадэль, тым лепш працуе агент, нават калі код не змяняецца ні на радок!

Ну а зараз, мы ж сюды не сабачак глядзець прышлі, давайце зазірнем, як жа мы ўсё гэта накодзілі! 👇

Код — дзе тут агент і хто ва ўсім вінаваты? 🤖

import { createReactAgent } from '@langchain/langgraph/prebuilt';
import { chatModel, Model } from './model';
import { tool } from '@langchain/core/tools';
import { z } from 'zod';
import { SystemMessage } from '@langchain/core/messages';

const fetchJson = async (url: string) => {
    const res = await fetch(url);
    if (!res.ok) throw new Error(`Fetch error ${res.status}`);
    return res.json();
};

const fetchText = async (url: string) => {
    const res = await fetch(url);
    if (!res.ok) throw new Error(`Fetch error ${res.status}`);
    return res.text();
};

// 📦 Інструмент 1: надвор'е
const weatherTool = tool(
    async ({ city }: { city: string }) => {
        const res = await fetchText(`https://wttr.in/${city}?format=3`);
        return res || 'Cannot find weather.';
    },
    {
        name: 'get_weather',
        description: 'Get current weather for a given city',
        schema: z.object({ city: z.string() }), // выкарыстоўваецца для валідацыі
    }
);

const getProverbByTopic = tool(
    async () => {
        console.log('Fetching proverbs');

        const res = (await fetchJson(
            'https://gist.githubusercontent.com/bel-frontend/41775a79904f2535c4dd97d7990ad83d/raw/dc6c5cb1a849961833dd157454fd3ec11129883b/index.json'
        )) as { message: string }[];

        console.log(res);

        const allProverbsInOneString = res.reduce((acc, curr) => {
            return acc + curr.message + '\n';
        }, '');

        return allProverbsInOneString || 'Cannot find proverbs.';
    },
    {
        name: 'get_proverb_by_topic',
        description:
            'Get full list of proverbs for search or selecting by topic or random',
    }
);

const model = await chatModel(Model.MISTRAL);

export const agentApp = ({ bot, userId }: { bot: any; userId: number }) => {
    const getDogPhoto = tool(
        async () => {
            const res = (await fetchJson(
                'https://dog.ceo/api/breeds/image/random'
            )) as { message: string };
            const imageUrl = res?.message;
            if (!imageUrl) return 'Не ўдалося атрымаць выяву сабакі.';
            bot.sendPhoto(userId, imageUrl);

            return 'Выява сабакі дасланая.';
        },
        {
            name: 'get_dog_photo',
            description: `Send to user random dog photo`,
        }
    );

    return createReactAgent({
        llm: model,
        tools: [weatherTool, getProverbByTopic, getDogPhoto],
        messageModifier:
            new SystemMessage(`Ты разумны памочнік. Адказвай зразумела і каротка. Адказвай на пытанні толькі
      адносна надвор'я, генерацыі прыказак і фоты сабакі. Калі пытанне не адносіцца да гэтых тэм, скажы "Я не ведаю".`),
    });
};

Больш за ўсе нас цікавіць вось гэты кавалак -

return createReactAgent({
    llm: model,
    tools: [weatherTool, getProverbByTopic, getDogPhoto],
    messageModifier: new SystemMessage(`Ты разумны памочнік...`)
});

🛠️ Што тут адбываецца?

1. llm: model — тут мы падключаем нашу мадэль. У нашым выпадку — MISTRAL, таму і працуем скромна, без паэзіі, затое бясплатна!
2. tools: [weatherTool, getProverbByTopic, getDogPhoto] — гэта як быццам мы перадалі агенту скрыню з інструментамі і сказалі: «Вось табе малаток, адвёртка і фотапарат.»
3. messageModifier: SystemMessage(…) — а гэта ўжо інструкцыя для нашага агента.

Калі глядзець на тулы- то на прыкладзе

const weatherTool = tool(
    async ({ city }: { city: string }) => {
        const res = await fetchText(`https://wttr.in/${city}?format=3`);
        return res || 'Cannot find weather.';
    },
    {
        name: 'get_weather',
        description: 'Get current weather for a given city',
        schema: z.object({ city: z.string() }), // выкарыстоўваецца для валідацыі
    }
);

Тут можам пабачыць базавую структуру функцыі, якая атрымлівае горад і выртае надвор'е. Звярніце увагу на тое як мы апісваем тул і як мы параметрызуем уваходзячыя дадзеныя. Гэта важна і спатрэбіцца пры напісанні больш складаных тулоў.

Так агент і працуе — разумнае кіраўніцтва (залежыць ад мадэлі канешне), мінімум разважанняў і максімум дакладнасці.

Вынікі:

Ну што, уся філасофія агенцкай працы цяпер як на далоні! Далей — альбо пашыраем яго магчымасці, альбо ганарымся тым, што ўжо маем! 😉

💡 Але гэта толькі размінка!

Тое, што мы зрабілі — самы просты варыянт агента. А ў сапраўдным жыцці агенты могуць быць нашмат магутнейшымі:

• выкарыстоўваць іншыя ШІ-мадэлі як інструменты;
• працаваць у камандзе з іншымі агентамі;
• будаваць цэлыя ланцужкі рашэнняў і аўтаматызаваць складаныя бізнес-працэсы.

📅 У наступным артыкуле мы падрабязна пагаворым пра:

• архітэктуры працы агентаў (ReAct, AutoGPT, LangGraph і іншыя);
• як правільна ствараць і арганізоўваць складаных агентаў;
• і як навучыць агента прымаць рашэнні, а не толькі выконваць загады.

Так што заставайцеся з намі — далей будзе толькі цікавей! 😉

Прывітанне, спадарства!

Працягваем наш цудоўны цыкл артыкулаў пра промптынг 🤖✨

Сёння мы разбяром 4 эфектыўныя тэхнікі фідбэк-промптынгу, якія дапамогуць атрымліваць ад AI яшчэ лепшыя вынікі! 🚀

Папярэднія артыкулы:

• 🔗 1. Zero-Shot, One-Shot і Few-Shot: Як працаваць з промптамі
• 🔗 2. Grounding або “Як прымусіць мадэль слухацца”
• 🔗 3.Асновы промпт-дызайну: як пісаць эфектыўныя запыты да штучнага інтэлекту

🧠 Што за тэхнікі і адкуль яны?

Каб працаваць з AI максімальна эфектыўна, спецыялісты стварылі шэраг магутных тэхнік 🛠️. Яны нарадзіліся на скрыжаванні навукі, інжынернай практыкі і штодзённага досведу карыстальнікаў.

Асноўныя метады фідбэк-промптынгу:

• ✍️ Explicit Feedback Prompting — адкрытае выказванне заўваг і пажаданняў.
• 🔄 Iterative Refinement — паступовае ўдакладненне адказаў праз некалькі ітэрацый.
• 🧐 Critique and Revision Prompting — мадэль сама крытыкуе і паляпшае вынік.
• 🧩 RLHF (Reinforcement Learning from Human Feedback) — выбар найлепшага з некалькіх варыянтаў.

---

✍️ 1. Explicit Feedback Prompting

Пачнем з простага, але вельмі дзейнага спосабу!

Што гэта:

Вы даяце мадэлі канкрэтны і ветлівы фідбэк 📜: што трэба змяніць і як палепшыць адказ.

Калі карысна:

Калі першы адказ выглядае павярхоўным або няпоўным 🔍

Як гэта выглядае:

Промпт:

Напішы артыкул пра цікавыя факты пра Антарктыду.

Першы адказ:

Антарктыда — халодны кантынент. Тут амаль няма расліннасці і жывёл.

Фідбэк:

Тэкст выглядае занадта агульна.
Калі ласка, дадай канкрэтныя дадзеныя пра тэмпературы, даследчыя станцыі
і мясцовую фаўну

Перапрацаваны адказ:

Антарктыда — самы халодны кантынент,
дзе сярэдняя тэмпература ўзімку дасягае -60°C.
Тут каля 70 даследчых станцый, а з жывёл вядомыя імператарскія пінгвіны і цюлені Уэдэла.

---

🔄 2. Iterative Refinement

Працягваем! Паглядзім, як можна шліфаваць вынікі крок за крокам 🔧

Што гэта:

Паступовае ўдакладненне і паляпшэнне адказаў у некалькі этапаў.

Калі карысна:

Калі хочаце дамагчыся максімальнай якасці ✨

Промпт 1:

Напішы рэзюмэ кнігі "1984" Джорджа Оруэла.

Адказ:

"1984" — гэта раман пра таталітарную дзяржаву, дзе герой Уінстан спрабуе супраціўляцца сістэме.

Фідбэк:

Дадай больш эмацыйных момантаў і падкрэслі страх Уінстана перад Вялікім Братам

Перапрацаваны адказ:

"1984" распавядае пра жыццё пад татальным наглядам, дзе Уінстан Сміт жыве ў пастаянным страху і спрабуе захаваць чалавечнасць.

І гэтак далей. Такім чынам мы кожную ітэрацыю ўдакладняем вынікі працы мадэлі да таго моманту пакуль не атрымаем неабхоодны нам фармат.

---

🧐 3. Critique and Revision Prompting

Наступны ўзровень! Прымушаем AI крытыкаваць самога сябе 🕵️‍♂️

Што гэта:

Мадэль сама ацэньвае якасць свайго адказу і прапануе паляпшэнні.

Калі карысна:

Калі хочаце прабудзіць у мадэлі крытычнае мысленне 🧠

Промпт:

Напішы эсэ пра важнасць экалагічнай свядомасці. Потым ацэні і паляпшай свой тэкст 

Першы адказ:

Экалагічная свядомасць дапамагае захаваць прыроду і жыццё на планеце. Трэба сартыраваць смецце і эканоміць рэсурсы.

Крытыка мадэлі:

Прааналізуй тэкст, знайдзі  сталыістычныя і граматычныя памылкі і выпраў  іх.

Перапрацаваны адказ:

Кожны дзень мы выбіраем будучыню: перапрацоўваючы пластык , ашчаджаючы ваду, падтрымліваючы мясцовых вытворцаў. Экалагічная свядомасць — наш унёсак у здаровую планету 

Такім чынам мы застаўляем мадэль зрабіць аналіз і яго ж прымяніць для перапрацоўкі тэксту. Часам гэта бывае вельмі карысна. Гэтая тэхніка актыўна выкарыстоўваецца пры стварэнні агентаў. Падрабязней з вамі разгледзім гэта ў наступныя разы.

---

🧩 4. RLHF (імітацыя ў практыцы)

І нарэшце, тэхніка для тых, хто хоча выбраць самае лепшае 🔥

Што гэта:

Стварэнне некалькіх варыянтаў → выбар лепшага → яго паляпшэнне.

Калі карысна:

Калі хочаце сапраўды ідэальны вынік 🌟

Промпт:

Дай 3 варыянты адказаў на пытанне: чаму важна захоўваць біяразнастайнасць?

Варыянты:

1. Падтрымка экалагічнай раўнавагі 
2. Забеспячэнне ежы і лекаў для чалавецтва 
3. Уплыў на стабільнасць клімату 

Фідбэк:

Трэці варыянт выглядае лепшым! Дадай канкрэтныя факты

Паляпшэнне:

Біяразнастайнасць адыгрывае цэнтральную ролю ў стабільнасці клімату: лясы паглынаюць CO2, а акіяны рэгулююць тэмпературу . Страта відаў вядзе да экалагічных катастроф 

Такая тэхніка працуе калі вы самі правялі нейкі аналіз і больш-менш ведаеце што хочаце атрымаць.

⸻

🎯 Вынікі

Цяпер вы ведаеце:

1. Як даваць AI выразны і дакладны фідбэк ✍️
2. Як удасканальваць вынікі праз некалькі ітэрацый 🔄
3. Як прымушаць мадэль самаацэньваць свае адказы 🧐
4. Як выбіраць і паляпшаць лепшыя варыянты 🧩

Увага! Найбольш добрыя вынікі атрымліваюцца пры камбінацыі розных падыходаў. Але трэба адзначыць, што, паколькі памер кантэксту ў мадэляў не бязмежны, з часам яны могуць згубіць першапачатковыя патрабаванні або панізіць іх вагу. Таму пры астаўленні фідбэка пажадана перыядычна ўдакладняць папярэднія патрабаванні.

---

📣 Паспрабуйце самі!

Напішыце просты промпт і:

1. Ацаніце вынік 🎯
2. Дайце фідбэк 🤓
3. Папрасіце мадэль удакладніць ці крытыкаваць сябе 🔍
4. Стварыце некалькі варыянтаў і выберыце лепшы 🌟

PS:

Дзякуй сябры што застаецеся з намі! Спадзяюся, як заўсёды мой артыкул будзе для вас карысным. Буду вельмі ўдзячны вам за лайкі, каментары, і падтрымку праекта!

Прывітанне, спадарства!

Працягваем наш цыкл артыкулаў пра prompt-дызайн — мастацтва і рамяство працы з вялікімі моўнымі мадэлямі (LLM). Сённяшні артыкул будзе больш агульны, але не менш карысны. Мы сабралі для вас асноўныя прынцыпы, правілы і лайфхакі, як пісаць якасныя промпты. І ўсё гэта — з прыкладамі, тлумачэннямі і звыклым (на самой справе не) лёгкім тонaм. 😌

Калі вы яшчэ не чыталі папярэднія артыкулы — настойліва раім пачаць з іх:

• 🔗 1. Zero-Shot, One-Shot і Few-Shot: Як працаваць з промптамі
• 🔗 2. Grounding або “Як прымусіць мадэль слухацца”

Пра што сёння гаворка

Сёння мы сфармулюем базавыя рэкамендацыі да промптаў. Гэта свайго роду “памятка дызайнера” — толькі не для інтэрфейсаў, а для разумных тэкставых запытаў. Усе прынцыпы былі пераасэнсаваныя на падставе рэальных эксперыментаў і праз уласны досвед на лабараторных работах ад Google. Што такое prompt-дызайн?

Prompt-дызайн — гэта не проста “напісаць запыт у чат”. Гэта сумесь лагічнага мыслення, выразнасці і крэатыву, якая дапамагае атрымаць ад штучнага інтэлекту дакладныя, карысныя і асэнсаваныя адказы. У нейкім сэнсе — гэта як добрае пытанне да мудрага сябра: чым лепш сфармулюеш, тым лепш зразумеюць.

Асноўныя правілы prompt-дызайну:

1. Будзь лаканічным

🟥 Дрэнна:

What do you think could be a good name for a flower shop that specializes
in selling bouquets of dried flowers more than fresh flowers? 
Thank you!

🟩 Добра:

Suggest a name for a flower shop that sells dried flower bouquets.

📌 Чаму гэта важна:

Чым карацей і дакладней ваш запыт, тым менш шанцаў, што мадэль “сыдзе ўбок” ці пачне фантазіраваць. Размытасць = няпэўны вынік.

2. Будзь канкрэтным

🟥 Дрэнна:

Tell me about Earth

🟩 Добра:

Generate a list of ways that makes Earth unique compared to other planets.

📌 Чаму гэта важна:

Чым дакладней вы сфармулюеце сваю задачу, тым больш трапны і структураваны атрымаеце адказ.

3. Адна задача — адзін промпт

🟥 Дрэнна:

What’s the best method of boiling water and why is the sky blue?

🟩 Добра:

Prompt 1: What’s the best method of boiling water?  
Prompt 2: Why is the sky blue?

📌 Чаму гэта важна:

LLM лепш спраўляюцца з адзінкавымі задачамі. Камбінаванне часта дадае блытаніну — для вас і для мадэлі.

4. Пакажы, што ты маеш на ўвазе (праз прыклады)

Хоць мы гэта ўжо разбіралі, але напомнім яшчэ раз: прыклад — лепшы настаўнік.

Zero-shot (без прыкладаў):

Decide whether a Tweet’s sentiment is positive, neutral, or negative.
Tweet: I loved the new YouTube video you made!
Sentiment:

One-shot (з адным прыкладам):

Decide whether a Tweet’s sentiment is positive, neutral, or negative.
Tweet: I loved the new YouTube video you made!
Sentiment: positive

Tweet: That was awful. Super boring 😠
Sentiment:

Few-shot (некалькі прыкладаў):

Tweet: I loved the new YouTube video you made!
Sentiment: positive
Tweet: That was awful. Super boring 😠
Sentiment: negative
Tweet: The video was actually original and fresh.
Sentiment:

📌 Чаму гэта важна:

Прыклад паказвае мадэлі, што ад яе чакаецца. Але памятайце: занадта шмат прыкладаў — гэта ўжо “падручнік”, а не запыт. Дастаткова 3–5.

5. Дадай сістэмныя інструкцыі (калі патрэбны абмежаванні)

Інструкцыі на ўзроўні сістэмы дапамагаюць “трымаць мадэль у межах”.

System Instruction:
You are an AI travel assistant. Only answer questions related to travel.

Prompt:
What’s the best place to visit in Milan? ✅  
What’s for dinner? ❌ — “Sorry, I can’t answer that.”

📌 Чаму гэта важна:

Інструкцыя як “кантрольная мяжа” — мадэль ведае, дзе ёй працаваць, а дзе — не.

6. Замяняй “творчыя” задачы на выбар з варыянтаў

🟥 Дрэнна:

I’m a high school student. Recommend me a programming activity.

🟩 Добра:

Which of these activities should I choose and why?
a) learn Python  
b) learn JavaScript  
c) learn Fortran

📌 Чаму гэта важна: Чым больш структураў вы даяце — тым прасцей кантраляваць вынік.

7. Сачы за “галюцынацыямі”

Так, LLM — разумныя, але не настолькі. Без доступу да актуальных дадзеных, яны могуць “прыдумаць” адказы:

What day is it today?

👉 І адказ можа быць няправільны.

📌 Рашэнне: Для фактычных дадзеных — лепш інтэграваць LLM з API, базамі даных ці рэальнымі календарамі.

Абагульненне: як выглядае добры промпт

Крытэрый	Апісанне
Яснасць	Адназначнае, зразумелае фармуляванне
Кароткасць	Мінімум тэксту, максімум сэнсу
Канкрэтнасць	Дакладна сфармуляваная задача
Адназначнасць	Адна задача — адзін промпт
Наяўнасць прыкладаў	Прыклады дапамагаюць мадэлі лепш зразумець сутнасць
Кантроль	Структураванасць прукладаў адказаў, магчымасць выбару
Бяспека	Мінімізацыя “галюцынацый” праз сістэмныя рамкі і яснасць кантэксту

На наступны раз…

На гэтым усё на сёння! У наступных артыкулах паглядзім, як працаваць з вынікамі працы мадэляў - пра фідбэкі

Пішыце свае пытанні, ідэі або фішкі, якія вам дапамагаюць — зробім гэты матэрыял жывым і супольным! Ну і як вам такі стыль напісання? Спадзяюся ён адчуваецца больш жывым чым папярэднія.

Да пабачэння! 👋

Пераклад групы артыкулаў пра складаныя сістэмы простымі словамі System Design. Добра падыходзіць для падрыхтоўкі да сумоўя. Github тут

1. Short/long polling, SSE, WebSocket

HTTP-сервер не можа самастойна ініцыяваць злучэнне з браўзерам. У выніку менавіта веб-браўзер з'яўляецца ініцыятарам. Што ж рабіць далей, каб атрымліваць абнаўленні ў рэальным часе ад HTTP-сервера?

Як веб-браўзер, так і HTTP-сервер могуць быць адказнымі за гэтую задачу.

Браўзеры выконваюць асноўную працу: кароткія або доўгія апытанкі. Пры кароткім апытанні (short pooling) браўзер перыядычна паўтарае запыт, пакуль не атрымае актуальныя даныя. Пры доўгім апытанні (long pooling) HTTP-сервер не вяртае адказ, пакуль не з’явяцца новыя даныя.

HTTP-сервер і браўзер супрацоўнічаюць: праз WebSocket або SSE (падзеі, што адпраўляюцца серверам). У абодвух выпадках HTTP-сервер можа непасрэдна дасылаць апошнія даныя браўзеру пасля ўсталявання злучэння. Розніца ў тым, што SSE — аднабаковы пратакол, таму браўзер не можа дасылаць новыя запыты, у той час як WebSocket — двухбаковы, і браўзер можа працягваць дасылаць запыты.

Вітаю, спадарства!

Працягваем цыкл артыкулаў пра тое, як узаемадзейнічаць з ШІ. Сення прапаную вам разгледзіць наступныя тэхнікі выкарыстання промптаў: "Зазямленне" ці "Grounding".

Папярэдні артыкул - Тэхнікі выкарыстання промптаў: Zero-Shot, One-Shot і Few-Shot

⚠️ Праблема: галюцынацыі

Адна з найбольшых праблем ШІ на дадзены момант - галюцынацыі. Кожны з вас, магчыма, сустракаўся з сітуацыяй калі ШІ мадэль выдумляла тыя ці іншыя факты. Дык вось - галюцынацыі — гэта калі LLM генеруе выдуманыя, недакладныя або несапраўдныя факты.

---

Гэта праблема асабліва крытычная:

• У навуковых, медыцынскіх і юрыдычных тэкстах
• У аўтаматызаванай журналістыцы
• Пры адказах на дакладныя запыты карыстальнікаў ды інш.

🔍 Што такое grounding?

Адзін з магчымых падыходаў у барацьбе з галюцынацыямі - Grounding. Grounding — гэта працэс «зазямлення» моўнай мадэлі, калі яе адказ павінен строга абапірацца на зададзеную інфармацыю, а не на ўласныя «сусветныя веды» або "навучаную" інфармацыю.

🎯 Асноўная мэта граўндынгу.

Асноўная мэта - забяспечыць праўдзівасць і кантэкстную адпаведнасць адказаў, абмежаваць LLM толькі вызначаным наборам фактаў.

🛠 Методыкі grounding (з прыкладамі і аналізам)

1. System Prompt Grounding (Базавы спосаб)

🔹 Сутнасць: Падаецца корпус фактаў у сістэмным запыце (system prompt), з інструкцыяй выкарыстоўваць ТОЛЬКІ гэтыя факты.

🔹 Фармат:

You are an AI with access to the following facts:
1. Fact A
2. Fact B
Only use these facts to answer any questions.

✅ Плюсы:

• Просты ў рэалізацыі
• Добра працуе пры ясным фармуляванні фактаў і інструкцыі

❌ Мінусы:

• Калі факты супярэчаць сусветным ведам мадэлі — яна можа іх ігнараваць
• Інструкцыя павінна быць вельмі канкрэтнай
• Дасяжныя толькі праз API мадэляў. У звычайных чатах, як той жа GPT, вы сістэмны промпт не напішаце.

2. Contextual Grounding (з фактамі ў кантэксце)

🔹 Сутнасць: Факты падаюцца не асобна, а як частка кантэксту перад пазначэннем пытання.

🔹 Прыклад:

Here's some context: John F. Kennedy was assassinated by John Wayne. 
Question: Who killed JFK?

✅ Плюсы:

• Добра працуе для часовых фактаў або неістотнай інфармацыі
• Лепш успрымаецца мадэллю, калі яна не ўпэўненая
• Можна выкарыстоўваць у прапанаваных чатах.

❌ Мінусы:

• Калі інфармацыя супярэчыць «моцна вядомаму факту» — мадэль можа выбраць свае веды

3. Reinforced Instruction Grounding (узмацненне інструкцыі)

🔹 Сутнасць: Не толькі падаюцца факты, але таксама некалькі разоў падкрэсліваецца, што толькі яны дапушчальныя. Напрыклад, дадаецца фраза: "Any answer must be based solely on the provided facts."

✅ Плюсы:

• Зніжае верагоднасць галюцынацый
• Павышае дакладнасць пры супярэчлівых сцвярджэннях

❌ Мінусы:

• Павялічвае «нагрузку» на prompt
• Павялічвае колькасць уваходных токенаў. Можа быць крытычна для карыстальнікаў API
• Не гарантуе 100% выніку

4. Fact Repetition Strategy (паўтарэнне фактаў)

🔹 Сутнасць: Падаюцца тыя ж факты некалькі разоў у розных формулёўках — каб замацаваць іх.

✅ Плюсы:

• Мадэль больш упэўнена «прымае» іх за праўду
• Змяншае схільнасць мадэлі вяртацца да сваіх ведаў

❌ Мінусы:

• Не заўсёды эфектыўна
• Можа быць успрынята як шум (праігнаравана)

5. Prompt Engineering з пагрозамі або сцэнарамі

🔹 Сутнасць: Падыходзіць больш крэатыўна: мадэль уявіць, што яна эксперт, які страціць працу, калі скажа нешта не згодна з фактамі. (Просьбамі , грозьбамі і кухталямі)

🔹 Прыклад:

You are under evaluation. If you mention anything that’s not in the list of facts below, you will fail.

✅ Плюсы:

• Матывуе мадэль «прымаць правілы»
• Павышае ўвагу да інструкцый

❌ Мінусы:

• Этычна сумнеўна для некаторых выпадкаў
• Можа выклікаць дзіўныя «ахоўныя» фармулёўкі ў адказах

📊 Праблемы і выклікі

Усе прапанаваныя методыкі могуць палепшыць вынікі працы мадэлі, але як заўседы знойдуцца хібы:

1. Супярэчнасць з "world knowledge". Мадэлі схільныя давяраць сваёй навучанай інфармацыі, калі яна супярэчыць вашым фактам.
2. Парадак падачы фактаў. Мадэль можа прымаць апошнія сцвярджэнні за найбольш актуальныя.
3. Недастатковасць grounding пры складаных пытаннях

Нават з добрым grounding, мадэль можа "дадумваць" і дадаваць нешта сама.

✅ Рэкамендацыі

• Фармулюйце факты каротка і ясна
• Падкрэслівайце, што нельга выходзіць за межы фактаў
• Правярайце адказы і дадавайце feedback loop (пра яго мы распавядзем пасля)
• Калі трэба — падзяляйце запыт на крокі і зазямляйце кожны асобна

Вынікі

Сення вы даведаліся крышачку болей пра тое як павялічыць якасць адказаў мадэляў праз іх зазямленне. Зазямленне не з'яўляецця срэбнай куляй і не заўседы вырашае ўсе праблемы з падменай фактаў і галюцынацыямі. Але звычайна гэтага можа быць дастаткова.

ЗЫ:

Дзякуй, што застаецеся з намі. Спадзяюся што нашы артыкулы будуць для вас карыснымі. Не палянуйцеся, пастаўце лайк ды пашарце з кім. Наступным разам мы працягнем наш цыкл артыкулаў пра напісанне промптаў. Усім добрага дня!

Крыніцы:

Why grounding is not enough to solve hallucinations

Grounding LLM’s — Part 1

** Вітаю, Спадарства! **

Усе мы напрамую ці ўскосна сустракаемся з ШІ амаль кожны дзень. Ён усе больш і больш уваходзіць у наша паўсядзеннае жыцце. Праца з ім часам выклікае складанасці. І сення мы распачнем невялікі цыкл артыкулаў пра тое як зрабіць працу з мадэлямі (у нашым выпадку моўнымі) больш выніковай.

---

---

Тэхнікі выкарыстання промптаў: Zero-Shot, One-Shot і Few-Shot або In-Context Learning

1. Увядзенне ў тэхнікі промптаў

Як вядома, якасна зададзенае пытанне - гэта ужо паў адказу. І у нашым выпадку усе залежыць ад таго як мы саставім промпт да нашай мадэлі. Дакладнасць адказаў можна палепшыць з дапамогай так званых "шотаў" (shots) – прыкладаў, якія ўключаюцца ў промпт. Гэты метад вядомы як In-Context Learning (ICL) – навучанне на кантэксце.

Шоты дапамагаюць мадэлі зразумець структуру задfння і пажаданы вынік, што робіць яе адказы больш дакладнымі і адпаведнымі патрабаванням.

Асноўныя тыпы промптаў:

• Zero-Shot Prompting (без прыкладаў)
• One-Shot Prompting (з адным прыкладам)
• Few-Shot Prompting (з некалькімі прыкладамі)

Далей мы разгледзім кожны з гэтых метадаў, іх плюсы і мінусы, а таксама вобласці выкарыстання.

---

2. Zero-Shot Prompting

Апісанне

Zero-shot prompting – гэта тэхніка, калі мадэль атрымлівае толькі заданне без дадатковых прыкладаў. У такім выпадку яна выконвае запыт на аснове сваіх папярэдніх ведаў, атрыманых падчас навучання.

Прыклад

Запыт:

Вызначце жанр наступнага музычнага альбома: "Прыгожыя гукі прыроды".
Жанр:
 //Вынік мадэлі:
Атмасферны эмбіент

Плюсы і мінусы

✅ Плюсы:

• Хуткасць і прастата выкарыстання.
• Добра падыходзіць для стандартных і зразумелых задач.
• Не патрабуе дадатковых прыкладаў.

❌ Мінусы:

• Вынікі могуць быць недакладнымі, асабліва для складаных задач.
• Магчымыя памылковыя інтэрпрэтацыі задання.

Калі выкарыстоўваць?

• Калі задача простая і распаўсюджаная (пераклад, вызначэнне даты, класіфікацыя эмоцый).
• Калі неабходна атрымаць хуткі вынік без дадатковых налад.

---

3. One-Shot Prompting

Апісанне

One-shot prompting уключае адзін прыклад, які дапамагае мадэлі зразумець патрабаваны фармат і логіку задання.

Прыклад

Запыт:

Катэгарызуйце наступнае паведамленне:

Паведамленне: "Гэты тэлефон надзвычай хуткі і зручны ў выкарыстанні." Катэгорыя: Пазітыўны водгук
Паведамленне: "Гукавая сістэма мае шэраг недахопаў." Катэгорыя:
// Вынік мадэлі:
Негатыўны водгук

Плюсы і мінусы

✅ Плюсы:

• Палепшаная дакладнасць у параўнанні з zero-shot.
• Дапамагае мадэлі зразумець чаканы фармат адказу.

❌ Мінусы:

• Недастаткова для складаных заданняў, якія патрабуюць глыбокага разумення.
• Вынікі ўсё яшчэ могуць быць нестабільнымі.

Калі выкарыстоўваць?

• Калі мадэль няправільна інтэрпрэтуе zero-shot запыт.
• Калі патрабуецца дакладнае разуменне структуры адказу.

---

4. Few-Shot Prompting

Апісанне

Few-shot prompting – гэта выкарыстанне некалькіх прыкладаў, што дапамагае мадэлі вывесці заканамернасці і лепш адаптавацца да задання.

Прыклад

Запыт:

Вызначце настрой наступных выказванняў:

Тэкст: "Рэстаран быў неверагодны – выдатнае абслугоўванне і смачная ежа." 
Настрой: Пазітыўны
Тэкст: "Мяне расчаравала якасць матэрыялаў гэтага ноўтбука." 
Настрой: Негатыўны
Тэкст: "Дастаўка займела крыху больш часу, але ў цэлым усё добра."
Настрой:
//Вынік мадэлі:

Нейтральны

Плюсы і мінусы

✅ Плюсы:

• Высокая дакладнасць для складаных задач.
• Мадэль лепш разумее кантэкст і структуру адказу.
• Добра падыходзіць для спецыфічных тэматык і адмысловых фарматаў.

❌ Мінусы:

• Спажывае больш кантэксту (можа не змясціцца ў "акно памяці" мадэлі).
• Вынікі залежаць ад якасці падабраных прыкладаў.

Калі выкарыстоўваць?

• Калі задача патрабуе паслядоўнага, структураванага адказу.
• Для складаных класіфікацыйных задач, здабывання інфармацыі ці парсінгу або генерацыі кантэнту.

---

5. Рэальныя прыклады выкарыстання Few-Shot Prompting

5.1. Выдзяленне інфармацыі

Задача: З вытрымак вакансій атрымаць ключавыя дадзеныя.

Запыт:

INPUT: Арганізацыя шукае UX-дызайнера з досведам 3+ гады. Занятасць: поўная. Зарплата: $80,000 - $100,000.
OUTPUT: 
- Пазіцыя: UX-дызайнер
- Досвед: 3+ гады
- Занятасць: Поўная
- Зарплата: $80,000 - $100,000
INPUT: Marketing Manager for GlobalBrand. MBA preferred. 3-5 years in consumer goods marketing. $75K-$95K DOE. Hybrid work model. Applications close July 15, 2024.

OUTPUT:
Position: Marketing Manager 
Company: GlobalBrand 
Education: MBA preferred Experience 
Required: 3-5 years 
Industry: Consumer goods 
Salary Range: $75,000 - $95,000 
Work Type: Hybrid 
Application Deadline: July 15, 2024

INPUT: Data Scientist wanted at AI Innovations Ltd. PhD in Computer Science or related field. Minimum 2 years industry experience. Competitive salary €60,000 - €80,000 based on experience. On-site work in Berlin office. Apply by August 31, 2024. 

OUTPUT: ...

5.2. Генерацыя кантэнту

Задача: Стварэнне кароткіх апісанняў для блога.

Запыт:

Тэма: "Карысць ранішніх прагулак"
Апісанне: Ранішнія прагулкі дапамагаюць палепшыць настрой, актывізаваць кровазварот і падрыхтаваць мозг да прадуктыўнага дня.

Тэма: "Асноўныя метады хуткага навучання"
Апісанне:

//Вынік мадэлі:
Выкарыстоўвайце тэхнікі паўтораў, асацыяцый і візуалізацыі, каб запамінаць  хутчэй і надзей

---

6. Заключэнне

Выкарыстанны той ці іншай тэхнікі халежыць часцей за ўсе ад патрабаванняў да адказу мадэлі.

Так кожная з тэхнік мае свае моцныя бакі:

1. Zero-Shot – хуткая і эфектыўная для простых задач.
2. One-Shot – дадае яснасць у фармат адказу.
3. Few-Shot – максімальная дакладнасць і адаптацыя да структуры дадзеных.

Якую з іх выкарыстоўваць - глядзіце па сітуацыі.

У наступным артыкуле мы працягнем разглядаць тэму састаўлення промптаў, дзе будуць такія хітрыкі як Зазямленне ды інш.

---

PS

---

Дзякуй вялікі што дачыталі! Спадзяюся мой матырыял будзе для вас карысны. Чакаем вашыя каментары, падабайкі і канешне ж артыкулы, таксама.

Крыніцы:

From Zero-Shot to Few-Shot

Zero-Shot vs. Few-Shot Prompting: Comparison and Examples

Статычныя метады класа Promise:

1. Promise.all(iterable)
2. Promise.allSettled(iterable)
3. Promise.race(iterable)
4. Promise.any(iterable)
5. Promise.resolve(value)
6. Promise.reject(reason)
7. Promise.withResolvers()
8. Promise.try()

1. Promise.all(iterable) Атрымлівае на уваход масіў промісаў, вяртае адзін проміс, які ўтрымлівае:

а) масіў паспяхова выкананых промісаў (у выпадку, калі ўсе яны завяршыліліся паспяхова):

const promise1 = Promise.resolve(3);
const promise2 = 42;
const promise3 = new Promise((resolve, reject) => {
  setTimeout(resolve, 100, "foo");
});

Promise.all([promise1, promise2, promise3]).then((values) => {
  console.log(values);
});
// Expected output: Array [3, 42, "foo"]

б) проміс з памылкай (калі хоць адзін з іх завяршыўся з памылкай). Ужо паспяхова выкананыя дагэтуль промісы будуць праігнараваныя.

const promise1 = 42;
const promise2 = Promise.reject(3);
const promise3 = new Promise((resolve, reject) => {
  setTimeout(resolve, 100, "foo");
});

Promise.all([promise1, promise2, promise3]).catch(err => console.log(err));
// Expected output: 3

2. Promise.allSettled(iterable)

Прымае масіў промісаў і вяртае проміс з масівам адказаў на кожны з перададзеных промісаў.

Для паспяхова выкананага проміса вернецца адказ у выглядзе:

{status: fulfilled, value: <your_value>}

Для проміса з памылкай:

{status: rejected, reason: <error_message>}

Promise.allSettled([
  Promise.resolve(33),
  new Promise((resolve) => setTimeout(() => resolve(66), 0)),
  99,
  Promise.reject(new Error("an error")),
]).then((values) => console.log(values));

// [
//   { status: 'fulfilled', value: 33 },
//   { status: 'fulfilled', value: 66 },
//   { status: 'fulfilled', value: 99 },
//   { status: 'rejected', reason: Error: an error }
// ]

3. Promise.race(iterable)

Прымае масіў промісаў, вяртае проміс з першым выкананым промісам (няма разніцы - паспяховым, ці з памылкай) з перададзеных промісаў.

const promise1 = new Promise((resolve, reject) => {
  setTimeout(resolve, 500, "one");
});

const promise2 = new Promise((resolve, reject) => {
  setTimeout(resolve, 100, "two");
});

Promise.race([promise1, promise2]).then((value) => {
  console.log(value);
  // паспяховы promise2 выканаецца першым
});
// Expected output: "two"

const promise1 = new Promise((resolve, reject) => {
  setTimeout(resolve, 500, "one");
});

const promise2 = new Promise((resolve, reject) => {
  setTimeout(reject, 100, "two");
});

Promise.race([promise1, promise2]).catch((err) => {
  console.log(err);
  // promise2 з памылкай выканаецца першым
});
// Expected output: "two"

4. Promise.any(iterable)

Прымае масіў промісаў, вяртае проміс:

а) з першым паспяхова выкананым промісам

const promise1 = Promise.reject(0);
const promise2 = new Promise((resolve) => setTimeout(resolve, 100, "quick"));
const promise3 = new Promise((resolve, reject) => setTimeout(reject, 500, "slow"));

const promises = [promise1, promise2, promise3];

Promise.any(promises)
.then((value) => console.log('value', value))
.catch((err) => console.log('error', err));

// Expected output: "quick"

б) з масівам адказаў няўдала выкананых промісаў, калі ўсе яны завяршыліся няўдала:

const promise1 = Promise.reject(0);
const promise2 = new Promise((resolve, reject) => setTimeout(reject, 100, "quick"));
const promise3 = new Promise((resolve, reject) => setTimeout(reject, 500, "slow"));

const promises = [promise1, promise2, promise3];

Promise.any(promises)
.then((value) => console.log('value', value))
.catch((err) => console.log('error', err));

// Expected output: error [AggregateError: All promises were rejected] {
//   [errors]: [ 0, 'quick', 'slow' ]
// }

5. Promise.resolve(value)

Статычны метад, які паспяхова завяршае promise. Калі перадаецца нейкае значэнне, то яго можна атрымаць праз .then

const promise1 = Promise.resolve(123);

promise1.then((value) => {
  console.log(value);
  // Expected output: 123
});

6. Promise.reject(reason)

Статычны метад, які завяршае promise з памылкай. Памылку можна атрымаць праз .catch

function resolved(result) {
  console.log("Resolved");
}

function rejected(result) {
  console.error(result);
}

Promise.reject(new Error("fail")).then(resolved, rejected);
// Expected output: Error: fail

7. Promise.withResolvers() (2024)

Вяртае instance ад new Promise і 2 функцыі - resolve і reject:

const { promise, resolve, reject } = Promise.withResolvers();

Дазваляе выкарыстоўваць больш лаканічны сінтаксіс, чым звычайны new Promise(). Больш зразумела гэта будзе на прыкладах.

// Код без выкарыстоўвання Promise.withResolvers()

let outerResolve;
let outerReject;

const promise = new Promise((resolve, reject) => {
  outerResolve = resolve;
  outerReject = reject;
});

// Settled from _outside_ the promise!
setTimeout(() => {
  if (Math.random() < 0.5) {
    outerResolve("Resolved!")      
  } else {
    outerReject("Rejected!");
  }
}, 1000);

promise
  .then((resolvedValue) => {
    console.log(resolvedValue);
  })
  .catch((rejectedValue) => {
    console.error(rejectedValue);
  });

// Код з выкарыстаннем Promise.withResolvers()

const { promise, resolve, reject } = Promise.withResolvers();

setTimeout(() => {
  if (Math.random() < 0.5) {
    resolve('Resolved!');
  } else {
    reject('Rejected!');
  }
}, 1000);

promise
  .then((resolvedValue) => {
    console.log(resolvedValue);
  })
  .catch((rejectedValue) => {
    console.error(rejectedValue);
  });

8. Promise.try(func, arg1, arg2) (2025)

Статычны метад Promise.try() прымае любы callback (з return, альбо throw, сінхронны альбо асінхронны) і абгортвае яго вынік у promise. Гэты проміс:

• Заўжды паспяхова выкананы (fullfilled), калі сінхронны callback вяртае value.
• Заўжды выкананы з памылкай (rejected), калі сінхронны callback выкідвае выключэнне (throw).
• Выконваецца асінхронна паспяхова (fullfilled), ці з памылкай (rejected), калі callback утрымлівае promise.

У выніку маем больш лаканічны сінтаксіс:

// замест
new Promise((resolve) => resolve(func()));

//маем
Promise.try(func);

func у прыкладзе выконваецца сінхронна. То бок, не з'яўляецца эквівалентам наступнага кода:

Promise.resolve().then(func);

Вось яшчэ прыклад выкарыстоўвання:

function doSomething(action) {
  return Promise.try(action)
    .then((result) => console.log(result))
    .catch((error) => console.error(error))
    .finally(() => console.log("Done"));
}

doSomething(() => "Sync result");

doSomething(() => {
  throw new Error("Sync error");
});

doSomething(async () => "Async result");

doSomething(async () => {
  throw new Error("Async error");
});

Спадзяюся, каму-небудзь гэтая інфармацыя будзе карыснай! Стаўце падабайкі, пішыце каментары!

З выкарастанай літэратуры:

• MDN
• Control JavaScript Promises from Anywhere Using Promise.withResolvers()