Урт агентын эргэлтийг context window-д багтаах нь

Загвар нэг удаа зөвхөн тодорхой хэмжээний текст унших боломжтой — түүний context window. Mythex-ийн агент урт ажил хийдэг: олон файл уншиж, команд ажиллуулж, хязгаарлагдмал ажлуудыг дэд агентуудад өгдөг. Урт ажил эвдэрдэг гурван арга олсон: дэд агентууд загвар бүх хүсэлтийг татгалзах хүртэл ургадаг, нэг дэд агент өрөө дууссан гэж бодоод эрт зогсдог, мөн Орос, Хятад, Япон текстийн токен тоолол маш буруу байсан. Энд бидний өөрчилсөн зүйлс байна.

Эхлээд зарим нэр томъёо

• Токен нь загварын уншдаг хэсгүүд. Хязгаар, зардлыг тэдгээрээр тоолдог, тэмдэгт эсвэл үгээр биш.
• Context window нь загвар нэг хүсэлтэд хамгийн ихээр унших боломжтой хэмжээ. Бид мөн хүсэлт бүрт зориулсан өөрийн доод төсвийг тогтоодог, ингэснээр зардал, хурд ухаалаг хэвээр байна.
• Хэрэгслийн үр дүн нь агент хэрэгслүүдээсээ авдаг зүйл: уншсан файлын агуулга, ажиллуулсан командын гаралт. Урт ажилд тэдгээр нь илгээгдэж буй зүйлийн ихэнх.
• Дэд агент нь агентийн эхлүүлдэг туслах, тусдаа өөртөө хамаарах ажилд зориулсан, жишээ нь «эдгээр бүлгүүдийг тэмдэглэлтэй нь шалга». Тэр нэг заавар авч, дараа нь олон хэрэгслийн дуудлагаар өөрөө ажилладаг.

Асуудал 1: дэд агентууд загвар татгалзах хүртэл ургасан

Алхам бүрт агент загварт одоогийн яриаг илгээдэг. Хэт том болоход манай код үүнийг тайрдаг байсан — гэхдээ зөвхөн хэрэглэгчийн мессежийн эхэнд, ингэснээр хэрэгслийн дуудлага болон түүний үр дүн хэзээ ч хуваагдахгүй. Эхний мессежийг үлдээж, өмнөх яриа тайрагдсан гэсэн тэмдэглэл нэмж, хамгийн шинэ бүтэн эргэлтүүдийг багтах хэмжээгээр үлдээдэг байсан.

Дэд агент яг нэг хэрэглэгчийн мессежтэй: түүний заавар. Тайрах газар байгаагүй. Тиймээс түүний бүтэн түүхийг алхам бүрт илгээж, ургаж, загварын хүлээн авдаг хэмжээнээс — ойролцоогоор нэг сая токенээс — хүсэлт илүү том болтол. Туршилтад ийм 8 дэд агентаас 8 нь бүгд татгалзсан.

Засвар: эхлээд хуучин хэрэгслийн үр дүнг цэвэрлэ

Одоо хүсэлтүүд гурван алхамаар төсөвт багтдаг бөгөөд нэг нь өмнөхөөсөө хангалтгүй байсан тохиолдолд л дараагийнх нь туршина:

1. Хамгийн хуучин хэрэгслийн үр дүнг цэвэрлэ. Тэдгээрийн агуулгыг товч тэмдэглэлээр солино: үр дүнг загварын context-д багтаах зорилгоор цэвэрлэсэн, агент хэрэгтэй бол дахин ажиллуулж болно. Нэг цагийн өмнө уншсан файл ихэвчлэн хүсэлт дэх хамгийн том, хамгийн бага ашигтай зүйл, мөн тэр файл дахин уншиж болох хэвээр. Шинэ үр дүн бүтэн үлдэнэ.
2. Бүтэн хэрэглэгчийн эргэлтүүдийг хадгал. Өмнөх шигээ: эхний мессеж, тэмдэглэл, багтах шинэ бүтэн эргэлтүүд.
3. Бүтэн хэрэгслийн дуудлагуудыг хадгал. Нэг урт эргэлтийн дотор — дэд агентад байдаг цорын ганц төрөл — эхний мессеж, тэмдэглэл, багтах шинэ бүтэн "хэрэгсэл дуудах, үр дүн авах" мөчлөгүүдийг хадгал.

Энэ нь зөвхөн илгээгдэх зүйлийг бүрдүүлдэг. Агентын хадгалсан түүх бүгдийг хадгална. Ижил туршилтад 8-аас 0 нь татгалзаж, бүгд дуусав.

Багцаар цэвэрлэх, ингэснээр кэш ажилладаг хэвээр

Загварын үйлчилгээ үүнтэй адилхан хүсэлтийн эхлэлийг дахин ашиглаж болно — prefix cache. Хэрэв бид дуудлага бүрт нэг үр дүнг нэмж цэвэрлэвэл хүсэлтийн эхлэл дуудлага бүр өөрчлөгдөж, кэш хэзээ ч тусалдаггүй байх байсан.

Тиймээс хамгийн хуучин үр дүнг нэг биш, дөрөв дөрвөөр цэвэрлэдэг. Цэвэрлэсэн хэсэг олон дуудлагад тогтмол хэвээр үлддэг. Тэмдэглэлээс бага зэрэг том үр дүнг хөнддөггүй: цэвэрлэх нь бараг хэмнэхгүй мөн хүсэлтийн эхлэлийг өөрчилнө. Хэр олон үр дүн бүтэн үлдэх вэ гэдгийг тоогоор биш хэмжээгээр шийддэг: төсвийн дөрөвний нэгэнд багтах хамгийн шинэ үр дүнгүүд үлдэж, ядаж нэг нь үргэлж үлдэнэ. Өмнөх хувилбар тогтмол зургаан бүтэн үлдээдэг байсан нь богино командын гаралтад зөв байсан ч урт файл уншилттай үед хуучин үр дүнд төсвийн ихэнхийг үлдээдэг байсан.

Татгалзал одоо үүнийг хэлнэ

Загвар хүчингүй гэж татгалзсан хүсэлтийг дахин оролдохгүй; ижил хүсэлтийг дахин илгээвэл ижил хариулт ирнэ. Хэрэв яриа загварт хэт урт болсон бол хэрэглэгч дараах мессежийг харна: «Энэ яриа загварт нэг удаад унших хэтэрхий урт болсон. Дараагийн алхамд шинэ чат эхлүүлээрэй — одоогоор бүтээсэн бүх зүйл хадгалагдана.» Энэ нь хэрэглэгчийн хийх зүйл, системийн эвдрэл биш тул бид тэр даруйд дуудахгүй.

Асуудал 2: агент "өрөө хэмнэхийн" тулд зогсдог байсан

Дэд агент 40 урт бүлэг уншихыг хүсэхэд 2-ыг уншаад «өрөө хэмнэх» гэж хэлээд зогссон. Энэ нь 400,000 токены төсвөөс ойролцоогоор 100,000 токен зарцуулсан байв.

Хуучин үр дүнгүүд одоо түүний төлөө цэвэрлэгдэх гэдгийг тэр мэддэггүй байсан. Тиймээс бид түүнд хэлсэн. Агентын заавар одоо хэлдэг: загвар унших боломжоосоо илүү яриа өсвөл хамгийн хуучин хэрэгслийн үр дүнг цэвэрлэж, хамгийн шинэ нь бүтэн үлдэнэ — тиймээс урт ажлыг өрөө хэмнэхийн тулд зогсоох хэрэггүй; үргэлжлүүлээрэй, хэрэв цэвэрлэгдсэн зүйл хэрэгтэй бол файлыг дахин уншаарай.

Загвар хараагүй засвар нь загварын үүднээс засвар биш. Механизм агент түүнд итгэх тохиолдолд л тусалдаг.

Асуудал 3: бүх зүйл англи мэт токеныг тоолж байсан

Бид токеныг токенизатор ажиллуулахгүйгээр тооцдог байсан: тэмдэгт тоог дөрөвөөр хуваасан. Энэ нь англи хэлний хувьд боломжийн дүрэм. Бусад бичгийн хэлэнд хувьд биш: Орос хэл ойролцоогоор 2.2 тэмдэгт токен тутамд, Хятад эсвэл Япон хэл ойролцоогоор нэг.

Тиймээс Орос бүлэгтэй уншиж байсан дэд агент ойролцоогоор 640,000 токентой хүсэлт илгээсэн, харин бидний тооцоо 400,000 төсвөөс доош байна гэж хэлж байсан. Тооцоо загварын хатуу хязгаараас хэтрүүлэх магадлалтай байсан.

Тооцоо одоо бичгийн хэлээр тооцдог: цэвэр ASCII дөрвөн тэмдэгт токенд, Хятад, Япон, Солонгос нэг тэмдэгт токенд, бусад бүх зүйл — Кирилл, Грек, Араб, аксенттай үсэг, эможи — хоёр тэмдэгт токенд. Энэ нь өндөр тооцох зорилготой. Нэг Орос бүлэгт одоо 43,423 токен гэж тооцдог, хэмжсэн ойролцоогоор 44,600; өмнө нь 25,023 гэж гардаг байсан. Мессеж бичигдсэн хойно өөрчлөгддөггүй тул түүний тооцоо нэг удаа гаргаж, санаж байдаг, алхам бүр дээр дахин тооцдоггүй.

Бидний авсан дүгнэлт

• Хэмжээ жинхэнэ байгаа газарт тайрна. Агентын ажилд энэ нь хэрэглэгчийн мессежүүд биш, хэрэгслийн үр дүнгүүд.
• Агентад өөрийн хамгаалалтын сүлжээний тухай хэлнэ. Үгүй бол хэзээ ч хэрэглэгдэхгүй хязгаарын төлөө төлөвлөдөг.
• "Тэмдэгт ÷ 4" гэдэг нь англи хэлний таамаглал. Олон хэлтэй хэрэглэгчдэд токен тоолдог зүйл бичгийн хэлээр тоолох ёстой, эсвэл жинхэнэ токенизатор ашиглах.
• Кэшид анхаар. Дуудлага бүр урд хэсгээрээ өөрчлөгддөг хүсэлт илүү их зардалтай, удаан ажилладаг.

Та өөрийн апп-д AI онцлог нэмэх гэж байгаа бол LLM гэж юу вэ болон LLM API-г хэрхэн ашиглах вэ гарын авлагууд context window болон токенийг эхнээс нь тайлбарласан. Mythex дээр дэд агентууд хэрхэн ажилладаг талаар илүү дэлгэрэнгүйг дэд агентын docs-д үзнэ үү.