Зургаар дүүрсэн агентын эргэлтийг санах ойд багтаах нь

Production дээр агентын нэг эргэлт 952 МБ дээр санах ой дуусав. Энэ нь зургаан каталогийн скануудаас бүтээгдэхүүнүүдийг таслан авч, таслагдсан хэсгүүдээ харж байх явцад болсон. Нэг л утгагүй алдаа биш — гурван байсан. Загвар руу хийх дуудлага бүр эргэлтийн бүх зургийг бүтэн хэмжээгээр дахин илгээдэг байсан; загвартай харилцахад ашигладаг сан дуудлага бүрийг эргэлт дуусах хүртэл амьд байлгадаг байсан; агентын трейсинг дуудлага бүрийн оролтыг, зургуудыг оруулаад, эргэлтийн туршид хадгалдаг байсан. Бид гурвуулаа засав: зургуудыг илгээхээсээ өмнө багасгаж, дуудлага бүрийн зургуудыг дуусмагц чөлөөлдөг болгосон.

Агент зургийг хэрхэн харах вэ

Mythex дээр бүтээхдээ агент таны төслийн үилчилгээний sandbox доторх ажилладаг. Тэр зургийг харж чадна — таны хавсаргасан скриншот, загвар, төслийн файл, эсвэл өөрөө дөнгөж үүсгэсэн зураг — тэдгээрийг яриатай хамт загварт илгээж.

Эргэлт гэдэг нь таны нэг мессежид агентын хийдэг бүх зүйл юм. Эргэлтийн дотор агент загварыг олон удаа дууддаг: бодох, хэрэгсэл ажиллуулах, үр дүнг харах, дахин бодох. Дуудлага бүр ярианы одоогийн агуулгыг илгээдэг, мөн эргэлтийн зургуудыг текст хэлбэрээр (base64, энэ нь ойролцоогоор гуравны нэгээр том болгодог) агуулдаг.

Санах ойд дүүрсэн эргэлт нь үндэслэлтэй зүйл хийж байсан. Тэр зургаан каталогийн скан авч, тус бүр 2.4 МБ орчим, бүтээгдэхүүнүүдийг нэг бүрчлэн таслан авч, таслагдсан хэсгүүдээ буцааж уншиж шалгаж байв. Энэ нь олон загварын дуудлага байсан бөгөөд тус бүр олон том зураг агуулсан.

Шалтгаан 1: дуудлага бүр бүтэн хэмжээтэй зургийг дахин илгээж байсан

Загварын дуудлага бүр эргэлтийн зургуудыг бүтэн хэмжээгээр агуулсан хүсэлтийн биеийг дахин бүтээдэг байсан — дуудлага бүр ойролцоогоор 20 МБ base64. Бие нь агентын санах ойд нэг мөр болж бүтдэг тул дуудлага бүр дахин ~20 МБ хуваарилдаг байсан.

Бүтэн хэмжээгээр илгээх нь ямар ч ашиггүй байсан. Загвар өөрөө зургийг урт талынх нь дагуу ойролцоогоор 1,300 пиксель хүртэл багасгадаг тул нэмэлт пикселүүд зөвхөн санах ой болон байршуулах хугацааг зардаг.

Засвар: нэг удаа багасгаж, жижиг илгээх

• 400 КБ-аас дээш зургуудыг илгээхээсээ өмнө урт талынх нь дагуу дээд тал нь 1,568 пиксель JPEG болгон хөрвүүлдэг. Жижиг зургууд хэвээр явна.
• Хөрвүүлэлт нь Mythex sandbox бүрт байдаг ImageMagick-ийг ашигладаг бөгөөд файл бүрт нэг удаа ажилладаг. Ижил скануудыг дуудлага бүр харуулдаг эргэлт нь багассан хуулбарыг дахин ашигладаг. Кэш нь файлын зам, хэмжээ, өөрчлөгдсөн огноогоор түлхүүрлэгдсэн тул засварласан файл дахин хөрвүүлэгдэнэ, мөн өөрийн хэмжээний дээд хязгаартай тул санах ойг дүүргэх шалтгаан болж чадахгүй.
• Нэг загварын дуудлагад зургийн төсөв 16 МБ-аас 6 МБ болж буурсан.

Ижил зургаан скан одоо дуудлага бүр 19.7 МБ биш, 4.4 МБ зардаг.

Шалтгаан 2: загварын үйлчлүүлэгч хүсэлтээ хэзээ ч суллаагүй

Хүсэлт бүрийн хэмжээ зөвхөн нэг хэсэг байсан. Санах ой ч дуудлага бүрээр нэмэгдэж байсан. Staging орчинд ижил төрлийн эргэлт бүтэн хог цэвэрлэлтийн дараа ч 369 МБ амьд санах ойг эзэлж байсан — энэ нь хүрэх боломжгүй бүх зүйлийг чөлөөлсний дараа. Heap sampling бүх өсөлтийг загварын үйлчлүүлэгч сангийн хүсэлтийн биеийг кодлодог хэсэгт байгааг харуулсан.

Шалтгаан нь abort listener байсан. Та Stop дарахад эргэлтийн abort signal гал авч, түүнд хамаарах хүсэлт бүр цуцлагддаг. Бид энэ нэг эргэлтийн signal-ийг хүсэлт бүрт дамжуулдаг байсан. Үйлчлүүлэгч сан нь өгсөн signal-д "abort" listener нэмдэг — гэвч хэзээ ч устгадаггүй.

Тэгээд эргэлтийн хүсэлт бүр эргэлт үргэлжлэх хугацаанд эргэлтийн signal-д холбогдсон хэвээр байдаг байсан: listener, энэ нь controller-ийг барьж, controller нь хүсэлтийг, хүсэлт нь зургуудтай нь бүхэл хүсэлтийн биеийг барьдаг байсан.

Засвар: хүсэлт бүрт нэг signal

Одоо хүсэлт бүр өөрийн signal-тэй. Энэ нь зөвхөн тухайн хүсэлт явж байх үед эргэлтийн signal-тэй холбогдож, стримлэсэн хариултын хувьд сүүлчийн chunk уншигдах хүртэл, дараа нь даруй салгагддаг. Stop нь явж буй хүсэлт бүрт хүрсээр байх ба эргэлтийн signal нь зөвхөн нэг listener-ийг нэг удаад барьдаг.

Тестүүд энэ бүх хэсгийг хамаарна:

• 12 дуудлагын дараа эргэлтийн signal дээр listener үлдэхгүй. Засахаас өмнө 12 байсан.
• 8 МБ-ийн 15 хүсэлтийн дараа санах ой тогтмол хэвээр байна. Өмнө нь 128 МБ нэмэгддэг байсан.
• Stop нь стримийн дундуур хүсэлтийг цуцлах чадвартай хэвээр.

Шалтгаан 3: трейсинг дуудлага бүрийн оролтыг хадгалж байсан

Heap snapshot гуравдахь барьцыг харуулсан: загварын дуудлага бүрт ойролцоогоор 6 МБ. Энэ нь агентын framework-ийн event streaming-ээс гарсан. Энэ нь эргэлт дэх дуудлага бүрийг эргэлтийн хүүхэд болгон, оролтуудаа оруулаад, эргэлт дуустал бичдэг байсан. Дуудлага бүрийн хавсаргасан зураг бүр тэдгээртэй хамт санах ойд үлддэг байсан.

Засвар: дуудлага буцмагц зургийг хоосолно

Зургууд зөвхөн тодорхой загварын дуудлагад зориулж бүтээсэн мессежүүдэд хавсардаг. Тэд хэзээ ч яриаллын хадгалсан төлөвт хадгалагддаггүй. Тиймээс дуудлага буцмагц тэдгээр мессежүүдийн зургийн өгөгдлийг хоослох нь аюулгүй. Трейс нь дуудлагын текст бүртгэлийг хадгалдаг; пикселүүд алга болно.

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

Нэг тест агентын graph-ийг ижил event streaming дор ажиллуулж, дуудлага бүрт 4 МБ зурагтай. Засвалгүй бол 16 дуудлагын дараа санах ой 77 МБ нэмэгдсэн. Засвартай бол санах ой тогтмол хэвээр.

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

• Санах ойн асуудал давхаргатай байж болно. Гурван өөр шалтгаан зургуудыг удаан барьж байсан бөгөөд эргэлт санах ойд багтахаас өмнө гурвуулаа арилах ёстой байсан.
• Номын сан өгсөн бүх зүйлийг хадгалж болно. Signal ба трейс хоёулаа өгсөн дуудлагаасаа удаан амьдардаг байсан. Санах ой дуудлага бүрт өсдөг бол дуудлага хүрч буй урт хугацааны объектуудыг хараарай.
• Нөгөө талд хаях зүйлээ илгээж болохгүй. Загвар аль ч тохиолдолд хаях пикселүүд нь дуудлага бүрт бидэнд санах ой зардаг байсан.
• Санах ойг шууд тест хийгээрэй. Засвар бүр heap өсөлт эсвэл listener тоолох тестийн хамт ирсэн тул регресс тоо болж харагдаж, сэтгэлээр унах биш.

Энэ бол ойрын үед агентын гаралттай холбоотой хоёр дахь санах ойн түүх; эхнийх нь прогресс шошго дээр 41,000 удаа дахин илгээгдсэн байсан. Агент юу болох, хэрхэн ажилладаг талаар илүү мэдэхийг хүсвэл AI агент гэж юу вэ гарын авлага болон чатын docs-ийг үзнэ үү.