OpenAI o Gemini embeddings: text-only tipid o multimodal retrieval

Para sa text-only RAG, praktikal na panimulang pagpili ang OpenAI text-embedding-3-small. Sa bayad na paggamit, nakalista sa pahina ng modelo ng OpenAI ang presyong $0.02 bawat isang milyong input token at text-only na input. Kung ang sagot ay maaaring nasa mismong larawan, recording o video, mas angkop na kandidato ang Gemini Embedding 2; ibang uri ng retrieval ang binibili sa dagdag na gastos.

Ang dokumentasyon ng Gemini embeddings ay naglalarawan ng iisang embedding space para sa text, larawan, audio, video at PDF, na nagpapahintulot sa paghahanap sa magkakaibang uri ng nilalaman. Mahalaga ang kaibhang iyon kung kailangang hanapin ang nakikita sa isang larawan o naririnig sa recording. Kung transcript, caption o extracted text lang ang ini-index, text retrieval pa rin ang aktuwal na trabaho at kailangang sukatin kung may dagdag na kalidad ang direktang pag-embed ng media.

Presyo: ihambing ang parehong gawain

Para sa gemini-embedding-2, nakalista sa presyo ng Gemini API ang $0.20 bawat isang milyong text token sa paid standard tier, kasama ang humigit-kumulang $0.00012 bawat larawan, $0.00016 bawat segundo ng audio at $0.00079 bawat video frame. Sampung ulit ang text rate nito kumpara sa nakalistang standard rate ng text-embedding-3-small. May libreng tier ang Gemini, at mas mababa ang nakalistang batch rates; kaya dapat itugma ang paghahambing sa tier at paraan ng pagproseso na talagang gagamitin.

Sa text archive, isama sa tantiya ang paunang pag-embed ng mga dokumento, mga bagong dokumento at mga query habang tumatakbo ang serbisyo. Sa media archive, idagdag ang bilang ng larawang ipoproseso, tagal ng audio at bilang ng video frame. Ang mas mataas na singil sa bawat text token ay maaaring sulit kung naiiwasan nito ang hiwalay na pipeline para sa pagkuha ng impormasyon mula sa media at mas mahusay nitong naibabalik ang tamang asset. Kung text na ang tanging hinahanap, presyo ng text workload ang makabuluhang batayan.

Input limits at dimensions: ano ang epekto sa index?

Sa gabay ng OpenAI sa embeddings, 8,192 token ang maximum input ng text-embedding-3-small at text-embedding-3-large; 1,536 at 3,072 dimension naman ang kani-kanilang default output. Maaari ring paikliin ang vector sa pamamagitan ng dimensions parameter. Inilalathala ng OpenAI ang 62.3% na MTEB evaluation score para sa small model. Hindi kapalit ng maayos na paghahati ng dokumento ang maluwag na input limit: dapat pa ring manatiling sapat ang konteksto sa bawat chunk para maibalik ang tamang sipi.

Sa Gemini Embedding 2, 8,192 token din ang kabuuang maximum input at 3,072 dimension ang default vector; kabilang sa mas maiikling opsiyon ang 768 at 1,536 dimension. Para sa isang request, hanggang anim na larawan, 180 segundong audio, 120 segundong video o isang PDF na hanggang anim na pahina ang nakasaad sa dokumentasyon. Hanggang 32 frame ang pinoproseso mula sa isang video, at hindi kasama ang audio track ng video file. Kung mahalaga ang sinasabi sa video, kailangang iproseso nang hiwalay ang tunog sa disenyo ng archive.

May direktang epekto sa storage at oras ng similarity search ang haba ng vector, lalo na kung malaki ang index. Gayunman, hindi dapat ipalagay na sapat ang mas maikling output dahil lamang kasya ito sa database. Sukatin ang retrieval quality sa bawat napiling dimension gamit ang parehong corpus at pare-parehong settings. Mahalaga rin ang pagkakapareho ng chunk boundaries at metadata filters: kung sabay silang babaguhin sa paglipat ng modelo, hindi matutukoy kung alin ang nagdulot ng pagkakaiba sa mga resulta.

Benchmark para sa Filipino, English at code

Iniulat ng mga may-akda sa papel tungkol sa Gemini Embedding 2 ang markang 69.9 sa multilingual MTEB at 84.0 sa MTEB Code para sa modelong iyon. Dahilan ang mga resultang ito para isama ang Gemini sa pagsusuri ng multilingual at code search. Hindi sila direktang panalo laban sa inilathalang MTEB score ng OpenAI small model: magkaiba ang pinangalanang benchmark set, at hindi ligtas na paghambingin ang dalawang aggregate na marka na para bang iisang pagsubok ang pinagmulan.

Para sa corpus sa Pilipinas, maaaring magkaiba ang hamon ng Filipino-only, English-only at halo-halong query. Maaari ring hanapin ng developer ang isang function gamit ang karaniwang pangungusap kahit code ang laman ng file. Ang mahalagang sukatan ay kung lumilitaw ang tamang sipi, file o asset sa mga query na talagang gagamitin ng serbisyo. Nakakatulong ang benchmark sa pagpili ng mga kandidatong susubukan, ngunit ang sariling corpus ang magpapakita kung ang pagkakaiba ng mga modelo ay mahalaga sa produktong itinatayo.

Aling modelo ang babagay sa bawat gamit?

• Text RAG at mga dokumentong may extracted text: gawing panimulang batayan ang text-embedding-3-small kapag mahalaga ang gastos. Ihambing dito ang Gemini kung may pagbuti sa retrieval na may saysay para sa serbisyo.
• Filipino at English search: subukan ang parehong modelo sa magkakaparehong query at dokumento. Itala nang hiwalay ang resulta para sa bawat wika at sa halo-halong query upang hindi maitago ng pangkalahatang average ang mahinang bahagi.
• Code retrieval: isama ang Gemini Embedding 2 dahil sa naiulat na code benchmark, ngunit gamitin ang sariling repository sa paghahanap ng tamang function at file. Maaari ring isama ang OpenAI small model bilang text-based na panimulang sukatan para sa code search.
• Larawan, audio at video archive: mas may saysay ang Gemini kung kailangang itugma ang text query sa nilalaman ng media mismo. Kung caption, transcript at metadata lang ang saklaw ng paghahanap, ihambing muna ang text-only index bago bayaran ang direktang pag-embed ng media.

Maliit na pagsusuri bago magpalit ng vector index

Pumili ng representatibong mga tanong sa Filipino at English mula sa inaasahang paggamit ng serbisyo. Isama ang code o media query kung bahagi ang mga iyon ng produkto. Para sa bawat tanong, tukuyin ang dokumento o asset na may tamang sagot at ilang kapani-paniwala ngunit maling resulta. Gumawa ng magkahiwalay na index para sa mga kandidatong modelo gamit ang iisang snapshot ng corpus; panatilihing pareho ang chunking, metadata filters at dami ng ibinabalik na hit hangga’t maaari.

1. Sukatin kung nababalik ang relevant na resulta sa napiling bilang ng hit at kung gaano kataas ito sa ranggo. Ang recall at nDCG ay magkaibang kapaki-pakinabang na sukatan: ang una ay tungkol sa pagkakakuha ng tamang resulta, ang ikalawa ay nagbibigay-halaga sa puwesto nito. Hiwalay na ilista ang Filipino, English, code at media na mga query.
2. Itala ang gastos sa pag-embed ng corpus at bagong query, laki ng index at oras ng retrieval. Kung gagamit ng mas maikling vector, ulitin ang parehong pagsukat sa bawat dimension sa halip na ipalagay na pareho ang kalidad ng mga resulta.
3. Kung RAG chatbot ang gumagamit ng retrieval, sukatin nang hiwalay ang pagkuha ng ebidensiya at pagbuo ng sagot. Ang hiwalay na pagsusuri ng retrieval at sagot ay tumutulong matukoy kung sa index o sa paggamit ng nakuha nitong konteksto nagmumula ang problema.

Sa migration, muling i-embed ang corpus at mga query sa napiling modelo bago ilipat ang paghahanap. Ang mga vector mula sa magkaibang modelo ay hindi dapat paghaluin sa iisang similarity search dahil magkaiba ang kanilang representasyon. Kapag magkakalapit ang kalidad sa sariling text corpus, nagiging mabigat na dahilan ang mas mababang bayad na text rate ng OpenAI. Kapag may malinaw na pag-angat sa paghahanap sa mismong larawan, audio o video, doon nagkakaroon ng batayan ang dagdag na gastos sa Gemini.

Basahin din:

• Bago ilunsad ang RAG chatbot, sukatin nang hiwalay ang retrieval at sagot
• ElevenLabs o OpenAI TTS: 185 ms laban sa 2,796 ms sa benchmark
• RAG o fine-tuning: mabilis magbago ang facts, pero hindi laging panalo ang retrieval