你已經閱讀了這個理論,了解了數據的重要性以及所有可以使用的方法。我們準備好開始創(chuàng)建數據集了嗎?呃,沒那么快。我們需要確保我們了解問題空間,并使用它來確定我們甚至需要什么數據。

用戶體驗

以人為本的設計 是一個原則,它總是從用戶和他們的需要開始考慮(而不是技術、政策或其他外部因素)。這可能是一個非常令人興奮和有益的活動,以更好地了解目標用戶和如何服務他們。確保用戶體驗預期是明確的,也可以通過確保團隊中的每個人都能適應相同的成功定義來降低建模項目的風險。

在澄清用戶身份時要問的一些問題包括:

· 我們需要從用戶那里得到什么信息?

· 提供的信息是開放式的還是某種結構化的?

· 模型應如何響應信息不完整的提示?

· 我們的輸出應該是結構化的,還是以散文的形式?

· 我們是否應該總是生成輸出,或者有時要求用戶澄清或提供更多信息?

在我們的案例中,我們將堅持開放式輸入和結構化輸出,以允許用戶靈活性,同時保持可預測性。我們將避免后續(xù)行動,以降低我們的概念證明的復雜性。

現有各種技術和指南?在別處 幫助建模團隊通過更好地理解用戶來制定更好的需求。

實體關系圖

ER圖顯示了系統(tǒng)中涉及的所有實體和關系,是理解系統(tǒng)、用例等的一個非常強大的工具。畫一幅用例的圖片,我們可以使用ERDS來精確了解我們需要捕捉的數據,同時確保我們沒有盲點。

創(chuàng)建ER圖的過程很簡單:寫出所有你能想到的與應用程序相關的實體(名詞)。然后寫出他們之間的關系,就這樣!實際上,這是經過幾個回合完成的,但它創(chuàng)建了一個豐富的工具,對理解和交流您的系統(tǒng)都有用。

下面是我們?yōu)槔着灏偷侠L制的急診室圖:

我們的關系很簡單,所以?相當復雜的 .

數據集屬性

等等!我們還需要對我們的數據集做出更多的決定。下面是一些考慮因素,但您必須深入思考您的用例,以確保您涵蓋了您的數據集的所有基礎。

數據集類型

在本系列中,我們堅持收集和培訓SFT數據,但正如我們之前所述,有許多不同類型的數據需要培訓。

輸入和輸出屬性

在建模中,需要考慮的輸入變量的數量和生成輸出的變量數量是重要的考慮因素,也是衡量用例復雜性的指標。在決定這一點時應該非常謹慎,因為這將影響到你需要包含在數據中的多種情況,并影響到你需要收集的數據量(這也將影響到所需的計算,從而影響到訓練你的模型的成本)。

在我們的案例中,讓我們使用以下輸入:

· 年齡

· 高度

· 重量

· 活動水平

· 飲食限制

· 個人偏好/目標

在輸出量上,讓我們包括多餐的每日膳食計劃,并為每頓膳食提供具體的指導:

· 早餐

· 午餐

· 晚餐

· 小吃1

· 小吃2

每餐:

· 碳水化合物

· 雞/魚/肉

· 乳清蛋白

· 蔬菜

· 油/脂

分布

對于您正在探索的每個屬性,您應該考慮該屬性的自然多樣性。高度多樣化的屬性比有界限的屬性需要更多的數據來充分覆蓋。例如,考慮創(chuàng)建一個數據集,允許用戶詢問周期表中的元素。簡單:周期表中只有這么多元素?，F在考慮一個經過訓練的LLM,它可以識別出在提供元素清單時所有可能的化合物。對于任何給定的輸入,可能的輸出數量實際上是無限的,這使這項任務更具挑戰(zhàn)性。

此外,請注意,你的培訓數據越多樣化,模型就能更好地將概念推廣到培訓語料庫中沒有的例子。

為了證明我們的概念,我們不會用盡每個屬性的分布,而是專注于有限數量的示例。

邊緣案例

在定義您的需求時,您還可能希望確定您希望避免的特定邊緣情況。

在我們的案例中,讓我們避免在用戶懷孕時回答任何問題,而是引導他們尋求專業(yè)人員的幫助。

我們現在有一個很好的數據收集任務規(guī)范,除了一件事:我們需要多少數據?正如我們前面所描述的,這是由輸入/輸出屬性、這些屬性的分布以及我們想要處理的邊緣情況的數目所決定的。

一個快速了解你需要多少價值的方法是考慮一個簡單的公式:

1. 對于每個輸入屬性,評估值可以包含多少"桶"。例如,年齡可能是0-18歲,18-40歲,40-60歲,或者60歲以上4桶。

2. 在你所有的屬性中,把水桶的數量加起來。

3. 加上用例的數量。

這是一種粗略衡量你需要多少數據來完全覆蓋你的用例的方法,也是一個出發(fā)點,可以考慮你要排除哪些數據,或者你不希望考慮某個特定屬性的分布。