文生圖大型實踐:揭秘百度搜尋AIGC繪畫工具的背後故事!
近日,百度搜尋主任架構師Tianbao應邀參加了知名技術媒體InfoQ的“極客有約”對話節目,與主持人和觀眾們就影像生成技術進行了深入探討,包括百度搜尋的應用場景、相關技術的思考,以及在搜尋業務場景的應用落地經驗。
本文詳細記錄了訪談內容。
亮點:
1、這是一個巨大的變革,從過去使用者在全網尋找影像,轉變為結合了查詢影像和生成影像兩種方式,以滿足使用者更具體的需求,這也在一定程度上鼓勵使用者更主動地表達他們真正的需求。
2、要使一個模型更好地理解中文,準備和清理與中文語義相關的語料非常重要。
3、對於去除低質量樣本和構建高價值樣本,都是圖文對齊所必需的能力。
4、百度搜尋需要滿足使用者在內容和風格方面多樣化的需求,在百度搜尋目前支援了上千種不同的畫面風格定義。
5、遵循美學標準,構建自己的美學認知,無論是在整體模型構建方面還是在演算法最佳化方面,都需要按照這些先進標準來進行相關的指導和評估。
GEEK TALK
01
文生圖的技術發展過程
Q
AIGC從去年9月到現在,我們能看到各種各樣的模型和公司不斷湧現。從最初大家使用Stable Diffusion來生成簡單的影像,到後來用一些其它方法進行生成式影像編輯,後來甚至Adobe Photoshop 支援使用自然語言方式修改圖片。我覺得從之前看到的AIGC在生成文字方面取得的成就之外,還有更多有趣的應用領域。除了生成圖片,還能夠生成影片和音訊。最近,我也看到了一些令人驚豔的生成影片產品。今天想請TianBao老師跟大家展開介紹一下文生圖技術目前的整體發展趨勢是什麼樣的。
TianBao:2022年可以算是文生圖的元年,整體上分為以Stable Diffusion為代表的開源的流派,以及Midjourney 、Adobe的Firefly、Dall-E 3 為代表的閉源模型。而之所以說這一年是元年,是源於 Disco Diffusion。Disco Diffusion的目標主要是 landscape 等風景類創作,風景類場景是一個容錯率比較高的場景,並結合了富有視覺衝擊的色彩,極具藝術質感,這在2021年底至2022年初,是一個很大膽、很驚豔的一個嘗試。
直到2022年2月,Midjourney釋出了v1版本。v1的整體效果相當令人吃驚,但在生成人像方面還差強人意。直到同年7月中旬,Midjourney v3才能正常地生成一些常規人像。在8月份時,作品《太空歌劇院》就透過Midjourney v3進行生成,加上 Photoshop的後期處理,這使得Midjourney成功引起了轟動。
stable-diffusion 1.5版本也在同一時期開源,這個開源事件具有里程碑的意義,因為從那時起,像C站這樣的更多使用者開始湧向去中心化的模型和最佳化領域。隨著開源技術的發展,整個生態系統,包括下游應用,都經歷了爆發式增長和湧現。之後,技術的進步以及下游應用的發展持續在相互促進。
02
Q
AIGC從去年9月到現在,我們能看到各種各樣的模型和公司不斷湧現。從最初大家使用Stable Diffusion來生成簡單的影像,到後來用一些其它方法進行生成式影像編輯,後來甚至Adobe Photoshop 支援使用自然語言方式修改圖片。我覺得從之前看到的AIGC在生成文字方面取得的成就之外,還有更多有趣的應用領域。除了生成圖片,還能夠生成影片和音訊。最近,我也看到了一些令人驚豔的生成影片產品。今天想請TianBao老師跟大家展開介紹一下文生圖技術目前的整體發展趨勢是什麼樣的。
我大致還記得Stable Diffusion剛開始的效果並不太好,例如在嘗試生成人像時,出現了很多扭曲的結果,如一個人有三條腿或多個眼睛。隨著時間推移,這一技術逐漸變得更加逼真。同時,類似Civitai的AI技術也興起,允許人們根據他們的影像進行各種場景的創作,比如受歡迎的原神系列。這種生成影像技術的發展催生了多種應用。比如,在抽卡類遊戲中,原畫師可以利用這一技術來建立遊戲元件。在百度搜尋等國民級應用中,文生圖又如何與場景相結合的?剛開始,我理解它可能是在搜尋框中,使用者輸入關鍵詞後能夠找到相關的影像,但我相信你們會有更多不同的創新。
GEEK TALK
03
文生圖的實踐及挑戰
Q
聽起來這是一個非常有趣的應用場景,因為很多時候,比如我以前製作PPT時,需要找到能滿足我的想象場景的影像,例如客戶使用產品的場景或某個行業的照片。然而,我又不希望侵犯版權,或者避免涉及各種影像來源的糾紛。在這種情況下,能夠找到影像,並在此基礎上進行inpainting修改、邊框補全,甚至進行影像超解析度處理,這實際上是一個非常實用的應用場景。
外界可能認為我們只支援一些基本的影像生成和編輯功能,如生成、簡單編輯、邊框展開以及高解析度影像的補全。但實際上,根據我的瞭解,這項技術在中文語境下是相當具有挑戰性的。特別是針對中文文化和語義場景,大部分模型通常是在以英語為基礎的語境下進行訓練的,其原始語料庫也是英語為主。然而,百度作為中文搜尋引擎領域的巨頭,需要處理中文和英文,甚至一些方言的情況,面對這種挑戰是如何應對的?
Q
對於生成影像大模型,一方面,在訓練過程中,我們需要準備高質量的資料集,建立一個良好的基礎。另一方面,使用者在使用時可能會提供各種各樣的複雜描述,例如描述一個杯子,使用者可能會加入很多形容詞,比如高的、透明的、藍色的,裡面裝了一隻蟋蟀等,這些描述詞可能超出了標準模型支援的Token長度。特別是在中文語境中,使用者的描述可能更長,就像您剛才提到的,一隻戴著帽子、站在山峰頂、吹著西北風、雪花在背後飄落的貓。在這種情況下,如何處理具有大量描述詞和形容詞的影像是一個挑戰嗎?
GEEK TALK
04
圖片美感的評估
Q
確實,與我想象的相比,這個處理的複雜度要高得多。您剛才提到的去除低質量、保留高質量的很重要。您所說的低值和高值是指影像質量對嗎?在生成影像時,如果要生成一隻貓,首先它必須是一隻貓,其次重要的是它必須符合美感。它必須符合一隻貓的形狀,或者說它必須符合一隻狗的形狀,而美感是一個非常主觀的事情。例如,即使是一隻貓,有些人喜歡圓圓的、胖胖的、毛髮豐富的貓,他們認為最好是長得像個球一樣,但有些人認為貓應該像貓一樣,應該有貓的特徵,頭是頭,腿是腿,脖子是脖子。在這種情況下,百度如何處理關於貓應該長成什麼樣子的問題呢?
Q
您剛剛提到內容的一致性,可以展開這個解釋一下這個概念嗎?
GEEK TALK
05
文生圖提示工程
Q
不同場景和用途對美學要求不同,以戴帽子和太陽鏡的貓為例,使用者可能希望生成不同風格的漫畫,如日漫和美漫,它們在視覺體驗上有顯著差異。美漫通常色彩豐富、輪廓鮮明,而日漫則以黑白為主,視覺衝擊力較強。在保障在內容一致性的要求下,百度是如何在不同風格的情況下,從使用者的 prompt 中獲取相關資訊,以支援不同畫風的生成?
在百度搜索中,我們目前支援上千種不同的畫面風格定義。舉例來說,使用者可以將一隻貓呈現為水墨畫或卡通畫,也可以將它呈現為鋁製品或雕刻品,甚至以不同的材質。此外,使用者還可以選擇不同的視角,如帶有運動模糊效果、延時攝影效果,或者魚眼和廣角視角等。我們覆蓋了多種不同的風格和分類,因此使用者如果有更具體的風格要求,只需在他們的prompt中包含相關風格,即可獲得符合他們期望的畫面並具備相應風格。
Q
我還有一個問題,就是關於風格的疊加,是否支援這種操作?例如,能否將魚眼廣角和水墨畫的風格同時應用在影像上?因為一個是關於畫風,另一個是視角,那如果我們想要將水墨畫與卡通風格結合,這是否也是支援的呢?
TianBao:在模型方面,支援多風格是可行的,這樣可以激發新的風格創意。然而,我們面臨的另一個問題是如何在保持內容一致性的前提下,有效地融合和協調多種風格。因為不同風格之間的差異可能很大,可能會發生一些相互制約的情況,但這確實為使用者提供了更多的實驗和探索機會,可以透過嘗試不同風格的組合,實現更廣泛的創意空間。
Q
如果我有多個風格的關鍵詞去描述最後的主體,最後整張圖出來的效果和關鍵詞所在的位置的關聯度大嗎?比如說水墨、卡通風格的貓和卡通、水墨風格的貓,這兩個出來的效果會是一樣的嗎?
Q
剛才提到百度支援上千種風格,我想問,這上千種風格是人工梳理的,還是透過模型聚類後自動生成的?對於使用者來說,知道有這麼多風格可選可能一開始會覺得有點過多,有點難以選擇。
Q
正如你剛提到的,有上千種不同的藝術風格。即使對於非專業和一些專業的美術生來說,通常只瞭解一兩種風格,比如素描或水墨畫。實際上,很少有人能深入瞭解這麼多不同風格並寫出好的提示詞。那麼,當使用者不太瞭解如何編寫prompt提示詞時,我們該怎麼處理呢?比如,使用者第一次使用百度,除非有人告訴他們,他們可能不知道支援上千種風格。在這種情況下,我們應該如何處理,並引導他們瞭解更多有關百度的各種風格以及可以編寫的其他提示詞呢?
Q
有一個更具體的問題需要討論,涉及到prompt的改寫。例如,當我們將一個提示從描述一隻狗轉變為一隻帶帽子的生氣的手勢狗時,使用者實際上無法看到被改寫的部分。我們是否能夠確保每次改寫都是一樣的,或者每次改寫的內容可能略有不同?舉例來說,第一次可能是一隻戴帽子的狗,而第二次可能是一隻戴眼鏡躺在沙灘上的狗。這個過程是否具有隨機性,或者每次都是固定的?
TianBao:對於 prompt的改寫來說,其實我們更期望給到使用者更多多樣性、更多豐富的結果。因為如果是一條狗的話,我們可以想象到的是一個主體是一條狗,可能會有不同的一些犬類的品種,但是狗可能穿著不同服飾出現在不同場景之下,這個對更多人來說會有更多樣的一些結果,大家會有更多的預期。所以在模型層面,我們期望透過prompt這種改寫和最佳化,有更多的多樣性的備選,然後基於使用者實際的反饋,去來感知使用者對哪些風格,對什麼型別的內容場景的一個畫面結果會感興趣,後驗反饋會比較高,這對於整體的prompt的改寫模型也會有資料促進的作用。
GEEK TALK
06
反饋和評估
Q
剛剛提到了改寫,從使用者側收集反饋來迭代模型,有一個詞叫做 RLHF(Reinforcement Learning from Human Feedback)。這裡我覺得最難的點是human feedback是不穩定的,因為人與人之間的主觀觀點會差很多。如果我們需要依賴人的反饋來去迭代模型,其實是比較困難的。如果再落實到說模型的evaluation上來說,在這種情況下,百度是如何去manage balance,在影像生成的方向上去做評估。
TianBao:關於後驗反饋,首先需要考慮反饋資料是否確實能夠代表人類的後驗反饋,這對於反饋質量有更高的要求。因此,可以將這一方面與產品的整體設計和使用者互動相結合,以收集更多積極的使用者行為反饋。例如,當使用者對某個結果感興趣時,他們可能會點選圖片以進行放大檢視,然後進行下載等後續行為,這些都是積極的反饋。如果使用者對某張圖片點贊或進行評論,也提供了直接的反饋。我們希望在整個反饋系統中更有效地收集這些反饋,因為它們實際上反映了使用者的偏好。至於模稜兩可的反饋,只能透過更大的樣本量來收集更具代表性的資料。
Q
過去,無論是傳統的統計機器學習還是標準的深度學習模型,基本上都是監督學習,需要樣本或監督來計算F1分數、IQZ和VCR等指標。然而,對於生成式模型,如GPT系列模型或DALL-E這樣的生成式模型,技術上並沒有像以前那樣的標準基準資料集,大家可以根據這些基準資料集來生成和評估。相比之下,生成式模型需要一種更高效的評價方法,而不是依賴人工逐個觀察。在這個領域,與其讓人們用肉眼逐個觀察,是否有方法可以更高效地進行評估呢?
GEEK TALK
07
未來展望
Q
好的,接下來的問題稍微展望未來,儘管並不是非常遙遠,因為最近我看到許多初創團隊和相關公司正在嘗試這個領域。以動畫為例,動畫實際上是將多幅影像的幀疊加在一起呈現的。通常,動畫電影以每秒24幀或16幀的速度播放。除了靜態單幅影像的編輯,我們可以看到在AIGC領域,對於影片生成或短影片生成,無論是三秒還是七八秒的影片,都在不斷髮展。之前Runway團隊曾舉辦了一個使用文生圖進行影片生成的比賽。您認為在未來多久內,我們會看到第一部完全由AI生成的電影或電影狀態?
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70027828/viewspace-2993599/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Stable Diffusion解析:探尋AI繪畫背後的科技神秘AI
- aigc文生工程師AIGC工程師
- DrawPad 圖形繪畫工具
- DrawPad圖形繪畫工具
- AI繪畫爆火的背後,最後究竟誰在賺錢?AI
- DrawPad for mac 圖形繪畫工具Mac
- DrawPad for mac圖形繪畫工具Mac
- mac圖形繪畫工具:DrawPadMac
- 最新訪談首次披露拍出「天價」AI畫作背後的故事AI
- Redis持久化背後的故事Redis持久化
- Java main方法背後的故事?JavaAI
- Mac OS X 背後的故事Mac
- HTML5背後的故事HTML
- 抖音大型直播的畫質最佳化實踐
- 杉巖:小天才手錶背後的故事,超融合資料庫最佳實踐資料庫
- 小天才手錶背後的故事:杉巖超融合資料庫最佳實踐資料庫
- dyld背後的故事&原始碼分析原始碼
- 蘋果自動駕駛背後的故事蘋果自動駕駛
- 愛回收IPO背後的新老故事
- GCC編譯器背後的故事GC編譯
- RestCloud ETL 社群版背後的故事RESTCloud
- 微博春晚背後的技術故事
- 誰來背鍋?自動駕駛車禍背後的故事自動駕駛
- CAD夢想畫圖中的“繪圖工具——多線段”繪圖
- 10個社交網站背後的故事網站
- 圖片轉繪畫效和繪畫軟體
- 跬步至千里:揭秘谷歌AutoML背後的漸進式搜尋技術谷歌TOML
- 獨立畫素遊戲《光明旅者Hyper Light Drifter》與它背後的故事遊戲
- 百度搜尋萬億規模特徵計算系統實踐特徵
- 郭超:阿里雲Cassandra背後的故事阿里
- 嵌入式—編譯器背後的故事編譯
- AI Gossip - 人工智慧背後的小故事AIGo人工智慧
- 重磅釋出背後:POLARDB的中國故事
- SSH 協議埠號 22 背後的故事協議
- 微軟開源 .Net 平臺的背後故事微軟
- CAD迷你畫圖 for mac(輕量級cad繪圖工具)Mac繪圖
- Mac輕量級cad繪圖工具:CAD迷你畫圖Mac繪圖
- 騰訊與Github的魔幻會面背後的故事…Github