AI ярилцлагын асуулт 2: Том хэлний загварын (LLM) хэрэгсэл дуудалтыг хэрхэн найдвартай болгох вэ

Том хэлний загвар (LLM) хэрэгсэл дуудалтад найдвартай, хяналттай ажиллахыг хэрхэн хангах вэ? Зөвхөн сануулга үгээр загварыг "ялгах" биш, харин олон түвшний хязгаарлалтын хүрээг системтэйгээр өгөх хэрэгтэй.

Цаг агаар шалгах жишээнд загварын хэрэгсэл дуудалтад гаргадаг гурван төрлийн "зохиомол" үйлдэл:
1. Хэрэгсэл дуудахгүй, шууд зохиомол хариулт өгөх.
2. Хэрэгсэл дуудахдаа буруу форматтай параметр дамжуулах (жишээ нь, хэрэгсэл "маргааш"-ыг дэмждэггүй ч date="маргааш" гэж дамжуулах).
3. Параметрийн форматыг өөрийн дураар хөрвүүлэх (жишээ нь, "маргааш"-ыг тодорхой огноо болгон хөрвүүлэх), хэрэгсэлд ийм шаардлага байхгүй ч.

Асуудлын үндэс нь загварын гаралт магадлалт шинжтэй, сануулга үг нь зөвхөн магадлалын тархалтад "зөөлөн хязгаарлалт" тавьдаг, харин загварыг чанд дагах механизм биш юм. Нарийн төвөгтэй нөхцөлд энэ "зөөлөн хязгаарлалт" амархан бүтэлгүйтдэг.

Энэ асуудлыг шийдэхийн тулд олон түвшний инженерийн шийдэл хэрэгтэй:

1. Эхний түвшин: Сануулга үгийг оновчтой болгох (зөөлөн хязгаарлалт)

   • Хязгаарлалтын системийн эхлэл, гэхдээ төгсгөл биш.
   • Сануулга үгийг "үйл ажиллагааны гэрээ" гэж үзэж, хэрэгслийн зорилго, параметр бүрийн төрөл, хязгаарыг тодорхой тайлбарлаж, зөвшөөрөгдөхгүй утгын жишээг оруулах.
   • Цөөн жишээ (Few-shot) оруулах, "зөв оролт → зөв дуудалт"-ын жишээг үзүүлж, контекст сургалтаар загварын үйлдлийн хэв маягийг тогтоох.

2. Хоёрдугаар түвшин: JSON Schema нэвтрүүлэх (хатуу хязгаарлалт)

   • Энэ нь "учирлах"-аас "хашлага тавих" руу шилжих чухал алхам.
   • Байгалийн хэлээр параметр тайлбарлахын оронд машин унших, баталгаажуулах боломжтой бүтэцтэй тодорхойлолт (JSON Schema) ашиглах. Талбарын төрөл, заавал бөглөх эсэх, тооллын утгын хүрээг чанд тодорхойлж, additionalProperties: false тохируулгаар загварт тодорхойлогдоогүй талбар гаргахыг хориглох.
   • Гол API платформууд загварын код тайлах үе шатанд ийм бүтэцтэй гаралтын хязгаарлалтыг дэмждэг бөгөөд үүсгэх эх үүсвэрээс формат зөрчихөөс сэргийлдэг.

3. Гуравдугаар түвшин: Баталгаажуулах-засах-дахин оролдох хаалттай цикл (гүйцэтгэлийн нөөц)

   • Schema-тай байсан ч загварын гаралтыг хүлээн авсны дараа синтакс болон Schema баталгаажуулалт хийх шаардлагатай.
   • Баталгаажуулалт амжилтгүй болвол автомат цэвэрлэгээ, дахин оролдох механизм (дээд хязгаартай) зохиож, алдааны мэдээллийг загварт буцаан өгч гаралтыг засах. Дахин оролдолтын тоо хэтэрсэн тохиолдолд бууруулах эсвэл гараар боловсруулах шийдэлтэй байх.

4. Архитектурын түвшин: Үүргийн хуваарилалт

   • Шийдвэр гаргах болон гүйцэтгэх-ийг тусгаарлаж, гурван түвшний архитектур бүрдүүлэх:
     • Загварын түвшин: Зөвхөн шийдвэр гаргах (аль хэрэгслийг дуудах, ямар параметр үүсгэх).
     • Хүрээний түвшин: Гүйцэтгэх хүрээг хариуцах, үүнд Schema баталгаажуулалт, хэрэгсэл дуудалт, дахин оролдолт, үр дүнг нэгтгэх. Энэ нь загварын алдаа хэрэгслийн аюулгүй байдалд шууд нөлөөлөхгүй байх, хэрэгслийн өөрчлөлтөд сануулга үгийг байнга тохируулах шаардлагагүй болгох.
     • Хэрэгслийн түвшин: Тодорхой бизнесийн чадавхыг хэрэгжүүлэх.
   • LangChain, LlamaIndex зэрэг хүрээнүүд яг ийм ажлыг гүйцэтгэдэг.

Одоогийн шийдлийн хязгаарлалт: Параметрийн формат-ын асуудлыг сайн шийддэг ч, параметрийн утга (жишээ нь, "Шанхай" ба "Ху"-ын ижил утга) баталгаажуулалтыг хангалттай хамрахгүй байна. Энэ нь ирээдүйд тулгарах инженерийн сорилт болно.

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