回覆區
排序
源氏
源氏不物語
#1樓
3 個月前
樓主在做故事的AI產品嗎?我有一些經驗可以交流,為什麼要使用Structured Output呢?
CC
CCL
回覆 源氏不物語
3 個月前
我目前正在做的是八字的 AI 報告生成部分,但因為八字在中間計算方面比較複雜,所以目前的做法是把八字的講義濃縮成精華後,附註在 Prompt 裡面讓 AI 自己去閱讀。
目前算出來的效果其實都很好,但唯一的問題在於「身強身弱」的判定。這是一個沒有準確答案的特性,原本以為讓 AI 自己判斷就好,但現在最大的問題在於同一份報告中邏輯不一致:它會在文章前半段說這個人是身強,所以如何如何,後面卻又說因為你身弱,所以怎麼怎麼樣。我目前遇到的狀況是這樣。
至於你問到為什麼要用 Structured Output,原因是我希望一份報告直接輸入一次、輸出也就一次。這樣一來,我所花的 API 時間跟 Input Cost 會降低非常多。尤其在做這類報告時,使用者的預期是雖然報告長達上萬字,但應該在 5 分鐘之內就要產出,為了達到這個預期,就必須使用 Structured Output。
還有一點是,我們的報告是以類似 PowerPoint 轉換成 PDF 的方式生成,所以是一頁一頁的狀況。如果不用 Structured Output,目前我還沒想到其他方法可以精準地切割每一個頁面,並確保每一頁的文字主題都是獨立且不相同的。
郭庭
郭庭佑
#2樓
3 個月前
沒記錯的話做 Structured Output 的時候,每一次輸出都會被它當成「一個獨立的任務」來處理,所以才會出現你說的那種主角在第一章是王子、第三章變商人的情況。
我之前也踩過這個坑,分享兩個比較實用的作法給你:
第一個是「把設定寫清楚」:每次 call API 的時候,都把主角是誰、什麼身份、有什麼特質這些重要設定放在 system prompt 或請求的最前面。不要假設 AI 會記得之前的設定,每次都要再提醒它一次。
第二個是「把前面的內容帶上」:在生成第二、三章的時候,把第一章的關鍵設定或大綱一起帶入上下文,不需要全部,但起碼要有「主角是 XX、住在 OO」這種關鍵資訊。這樣 AI 就比較不會跑掉。
我之前是這樣解的,不過我是半年前了,你可以試試看
CC
CCL
回覆 郭庭佑
3 個月前
我這邊澄清一下,我所謂的 Structured Output 是指一次性的輸出,但在輸出的過程中會產生 Key-Value 對。
以我上面的舉例來說,Structured Output 的結構可能是:
1. Key:第一章、第二章、第三章、第四章
2. Value:需要 AI 生成的每一章節故事內容
如果這只是單一輸出,但我利用 Structured Output 將其拆分成不同的文件,我不確定這到底算不算是同一個輸出。不過我詢問了 Google AI 搜尋以及 Grok,兩者一致認為這屬於同一次輸出。
我覺得你給的第一個方法沒錯,我接下來會嘗試看看。至於第二個方法我也想過,但對我而言,「生成速度」非常重要。如果採用多輪對話的方式,將輸出當作輸入再丟回去重做一次,這樣的運作流程會導致生成最終故事的速度太慢了。
ED
Edward Feng
回覆 CCL
3 個月前
比較穩的作法,還是要第二種。如果有效能的考量,可以用2階段的作法,階段一是建立全文大綱、全文貫穿的設定。階段二則是平行的同時生成各個章節。
如果章節之間有相依性,這些關係都算是在階段一要建好的。
關聯 / 被收藏牆
被引用
尚未被引用或收藏
相關卡片
尚無相關卡片