Ang tanong na nagsimula ng lahat
"Bakit hindi puwedeng may sariling message bubble ang bawat karakter, tulad sa ibang app?"
Madalas naming matanggap ang tanong na ito. At sa totoo lang, magandang tanong ito. Ipinapakita ng karamihan ng chat app ang mga mensahe bilang magkakahiwalay na bubble - isa para sa bawat tao. Kaya bakit pinagsasama ng aming group chat ang mga sagot ng maraming karakter sa iisang mensahe?
Hindi katamaran o pagkakalimot ang sagot. Sinadyang desisyon ito sa engineering na nagmula sa ilang buwang pag-eeksperimento sa tatlong talagang magkakaibang paraan ng pagbuo ng group conversation sa AI.
Ang tatlong arkitektura
Sa pagbuo ng mga usapan sa AI na may maraming karakter, iisang desisyon ang hinaharap ng bawat platform. Eksaktong tatlo ang paraan para gawin ito, at may malalim na epekto ang bawat isa sa gastos, kalidad, at karanasan ng user.
1. Structured output (mga JSON array)
Ang pinakakaraniwang paraan sa industriya. Hihilingin mo sa AI na magbalik ng JSON array kung saan kumakatawan ang bawat element sa sagot ng isang karakter:
[
{
"speaker": "Sherlock",
"emotion": "naintriga",
"content": "Kamangha-mangha. Ipinapahiwatig ng pattern ng putik..."
},
{
"speaker": "Watson",
"emotion": "nalilito",
"content": "Holmes, ano'ng ibig mong sabihin?"
}
]Ang kaakit-akit dito:
- Isang API call, isang beses lang gagastos ng credits
- Madaling i-parse at ipakita bilang magkakahiwalay na message bubble
- Puwedeng magsama ng masaganang metadata (emosyon, aksyon, paglalarawan ng eksena)
- Perpekto para sa pag-generate ng mga mungkahing sagot para sa user
Ang realidad:
- Mamahaling premium model lang (Claude, GPT-4) ang maaasahang sumusuporta sa structured output - nahihirapan ang karamihan ng abot-kayang model na panatilihing consistent ang JSON format
- Nasisira ang buong sagot kapag may error sa format
- Kumakain ng token ang mga instruksyon sa JSON, kaya lumiliit ang espasyo para sa pagkamalikhain
- Parang "nakatali" ang mga model - kadalasang naaapektuhan ang pagkamalikhain
- Mas mahigpit ang mga paghihigpit sa content: kadalasang nagti-trigger ang structured output mode ng mas agresibong content filtering, kaya mas malamang na pumalya ang mga mature o mapangahas na roleplay scenario
- Kontaminasyon ng konteksto: napupuno ng mga JSON structure ang history ng iyong usapan
- Komplikadong error handling: ano ang mangyayari kapag pumalya ang parsing sa gitna ng stream?
Ito ang paraang ginagamit ng karamihan ng third-party na character platform. Gumagana ito, pero totoo ang mga limitasyon.
2. Tool calling (agent mode)
Ang pinaka-"matalinong" paraan. Ang AI ang nagpapasya kung aling karakter ang susunod na magsasalita, tumatawag ng tool para ipahiwatig ito, at saka ginagawa ang sagot ng karakter na iyon. Inuulit ito hanggang maramdamang kumpleto na ang eksena.
Iniisip ng AI: "Dapat mag-react si Watson sa rebelasyong ito"
→ tinatawag ang tool: next_speaker("Watson")
→ ginagawa ang sagot ni Watson
→ Iniisip ng AI: "Ngayon, sisingit si Sherlock"
→ tinatawag ang tool: next_speaker("Sherlock")
→ ginagawa ang sagot ni Sherlock
...
Ang kaakit-akit dito:
- Pinakanatural na daloy ng usapan
- Buong malikhaing kontrol ng AI sa pacing ng eksena
- May nakalaang kalidad ng generation ang sagot ng bawat karakter
- Natural na nakakabuo ng magkakahiwalay na mensahe para sa bawat karakter
Ang realidad:
- Maraming API call = maraming singil sa credits
- Nag-iipon ang latency: N karakter = N round trip
- High-end model lang (Claude, GPT-4) ang maaasahang humahawak ng tool calling - kadalasang pumapalya o nagha-hallucinate ng tool call ang mas murang model
- Komplikadong pamamahala ng state sa pagitan ng mga call
- Panganib ng walang katapusang loop o hindi inaasahang pagtigil
- Bangungot sa debugging: mahirap ulitin ang mga isyu
Ito ang "pangarap na arkitektura" na maganda sa papel pero nagdudulot ng sakit ng ulo sa operasyon kapag malakihan na.
3. Free-form text output (ang kasalukuyan naming pinili)
Ang pinakasimpleng paraan. Hilingin sa AI na isulat nang natural ang eksena, at hayaan itong magpasya kung paano ipapakita ang maraming karakter sa tuloy-tuloy na prosa:
Yumuko pasulong si Sherlock, matalas ang tingin. "Kamangha-mangha.
Ipinapahiwatig ng pattern ng putik na galing sa silangan ang ating suspek."
Kumunot ang noo ni Watson. "Holmes, ano'ng ibig mong sabihin? Basta putik lang 'yan."
"Basta putik lang?" Ngumiti si Sherlock. "Mahal kong Watson, walang
bagay na 'basta lang.'"
Ang kaakit-akit dito:
- Gumagana sa bawat AI model, walang kailangang espesyal na feature
- Pinakamalawak na kalayaan sa pagkamalikhain - natural na nagsusulat ang AI
- Malinis na konteksto: parang nobela ang history ng usapan
- Napakahusay na karanasan sa streaming
- Isang call, predictable ang gastos
- Pinakasimpleng ipatupad at i-maintain
Ang realidad:
- Nasa iisang message block ang lahat ng karakter
- Hindi madaling i-regenerate ang sagot ng iisang karakter
- Limitado ang flexibility ng UI
- Baka malito ang mga user na umaasa ng chat-style na bubble
Natutunan namin ito sa mahirap na paraan
Ito ang isang bagay na hindi pa namin naibabahagi sa publiko: gumamit ng tool calling ang unang bersyon ng aming group chat.
Naniwala kami sa "pangarap na arkitektura." AI ang nagpapasya kung sino ang susunod na magsasalita, may sariling generation ang bawat karakter, magaganda at magkakahiwalay na message bubble. Elegante ito. Matalino ito. Pero sakuna rin ito sa production.
Nakaranas ang mga user ng hindi mahulaang gastos - minsan 3x ng inaasahan nila para sa parehong usapan. Malaki ang pagbabago-bago ng bilis ng pagsagot depende sa kung ilang karakter ang pinasyang isali ng AI. Nagha-hallucinate ng tool call o naiipit sa loop ang mas murang model. Napuno ang aming error log ng mga edge case na hindi namin kailanman inasahan.
Matapos ang ilang buwan ng mga patch at workaround, ginawa namin ang mahirap na desisyong buuin ito ulit mula sa simula gamit ang free-form text output. Parang pag-atras ito sa pakiramdam. Pero minsan, ang "hindi gaanong matalinong" solusyon ang mas matalinong pagpili.
Bakit namin ito pinili
Matapos masusing subukan ang tatlong paraan - at i-ship ang isa sa production - pinili namin ang free-form text para sa group chat. Ito ang dahilan:
Stability higit sa mga feature - Hindi mahulaan kung kailan pumapalya ang structured output. Kapag nasira ang group chat mo sa gitna ng usapan, wala nang pakialam ang mga user sa magkakahiwalay na bubble - gusto lang nilang gumana ito. Hindi kailanman pumapalya ang free-form text dahil sa isyu sa format.
Kalidad higit sa dami - Banayad na binabawasan ng mahigpit na format ang pagkamalikhain ng AI. Nang paghambingin namin ang mga output, palaging mas buhay at mas natural ang mga interaksyon ng karakter sa free-form. Nakapag-focus ang AI sa pagkukuwento sa halip na sa JSON syntax.
Predictable na gastos - Naniningil ang agent mode kada karakter kada sagot. Puwedeng umabot sa 5-10x ng inaasahan ang gastos ng isang eksenang may limang karakter. Karapat-dapat sa predictable na presyo ang mga user.
Gumagana sa lahat - Sinusuportahan namin ang maraming AI model. Hindi lahat ay pantay na mahusay sa structured output o tool calling. Gumagana kahit saan ang free-form text, kaya mas maraming mapagpipiliang model ang mga user.
Ang trade-off na tinatanggap namin
Oo, isinasakripisyo namin ang karanasang "isang bubble kada karakter." Pero ang nakukuha namin:
- Matibay na pagiging maaasahan
- Mas mahusay na kalidad ng pagkamalikhain
- Predictable na gastos
- Mas malawak na suporta sa model
- Mas malinis na history ng usapan
Para sa group roleplay, kung saan pinakamahalaga ang immersion, naniniwala kaming sulit ang trade-off na ito.
Ang paparating: Story Mode
Ito ang isang nakakatuwang balita: bumubuo kami ng bagong Story Mode na gumagamit ng structured output.
Bakit iba ang paraan? Iba ang mga priyoridad ng Story Mode:
- Mas mahalaga ang eksaktong kontrol sa eksena kaysa sa malayang pagkamalikhain
- May dagdag na halaga ang masaganang metadata (mga anggulo ng camera, music cue, paghahati ng kabanata)
- Mas predictable ang format (malinaw na istruktura ng kabanata/eksena)
- Umaasa ang mga user ng mas "pinaghandaang" karanasan
Magkakaibang gamit, magkakaibang arkitektura. Hindi kami panatiko sa iisang paraan - pinipili namin kung ano ang pinakamakabubuti sa mga user.
Ang tapat na katotohanan
Walang perpektong solusyon para sa mga usapan sa AI na may maraming karakter. Bawat paraan ay may ipinagpapalit na mahalagang bagay kapalit ng iba.
Ang ibang platform na nagpapakita ng magkakahiwalay na bubble? Malamang na gumagamit sila ng structured output at tinatanggap ang mga limitasyon nito. Ang mga platform na may mas "matalinong" kontrol sa eksena? Malamang na tool calling na may mas mataas na gastos at latency.
Pinili namin ang daang inuuna ang pinakapinahahalagahan ng aming mga user: maaasahan, malikhain, at matipid na group roleplay.
Maganda ang karanasang may magkakahiwalay na bubble. Pero hindi kapalit ng lahat ng iba pa.
Ang sinusubukan namin
Nag-eeksperimento kami sa mga hybrid na paraan:
- Post-processing parsing: Paggamit ng magagaang model para hatiin sa mga segment ng karakter ang free-form text pagkatapos ng generation
- Opsyonal na structured mode: Hinahayaan ang mga power user na pumili ng structured output kapag kailangan nila ng eksaktong kontrol
- Smart scene detection: Awtomatikong pagtukoy ng mga natural na hatian para sa mas mahusay na pagpapakita sa UI
Hindi ang layunin ang hanapin ang "tamang" sagot. Ang layunin ay patuloy na pagandahin ang karanasan habang pinapanatili ang gumagana.
May ideya ka ba kung paano dapat gumana ang group chat? Gusto naming marinig mula sa iyo.