Основи на LLM API: Барање, одговор и улоги на пораки

Добивки:

• Може да ја опише основната структура на барањето LLM API (крајна точка, модел, пораки, max_tokens)
• Ја разбира разликата помеѓу улогите на системот, корисникот и помошникот и историјата на разговори без државјанство
• Може да чита и интерпретира полиња (блокови со содржина, stop_reason, употреба) на вратениот одговор

Во претходните модули користевме вештачка интелигенција од прозорец за разговор. Но, ако сакате да ја вградите вештачката интелигенција во вашиот сопствен производ, автоматизација или работен тек, интерфејсот за разговор нема да го намали; Треба да се поврзете со моделот програмски, односно со код или алатка за автоматизација. Името на овој мост е API (Application Programming Interface, договор кој дозволува два софтвери да разговараат со одредени правила). Кога ќе ја завршите оваа единица, ќе знаете што претставува барање за LLM (Large Language Model) API, што прават улогите на пораките и како да го прочитате одговорот. Ова е основата на која ќе се гради остатокот од модулот.

Како работи API-то?

Основниот тек во API е ова: испраќате барање во одреден формат; Серверот враќа одговор во одреден формат. Во LLM, ова е обично повик HTTP (HTTP: стандарден протокол за пренесување на барање-одговор на веб) до една адреса (крајна точка, фиксната адреса на серверот што се справува со вашето барање). На пример, во API за пораки, сите барања одат на една адреса и се носат во телото како JSON (JavaScript Object Notation — формат на текст кој се состои од парови клучеви/вредности кои можат да се читаат и од луѓето и од машините).

Во барањето, ги наведувате барем овие три работи:

• Модел: кој модел ќе го користите (на пр. брз и евтин модел или моќен модел).
• max_tokens: Максималниот број на токени (најмалата единица во која се обработува текстот, која детално ќе биде обработена во следната единица) што моделот може да ги произведе; односно излезна граница.
• пораки: Список на пораки што го сочинуваат разговорот.

Чекор по чекор: Како да поставите барање

1. Подгответе ја крајната точка и ингеренциите. Го додавате вашиот API клуч (тајната низа што го докажува вашиот идентитет) на барањето во заглавие. Никогаш не го вметнувате клучот во кодот; Ќе покриеме безбедно складирање во единицата 9.
2. Изберете го моделот и излезната граница. Лесен модел + мали max_tokens за едноставна задача; Моќен модел + поголема граница за сложена задача.
3. Поставете го списокот со пораки. List the system instruction, user message, and past rounds (if any).
4. Испратете го барањето и анализирајте го одговорот. Прочитајте ја содржината на текстот, прекинете ја причината и употребата на токени од вратениот JSON.

Улоги на пораки: систем, корисник, асистент

Разговорот се состои од пораки распоредени во низа и секоја порака има своја улога. Улогата одредува како моделот го третира тој текст.

Улога

Кој пишува

Цел

систем

Програмер/оператор

Постојани упатства, личност и правила кои важат во текот на целиот разговор

корисник

краен корисник

Тековно прашање или влез на корисникот

асистент

модел

Одговор произведен од моделот (и претходни одговори)

Системската улога е достапна како посебно системско поле во телото на барањето кај повеќето провајдери; корисникот и асистентот се наведени последователно во списокот со пораки. Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.

{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "Вие сте корпоративен асистент за поддршка. Дајте краток, формален и потврден одговор. Не измислувајте информации за кои не сте сигурни.", "messages": [ { "role": "user", "ow return my process": } ]}

Говорот е без државјанство

Еве ја најчестата заблуда: LLM API повиците се без државјанство - серверот не задржува меморија помеѓу две барања. Моделот не се сеќава на вашето претходно барање. Ако поставувате разговор со повеќе кругови, ќе треба повторно да ги испраќате минатите кругови со секое ново барање. „Меморијата“ на моделот се состои од листа на пораки што сте ги испратиле.

{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "Здраво, јас се викам Дениз." }, { "role": "assistant", "content": "Здраво Дениз, како можам да ти помогнам?" }, { "role": "user", "content": "Само што го кажав моето име, се сеќаваш ли?" } ]}

Точното одговарање на третата порака зависи од тоа дали ќе ги испратите двете претходни пораки. Ако не го испратите, моделот нема да знае „Море“ и ќе одговори погрешно. Ова, исто така, директно влијае на цената: колку е подолг разговорот, толку е поголема листата, секое барање троши повеќе токени.

Совет: во долгите разговори, сумирањето и преместувањето на старите кругови (резиме + последните неколку круга) наместо да се испрати целата историја, ги намалува трошоците и го зачувува контекстниот прозорец. Ова ќе го продлабочиме во целините 6 и 11.

Прочитајте го Одговорот

Кога моделот враќа одговор, добивате структуриран објект, а не обичен текст. Типични области:

„ "input_tokens": 47, "output_tokens": 88 }}

• содржина: Самиот одговор; Тоа е листа на блокови со содржина. Текстуалното поле на текстуалниот блок е вистинскиот одговор.
• stop_reason: Зошто моделот застана. крај_сврт = природен крај; max_tokens = заглавени на излезната граница (одговорот може да биде нецелосен); одбивање = одбиено од безбедносни причини. Вашиот код секогаш прво треба да го гледа stop_reason.
• употреба: Внеси и излезни токени броеви. Тоа е основа за следење на трошоците и ограничувањата.

Внимание: ако stop_reason е max_tokens, одговорот не е завршен. Да се ​​третира ова како „успешен одговор“ и да се покаже половина текст на корисникот е една од најчестите грешки во производството. Или зголемете ги max_tokens или користете стриминг.

Слаб промпт / Силен промпт

Истата задача со две различни системски сигнали:

# СЛАБ Вие сте асистент. Одговорете на прашањата.

# STRONG Вие сте корпоративен асистент за поддршка. Правила: - Потпрете се само на информациите во дадениот документ за политиката; Ако го нема во документот, кажете „Јас ги немам овие информации, ги упатувам до соодветната единица“. - Одговорите не треба да надминуваат 3 реченици, да бидат формални и јасни. - Не барајте лични податоци (ТЦ матичен број, број на картичка) и не повторувајте. - Не погодувајте кога не сте сигурни.

Моќна верзија; Тој го дефинира опсегот, формата, безбедносната маргина и однесувањето во несигурност. Конзистентноста на излезот на моделот доаѓа директно од оваа јасност.

Три мини футроли

Случај 1 - бот за поддршка (стапица за бездржавјанство). Тим за е-трговија го зеде ботот во живо; Кога корисникот рече „откажи ја претходната нарачка“, ботот го „заборави“ бројот на нарачката. Причина: секое барање го испраќаа само со последната порака. Решение: ги додадоа последните 6 круга на списокот со пораки. Резултат: контекстот е зачуван, но внесувањето по барање се зголеми од 40 токени на ~ 600 токени - ќе ја покриеме лекцијата за трошоци во единица 2.

Случај 2 - Нецелосно резиме на договорот. Адвокатскиот тим имаше наведени договори на 10 страници; max_tokens: 300 останаа ниски, резимеата ја отсекуваа средината на реченицата. stop_reason беше max_tokens секој пат, но никој не гледаше. ги зголеми max_tokens на 1500 и додаде проверка на stop_reason; Скратената сума стапка се намали од 18% на 0%.

Случај 3 - Мешање улоги. Маркетинг тим ги пишуваше сите инструкции во корисничката порака, оставајќи го системот празен. Кога внесувањето на корисникот се меша со инструкциите, моделот понекогаш ќе се усогласи со командата на корисникот да ги „заборави претходните правила“. Тие преместија постојани правила во системот; Со одвојување на корисничкиот влез од инструкцијата, прекршувањата на правилата значително се намалија.

Вообичаени грешки

• Заборавајќи да го испратите минатото: се смета дека моделот „не се сеќава“; при што е без државјанство. Вие го носите контекстот.
• Не гледајќи во `stop_reason`: Одговорот запрен со max_tokens се смета за завршен.
• Вградување на инструкцијата во `user`: Постојани правила во системот; инстант внесување оди кај корисникот. Мешањето создава безбедносни пропусти.
• Погрешна „содржина“ за обична низа: Одговорот е листа на блокови; прочитајте го полето за текст на првиот текстуален блок, потврдете го неговиот тип пред да добиете содржина[0] со слеп индекс.
• Вградување на клучот во кодот: Користете променлива на околината (единица 9).

Подлабоко: блокови на содржина и одговори од повеќе делови

Разбирањето зошто полето за содржина во одговорот е список е од фундаментално значење за напредните функции со кои ќе се сретнете подоцна. Понекогаш моделот враќа не еден блок текст, туку неколку блокови: блок на размислување, проследен со блок текст; или блок текст проследен со блок за употреба на алатка. Затоа слепо броењето на содржината[0] како „одговор“ е кревко. Правилниот пристап е да се помине низ списокот и да се подреди по тип: ја собирате текстуалната содржина на блоковите чие поле за тип е текст и ги третирате другите типови (размислување, алатка) одделно.

Она што го прави оваа разлика во пракса е тоа што можете да го евидентирате расудувањето на моделот (доколку го има) без да му го откриете на корисникот, да ги пренасочувате повиците на алатките кон одделна логика и само да го испечатите вистинскиот одговор на екранот. Како што напредува модулот (особено во единиците 4 и 11) ќе видите колку е корисна оваа блок структура за потврдување и насочување на излезот.

Друга практична точка: можете да пристапите до истиот модел од различни платформи на даватели (директен API, преку провајдер на облак). Иако адресата на крајната точка и форматот за автентикација може да се променат, основните концепти како што се улогите на пораките, бездржавјанството и структурата на одговор остануваат исти. Значи, основите во оваа единица се применуваат без разлика која платформа ја користите.

Сумирано

Барањето LLM API се состои од модел, излезна граница и листа на пораки; улогите (систем, корисник, асистент) го одредуваат однесувањето на моделот. Повиците се без државјанство: вие го носите контекстот со секое барање. Одговорот е структуриран објект; Читањето и толкувањето на содржината, стоп_причината и полињата за употреба е основата на издржливоста во производството.

Задача за апликација

Изберете задача од вашата професија (на пр. сортирање на дојдовната е-пошта, креирање кратки резимеа). На парче хартија: (1) напишете го системското известување со 4-5 правила, (2) поставете примерок од корисничка порака и историја од 2 круга доколку ги има, (3) определете разумна вредност за max_tokens и напишете го оправдувањето, (4) наведете кои вредности за stop_reason ќе ги ракувате во вратениот одговор и како.

листа за проверка

• [ ] Можам да ги бројам трите задолжителни делови на барањето (модел, max_tokens, пораки).
• [ ] Можам да ја објаснам разликата помеѓу улогите на системот, корисникот и помошникот.
• [ ] Знам дека повиците се без државјанство и дека треба да го носам минатото.
• Можам да читам и коментирам на [ ] содржина, стоп_причина и полиња за користење.
• [ ] Со max_tokens можам да забележам и да се справам со скратениот одговор.