Saiki RAG kadhang kala dianggep ala, amarga ana sing nganggep RAG wis gampang banget (pancen gampang kanggo miwiti, nanging ora nalika digedhekake skalane), utawa nganggep RAG wis diluwihi dening ‘sistem agentik’ (sing ing pirang-pirang kasus, yen ditliti luwih jero, jebul cepet banget katon padha karo RAG...)
Blog iki menehi siji utawa loro tuladha nyata kanggo nuduhake cara kita ngadhepi sawetara tantangan umum, yaiku:
Nangani campuran data teks lan angka lan sebab iki ngrusak RAG sing prasaja: tembung kunci tabrakan lan angka ora nduweni makna semantis.
Napa ngrancang embedding sing ngutamakake ringkesan iku migunani: gawe ringkesan deskriptif cekak kanggo saben chunk, banjur gawe embedding lan jaluk pitakon adhedhasar ringkesan kasebut.
Cara nggawe ringkesan kontekstual: lebokna konteks dokumen induk supaya statistik sing wujude padha tetep bisa dibedakake.
Kapan kudu ngandelake kode lan model Pydantic: yen isi persis iku penting, gabungna kode kustom lan/utawa model Pydantic karo panggilan LLM supaya luwih andal.
Dhasar-dhasare
Sistem RAG ndhukung maneka warna piranti, saka bot dhukungan nganti asisten kawruh internal.
Ing proses internal, umume sampeyan bakal:
Mbagi dadi chunk dokumen sumber sampeyan
Nggawe embedding saben chunk menyang ruang vektor
Njupuk chunk top-K nalika ana pitakon
Ngasilake wangsulan adhedhasar chunk kasebut
Toolkit populer—LangChain, LlamaIndex, lan Filestore saka OpenAI—nggawe langkah-langkah kasebut meh dadi gampang banget. Nanging, ing pipeline nyata sampeyan bakal nemoni data sing ora mung awujud teks padhet, lan RAG dhasar bisa kangelan. Ing bagean sabanjure, kita bakal nuduhake tuladha nyata tantangan data lan mbangun solusi kanthi bertahap nalika kerumitane saya mundhak.
Nalika data sampeyan ora mung teks (nyatane iki lumrah)
Gatekna chunk data ing ngisor iki sajrone konteks game:
JSON
Embedding bisa digunakake amarga ana sesambungan antarane tembung sing disinaoni liwat makna semantis lan tata basa. Ing data ing ndhuwur, ana campuran teks lan angka. Ing njaba konteks sing pas iki, angka-angka kasebut ora nduweni sesambungan karo tembunge. Dadi, chunk data iki bisa diarani mung gabungan sawetara tembung sing rada deskriptif banjur diterusake angka acak.
Iki sejatine ora bakal dadi masalah yen mung data jinis iki sing diduweni, amarga kita isih bisa njupuk adhedhasar embedding saka sawetara tembung deskriptif sing kasedhiya (utawa mung nggunakake text-to-SQL). Nanging, kepriye yen chunk iki kependhem ing antarane akeh chunk teks padhet sing uga ngemot tembung-tembung kasebut? Tuladhane:
JSON
Saiki bayangna kita pengin njupuk “What is the attack range with Draconic Ascension?” Mesthine kita ora bakal bisa njupuk chunk cocog sing dikarepake, amarga chunk kasebut ketutup rame-rame chunk liyane sing ngemot tembung kunci padha.
Masalah utamane yaiku kita ora bisa mbedakake chunk data kasebut kanthi becik, sanajan saben chunk ngemot jinis informasi sing beda babagan topik sing padha. Apa kita bisa nambahi utawa ningkatake data kasebut? Mesthi bisa:smile:
Gawe data sampeyan luwih sugih kanthi ngringkes, ya, sampeyan ora salah maca
Tinimbang langsung nggawe embedding saka chunk, kita bisa luwih dhisik nggawe ringkesan sing nerangake isi data kasebut, banjur nggawe embedding lan njupuk data adhedhasar ringkesan kasebut. Nalika langkah ngasilake wangsulan, kita tetep nggunakake data asli sing disambungake karo ringkesan kasebut.
Dadi, kanggo rong tuladha chunk ing ndhuwur, kita bakal nggawe ringkesan kaya mangkene:
Statistik jangkauan, kacepetan, lan karusakan serangan (gawan lan nalika nganggo Draconic Ascension).
Katrangan lan rincian Draconic Ascension, kalebu syarat aktivasi, efek visual, lan lore.
Banjur, pitakon uga ditambahi supaya “selaras” karo ringkesan. Tuladhane, “What is the attack range with Draconic Ascension?” bakal diowahi dadi “What is the statistics of attack range with Draconic Ascension?” Iki penting banget yen pitakon retrieval asale saka pangguna ing njaba bidang teknis sing nggunakake basa manungsa lumrah, ~~“freestyle”~~. Pungkasane, pangguna ora kudu ngerti utawa mikirake cara kerja RAG kanggo ngoptimalake precision/recall.
Aja njupuk samubarang metu saka konteks (umume uga migunani ing urip)
Saiki, skenario sabanjure yaiku nangani akeh chunk data sing katon padha, kaya ing ngisor iki:
Plain Text
Yen tetep nggunakake pendekatan sing padha, bayangna ana sing takon, “what is character X’s attack range?” Kanthi ringkesan sing lagi wae digawe, kita mung bakal dolanan tebak-tebakan adhedhasar kabegjan, amarga wujude uga padha banget. Dadi, kepiye carane mbedakake?
Wangsulan prasajane: wenehana konteks. Kita cukup nglebokake rujukan menyang dokumen induk chunk ing chunk data, contone {”character”: “X”} ing kasus iki. Saiki kita bisa njupuk data sing bener kanggo karakter X kanthi akurat, sanajan uga duwe data sing padha kanggo karakter Y lan Z.
Nanging, pendekatan sing luwih apik lan bisa ditrapake luwih umum yaiku nggawe ringkesan kontekstual saka chunk kasebut. Tegese, tinimbang mung nggawe ringkesan saka chunk data kasebut, kita bisa nglebokake dokumen induk lan chunk kasebut kanggo nggawe ringkesan kontekstual umum. Ing ringkesan kasebut, kita nerangake sesambungane chunk karo dokumen induk, contone:
Chunk iki menehi statistik rinci babagan … kanggo karakter X. Chunk iki gegandhengan karo dokumen lengkap kanthi nuduhake kaunggulan X ing kacepetan serangan…
Chunk iki menehi statistik rinci babagan … kanggo karakter Y. Chunk iki gegandhengan karo dokumen lengkap kanthi nuduhake statistik Y sing mundhak nalika nggunakake kabisan khususe…
Chunk iki menehi statistik rinci babagan … kanggo karakter Z. Chunk iki gegandhengan karo dokumen lengkap kanthi nuduhake statistik Z sing cocog banget dadi tank ing pertandingan tim…
Cara iki (sing sapérangan diilhami Anthropic) bisa uga katon berlebihan kanggo tuladha ing ndhuwur. Nanging, cara iki efektif banget kanggo chunk sing bisa disalaharteni yen “metu saka konteks”. Kajaba iku, cara iki menehi pendekatan terpadu kanggo kabeh chunk lan njaga pipeline engineering tetep rapi.
Nalika sampeyan kudu ~~seneng ngontrol kabeh~~ tliti
Biasane, kita nampa data kanthi wutuh banjur mbagine dadi chunk kanggo sistem RAG. Ing tuladha iki, kita nuduhake perkara sing rada beda—data sing wis dipérang dadi chunk, nanging chunk-e ala. Chunk kasebut mung bagean acak saka siji chunk logis sing sejatine kudu digabungake maneh. Chunk logis yaiku potongan isi sing lumrahe kudu dadi siji, kayata subbagean dokumen utawa paragraf sing runtut.
Upaya kapisan yaiku nglebokake kabeh data iki menyang panggilan LLM, njaluk LLM nglompokake miturut pamahamane, banjur mbalekake isi sing wis diklompokake. LLM mesthine pinter nindakake iki, ta? Ya lan ora.
Saka sawetara kedadeyan liyane, kita nemokake yen LLM cenderung tumindak kesed lan ora andal nalika dijaluk ngasilake isi kanthi wutuh lan persis, utamane yen kontekse dawa. Lan kuwi pancen lumrah. Nanging, iki dadi alangan gedhe kanggo kasus panggunaan iki amarga kita pancen mbutuhake isi persis tembung demi tembung—ora kena diringkes lan ora kena ana bagean saka isi asli sing diliwati. Ora ana rincian sing oleh kliwatan.
Mesthi wae, sisih “ya”-ne yaiku LLM bisa mangerteni semantik lan struktur chunk sing pecah kasebut kanthi apik. Anggere LLM ora emoh ngutip maneh isine kanthi persis. Hadhuh:/
Banjur, kepiye carane nggunakake kaunggulan LLM tanpa gumantung marang bagean sing ora andal? Kita banjur njaluk tulung kanca lawas sing andal: kode (wacanen: fungsi Python kustom). Lan model Pydantic sing “ora bisa luwih prasaja maneh”. Iki solusine:
Iterasi saben bagean nalika tetep nyimpen chunk logis sing saiki
Ing saben bagean, takokna marang LLM: apa bagean iki kalebu chunk logis sing saiki? Wangsulana ya utawa ora (manut model Pydantic).
Yen ya, tambahna bagean kasebut menyang chunk; yen ora, metuake chunk logis sing saiki amarga wis rampung, banjur wiwiti chunk anyar nganggo bagean kasebut.
Mesthi wae, cara iki nggunakake token rada luwih akeh tinimbang ngolah kabeh isi sapisan. Nanging, kanggo kasus panggunaan sing ngutamakake panyimpenan isi kanthi persis, biaya tambahan sing (sithik) kasebut pancen imbang.
Iki solusi sing prasaja banget, nanging manut prinsip penting: yen perlu tliti, aja mung ngandelake LLM amarga sejatine LLM iku probabilistik.
Kode/fungsi kustom lan model Pydantic bisa digunakake kanggo ngasilake asil sing bisa diprakirakake lan andal, sembari tetep ngoptimalake kabisan LLM.
Nggawe solusi AI generatif iku tantangan engineering sing gedhene padha karo tantangan AI. Muga-muga tuladha iki bisa menehi inspirasi kanggo ngadhepi tantangan unik sampeyan dhewe. Kanggo maca luwih akeh babagan solusi AI generatif sing ngutamakake engineering, wacanen tulisan blog kita babagan rancangan sistem agentik adhedhasar router.