資料格式
所以它這裡用的是路段，而沒有使用座標？
是的，這裡使用的是路段（road segments）而不是直接使用座標（coordinates）。具體來說，實驗中的軌跡資料是透過將每個軌跡與實際的路網進行匹配後，得到的每條軌跡由多個路段組成。每個路段代表了車輛行駛路徑中的一個具體部分，而不是原始的GPS座標點。
在這項研究中，軌跡資料經過預處理和過濾，所有的軌跡都已被匹配到路網，並且每個軌跡的路段是按照實際的道路網路進行表示。這樣，軌跡不僅是由GPS座標點組成的，更多的是與道路網路中的具體路段相關聯的。
例如，在生成異常軌跡時（如Detour和Switch），操作是基於路段的選擇和修改，而非座標點本身。這種基於路段的表示方式幫助模型更好地理解和處理與實際路網相關的異常行為。
這裡有提及軌跡資料的長度麼
在這段內容中提到的軌跡資料的長度有一些說明，但並沒有提供詳細的每條軌跡的長度。具體來說：
-
過濾條件：在資料預處理階段，作者過濾掉了 長度小於30的軌跡，也就是說，每條軌跡至少有30個路段（segments）以上。
-
軌跡內容：每條軌跡由多個路段（road segments）組成，並且這些軌跡已經與路網匹配。
雖然沒有詳細列出每條軌跡的具體長度（如每條軌跡有多少個路段），但可以推測每條軌跡的長度應該大於等於30個路段，符合實驗的過濾條件。
因此，軌跡的長度並不是非常具體的數值，而是透過這一過濾條件間接給出了軌跡的最小長度。
也就是50條是訓練的，50是條是同分布的測試。還有ood的？
是的，您的理解是正確的。根據文中的描述，實驗中每個城市選擇了100個源-目的地（SD）對，每對至少有100條軌跡。
- 訓練集：從每個SD對中隨機選擇50條軌跡作為訓練資料。
- ID測試集：剩下的50條軌跡作為測試資料，這些資料與訓練資料來自相同的分佈，即同分布資料。
- OOD測試集：這部分資料並不來自訓練資料的同一分佈，通常是透過選取其他SD對的軌跡，或者透過某些策略生成的與訓練資料分佈不同的資料，用來測試模型在分佈外資料上的表現。
所以，每個城市的100個SD對中，會有一半的軌跡用於訓練，另一半用於ID測試集，而OOD測試集則是從其他資料來源中選取的。
程式碼處理與文字是否一致
從您提供的程式碼來看，資料處理和前面文字中的描述大致一致。以下是幾個關鍵點對比：
-
路段表示：程式碼中的
TrajectoryLoader和GraphLoader類實現了軌跡資料的載入和處理，資料以路段（而非原始座標）為單位。每個軌跡被對映到具體的路段（透過node2id），並且在預處理時進行了填充（bos_eos_pad）和批處理（batch_preprocess），符合文中提到的基於路段的軌跡表示。 -
軌跡長度：程式碼並未特別強調軌跡長度的過濾條件（例如小於30個路段的軌跡），但透過批處理部分來看，軌跡的長度是存在的，並且在資料預處理過程中進行了填充操作。可以推測，程式碼中也間接遵循了類似的過濾規則，確保每個批次的軌跡都有一定的最小長度。
-
資料集劃分：
- 在 訓練集 和 ID測試集 的劃分上，程式碼透過
TrajectoryLoader類載入了訓練資料，並且進行了批處理。雖然程式碼沒有明確顯示 50/50 的比例劃分，但從train_epoch方法和資料集的使用上可以看出，模型會在這些資料上進行訓練和評估。 - OOD測試集：在
test方法中，程式碼顯式地使用了TrajectoryLoader載入了正常資料集、繞行資料集（detour）、切換資料集（switch）、以及 OOD 資料集（ood_dataset）。這與文中提到的使用與訓練資料分佈不同的資料來評估模型在 OOD 資料上的表現一致。
- 在 訓練集 和 ID測試集 的劃分上，程式碼透過
總結來說，程式碼實現與文中的實驗設計是匹配的，尤其是在資料集劃分和軌跡的表示方式（路段）上，程式碼中對資料集的載入、劃分和處理邏輯與文中的描述一致。
前兩個是資料，後兩個是長度
好的，下面是一個表格，展示了您提到的幾個變數及其含義：
| 變數 | 維度 | 說明 |
|---|---|---|
src_data_batchs |
torch.Size([32, N]) |
輸入資料的批次，每個批次包含 32 條軌跡資料，每條資料的長度為 N（即路段數）。 |
trg_data_batchs |
torch.Size([32, N+2]) |
目標資料的批次，每個批次包含 32 條軌跡資料，每條資料的長度為 N+2（包括 bos 和 eos 標記）。 |
src_length_batchs |
torch.Size([32]) |
每條輸入軌跡的真實長度，即有效的路段數（不包括填充）。 |
trg_length_batchs |
torch.Size([32]) |
每條目標軌跡的真實長度，即有效的元素數（不包括填充的 bos 和 eos 標記）。 |
示例
假設某個批次的維度如下：
-
src_data_batchs: torch.Size([32, 135])：- 表示當前批次的 32 條輸入資料，每條資料包含 135 個路段。
-
trg_data_batchs: torch.Size([32, 137])：- 表示當前批次的 32 條目標資料，每條資料包含 137 個元素，其中 135 個來自輸入資料（路段），另外 2 個是
bos和eos標記。
- 表示當前批次的 32 條目標資料，每條資料包含 137 個元素，其中 135 個來自輸入資料（路段），另外 2 個是
-
src_length_batchs: torch.Size([32])：- 表示每條輸入資料的有效長度，例如所有 32 條資料的真實長度為 135（即每條資料的實際路段數）。
-
trg_length_batchs: torch.Size([32])：- 表示每條目標資料的有效長度，例如所有 32 條資料的目標長度為 137（即每條資料的有效元素數，包括
bos和eos標記）。
- 表示每條目標資料的有效長度，例如所有 32 條資料的目標長度為 137（即每條資料的有效元素數，包括
這個表格總結了資料的結構，幫助您理解各個變數的作用。如果有其他具體問題或需要進一步擴充套件的部分，請隨時告知！
資料的輸入和處理，一個批次32條資料。資料是否來自同一個SD?似乎不一定來自同一個SD
是的，TrajectoryLoader 中的資料處理方式確認了每個批次中資料是分開處理的，並分別送入模型進行訓練。在程式碼中，資料是透過以下幾個步驟組織的：
1. 資料載入 (load_data 方法)
load_data方法從指定的路徑載入軌跡資料（trajectory_path）。資料集是一個字典（dataset），每個字典項對應一個軌跡（traj）。軌跡中的每個節點被對映為一個ID（使用node2id字典），並儲存到self.data列表中。- 資料在載入時會根據
self.shuffle引數決定是否打亂順序。
2. 處理 BOS、EOS 和 Padding
- BOS (Beginning of Sequence) 和 EOS (End of Sequence) 是用於序列開始和結束的特殊標記。
self.bos和self.eos分別被設定為self.label_num-3和self.label_num-2。 - Padding (
self.pad) 用於填充較短的軌跡，使它們具有相同的長度，以便能夠批處理。
3. 批次預處理 (batch_preprocess 方法)
- 該方法按批次處理資料。每個批次包含
batch_size條軌跡資料（如果資料不足一個完整批次，則包含剩餘的資料）。每條軌跡資料被劃分為源資料和目標資料：- 源資料 (
src_data_batchs)：從軌跡中直接提取的資料（沒有 BOS 和 EOS 標記）。 - 目標資料 (
trg_data_batchs)：在源資料的基礎上，加上 BOS 和 EOS 標記。
- 源資料 (
- 每個批次中的軌跡會被填充（padding），使所有軌跡長度一致：
- 源資料會填充到最大長度
max_length，目標資料會填充到max_length + 2（為了容納額外的 BOS 和 EOS 標記）。
- 源資料會填充到最大長度
4. 批次資料和長度資訊
src_data_batchs、trg_data_batchs分別儲存源資料和目標資料（每個批次是一個 PyTorch Tensor）。src_length_batchs和trg_length_batchs儲存每條軌跡的實際長度（在填充後，實際長度可能小於填充後的最大長度）。
5. 批次資料列印
- 在
batch_preprocess方法中，每次生成一個批次後，會列印該批次的源資料、目標資料及其長度的維度，以便除錯和檢視資料是否正確組織。
總結：
在每個批次中，資料是分別處理並輸入到模型中的：
src_data_batchs儲存源軌跡資料。trg_data_batchs儲存目標軌跡資料（加上了 BOS 和 EOS）。- 每條軌跡都會被填充以確保每個批次中的軌跡具有相同的長度，便於批次處理。
- 這些資料（源資料和目標資料）是按批次處理的，但它們不一定來自同一個源-目標對。
這種資料處理方式是常見的序列建模（如 RNN 或 Transformer）訓練中的方法，它將源序列和目標序列（通常是帶有特殊標記的）作為輸入傳遞給模型。
應該是第二種
從您的描述來看，src_data_batchs 和 trg_data_batchs 是每批次輸入到模型的資料，通常每個批次（batch）包含32條軌跡資料。對於如何組織這些資料（是否同一個SD對的軌跡一起輸入，或者來自不同的SD對），有兩種常見的處理方式：
1. 每個批次包含相同SD對的軌跡（SD內批次）：
-
同一SD對的軌跡輸入一起：在這種方式下，每個批次中的32條軌跡通常來源於相同的源-目的地（SD）對，也就是說，每個批次中的32條軌跡的源資料和目標資料都來源於同一個SD對。例如，假設你有100個SD對資料，每個SD對都有100條軌跡，經過劃分後，每批次會從同一個SD對中選擇32條軌跡資料作為源和目標資料輸入模型。
-
源資料和目標資料配對：每批次中的
src_data_batchs和trg_data_batchs的軌跡是一一對應的，它們通常是從同一個SD對中的源軌跡和目標軌跡中選取的。這種方式保證了模型在訓練時每次處理的都是真實的源到目標的對映關係，模型學習如何從源資料（如輸入軌跡）對映到目標資料（如輸出軌跡）。
2. 不同SD對的軌跡混合輸入（跨SD批次）：
-
不同SD對的軌跡混合輸入：另一種常見方式是，在一個批次中，源資料和目標資料可能來自不同的源-目的地（SD）對。這樣，每個批次的32條軌跡可能包含多個SD對的資料。這種方式可以增加訓練資料的多樣性，有助於模型泛化能力的提升。
-
資料打亂與混合：為了保證不同SD對的軌跡資料能被混合並輸入到模型中，通常會對軌跡資料進行隨機打亂（shuffling）。這種方法常用於神經網路訓練中，幫助模型更好地從多樣的資料中學習，而不會僅限於同一SD對的樣本。
3. 模型輸入的處理方式：
無論是哪種方式，資料的輸入過程都會遵循以下幾個步驟：
- 資料預處理：將每條軌跡轉換為數字化表示，可能包括詞彙表的查詢、編碼等。
- 填充與對齊：由於每條軌跡的長度可能不同，通常會進行填充操作，使得批次中的所有軌跡具有相同的長度（例如，填充到最大軌跡長度）。這就是為什麼
src_length_batchs和trg_length_batchs是必需的，它們記錄了去除填充的實際軌跡長度。 - 輸入到模型：填充後的軌跡資料會被輸入到模型的編碼器部分，目標資料會輸入到解碼器部分。模型會透過源資料預測目標資料的相應部分，尤其是在生成任務中，模型會學習如何從源資料的表示中生成目標資料。
綜上所述：
- 是否來自同一個SD對：如果採用的是SD內批次（同一個SD對的資料一起輸入），那麼每個批次中的32條軌跡都會來自同一個SD對。而如果採用跨SD批次（不同SD對的資料一起輸入），那麼一個批次中的32條軌跡可能來自多個不同的SD對。
- 訓練策略：不同的訓練策略會影響這種資料的組織方式。在很多情況下，尤其是針對大規模資料集時，採用跨SD批次可以提高訓練效率，而對於需要保持源和目標一致性較高的任務（如序列到序列的生成任務），可能會使用SD內批次。
根據您的具體任務和模型設計，這兩種方法都可以合理地進行選擇。如果需要進一步確認是哪種方式，您可以檢視資料載入部分的程式碼，看看批次資料是如何組織的。