【科技新聞】Imagen,文本到圖像的擴散模型


Imagen,文本到圖像的擴散模型
Imagen, a text-to-image diffusion model

評論

對於抱怨他們不能玩模型的人……我在谷歌工作,我也不能玩模型:'(

我不得不想知道發布這些模型會有多少“毒害”並在互聯網上充斥著 AI 生成的圖像,這使得訓練改進的模型變得困難。畢竟,如果網上每一個 9/10 的“油畫”圖像都開始來自這些生成模型,那麼抓取網絡並從各個領域的真實世界數據中學習將變得越來越困難。本質上,一旦這些東西被廣泛使用,互聯網將變得更難獲取好的數據,模型將開始根據自己的輸出進行訓練。互聯網對人類來說也可能會變得更糟,因為搜索結果將完全被這些“有點逼真”的圖像所污染,這些圖像最終可以通過將字典中的單詞拼湊在一起以極快的速度吐出……

有趣的是,這個可以畫出清晰的文字。 DALLE 模型似乎會生成看起來像文本的奇怪字形。他們在此處顯示的示例具有清晰易讀的字符和正確的拼寫。這和 DALLE 之間的區別讓我懷疑/好奇。我希望我能玩這個模型。


9 歐元票
9-Euro-Ticket

評論

對於所有正在思考的人來說,非常重要的警告是,“哇哦,沒必要買那個 EuRail 通票!或者買一張昂貴的 ICE 車票!”

這些車票適用於所有“Nah- und Regionalverkehr”,明確排除 ICE、IC、EC(國際)和長途巴士(如慕尼黑和蘇黎世之間的巴士)

如果火車號以 RE 或 RB 開頭,那很好,但當然,那些是沿途每個村莊都會停的慢車。

這是為了生活在這裡並為 2 歐元 / 升燃料而苦苦掙扎的人們的利益,而不是那些輕率地支付 60 歐元來乘坐 ICE 的人。似乎沒有任何居住要求,但請記住,你不是這個的目標市場(除非你住在這裡並且正在為燃料價格而苦苦掙扎……)

我認為讓它免費並保持免費將是一個很酷的舉動。 – 更少/沒有昂貴的會計 – 更少/沒有檢查票的人員 – 更少/沒有起訴沒有票的人 – 更少/沒有自動售票機(以及隨之而來的所有維護) – 更少的交通道路,因為你不能“免費”,因此排放量更少(至少在漢堡火車使用綠色能源)並且道路上的磨損更少(可能被火車和公共汽車上的磨損所抵消) – 完全不歧視尊重收入

我不知道這是否適用於城際交通,但對於城市內交通,例如 HVV(負責漢堡及周邊地區的公共交通網絡)每年售出 3000 萬張車票,我想知道他們真正要花多少錢使用上述所有相關因素來做到這一點。

這裡給出了一些上下文: https://www.dw.com/en/germany-introduces-9-ticket-to-offset-…

這張票是德國議會簽署的支持方案的一部分。作為對不斷上漲的能源價格和由此產生的個人出行成本高昂的回應,該公司將支付約 25 億歐元的票價。


計費系統是工程師的噩夢
Billing systems are a nightmare for engineers

評論

等到您了解稅收的複雜性。

如果你認為你認識他們,請關注https://twitter.com/aotearoa_ben/status/1526786701750050817

這是一項改變稅率的法律,如果

1. 購買發生在德克薩斯州。 2. 付款在特定的 2 天期限內結清。 3. 商品價格 < 100 美元。運費必須包含在商品的成本中。 4. 該項目屬於特定類別,幾乎可以肯定與您嘗試使用的任何分類系統都不匹配。

說真的,只舉一個例子, https://comptroller.texas.gov/taxes/publications/98-490/scho…指出只要符合條件的學校用品的成本,包含學校用品的套件就符合條件其中超過了不合格項目的成本。我保證您的會計系統中沒有該類別…

我正在為公用事業公司開發計費系統,這是一場噩夢,但不是因為文章中的原因。

日期沒問題,一切都在月末、季度末或年末結算。

升級是降級簡化,客戶只能在預定義的日期/事件合法地更改關稅。

用法 – 是的,但文章中的示例甚至沒有涉及到這個的複雜性

冪等性並不是真正需要的,計費過程不是連續的,它是一個批處理作業。

現金收款不在計費軟件的範圍內。

徵稅很明確。是的,有多個不同稅率的計費項目,但不是太複雜。所有客戶都是當地人。

噩夢的部分是:

– 客戶可以有多個消費地點,地點可以有多個計價器,客戶可以要求在多張發票上拆分賬單或將多張賬單合併為一張發票

– 儀表可以隨時更換

– 儀表讀數可在完全獨立於計費周期的日期獲得。大多數消費數據只是預測。

– 當實際消耗數據可用時,必須重新計算並補償所有內容(在顯示差異的更正發票上)

– 實際消費數據可能是錯誤的,可能會在以後更正,甚至多次

– 消費積分可以隨時添加或刪除或移動到不同的客戶,但此信息僅在事後可用

– 對於某些客戶,價格可能會在結算週期中發生變化,但消費數據不可用該粒度

– 客戶法律信息(公司名稱、地址)可以在周期中更改

我曾在兩家公司的支付系統工作過。這篇文章很好地提到了許多計費系統挑戰。我認為它低估了在多個團隊中保持大規模冪等性是多麼困難和重要。

此外,它沒有提到金融監管的變化。印度在過去幾年的某個時候發生了變化,需要為印度客戶構建全新的系統。複雜性的一個例子是:該系統適用於在印度的客戶還是適用於在印度的企業(所有者可能不是)?

他也沒有提到欺詐,這基本上是未收回的支出,通常會導致退款。如果您收到過多的退款,您將被罰款。如果您收到更多退款,您將被踢出卡網絡,並且將不再能夠接受該網絡內的卡。

後付款(客戶獲得產品並隨後付款)模型會受到更多欺詐、未收費用等的影響。

與下游支付處理器打交道也很有趣。我還沒有與非常可靠的處理器或銀行合作過。有時他們會返回 500 個 http 代碼,然後處理付款,需要人工干預。有時,付款文件會發生這種情況,因為大多數銀行都會處理交易文件。


留言討論區