{
  "id": 684213,
  "title": "#[27th] Solution: ByT5-base + Gemini-3.0 + Ensemble",
  "url": "/competitions/deep-past-initiative-machine-translation/writeups/27th-solution-byt5-base-gemini-3-0-ensembl",
  "author_name": "",
  "post_date": "2026-03-24T03:49:06.037Z",
  "votes": 11,
  "comment_count": 2,
  "views": 0,
  "content": "<h2>0.Preface</h2>\n<p>First and foremost, I would like to express my gratitude to the organizers for hosting this excellent Akkadian translation competition (even though we encountered—and subsequently resolved—various challenges throughout the event). Despite these hurdles, it remained a truly remarkable contest !</p>\n<p>I would like to give special thanks to one of my teammates, <a href=\"https://www.kaggle.com/colhomy\" target=\"_blank\">@colhomy</a> , who invested a tremendous amount of effort into training the models and cleaning the data during the competition. I also wish to thank my other teammates for the diverse ideas and approaches they contributed during the early stages of the competition, which were instrumental in helping us achieve such a successful result. \nAt the end of, I would like to thank <a href=\"https://www.kaggle.com/giovannyrodrguez\" target=\"_blank\">@giovannyrodrguez</a> 's <a href=\"https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline\" target=\"_blank\">code</a>. his code provides a robust ensemble method.</p>\n<h2>1. Overview</h2>\n<ul>\n<li><strong>Model</strong>: ByT5-base only (Prefix: <code>\"translate Akkadian to English: \"</code>)</li>\n<li><strong>Hardware</strong>: Single RTX 4090</li>\n<li><strong>Key Strategy</strong>: For me, the only reliable way to consistently improve the score in this competition was increasing the data volume.</li>\n</ul>\n<h2>2. Pre-processing &amp; Post-processing</h2>\n<ul>\n<li><strong>Handling</strong>: Processed based on discussion information, similar to public code but with key differences.</li>\n<li><strong>Preprocessing Details</strong>: I used full <code>&lt;gap&gt;</code> and decimal processing in the preprocessing stage, whereas some public code versions put these steps in post-processing.</li>\n<li><strong>Decimal Normalization</strong>: In addition to converting decimals into the <code>⅚</code> form, I also handled the <code>5/6</code> forms in the data, processing both decimal and <code>5/6</code> formats into the <code>⅚</code> form.</li>\n<li><strong>Official Suggestions</strong>: Several official processing methods mentioned in the discussions did not lead to a score increase (e.g., <code>-textiles —&gt; kutānum textiles</code>, etc.).</li>\n<li><strong>Inference Chunking</strong>: To prevent exceeding the ByT5-base capacity, two chunking methods were considered: splitting by keywords (as seen in public code) and splitting by token counts at spaces. I ultimately chose the latter.</li>\n</ul>\n<h2>3. Data Engineering (Powered by Gemini-3.0-flash-preview)</h2>\n<p>Gemini-3.0-flash-preview was used for splitting, correction, pseudo-labeling, and PDF identification.</p>\n<h3>A. Training Set Optimization (1,500 → 8,000 samples)</h3>\n<p>Used Gemini-3.0-flash-preview to split <code>train.csv</code> to avoid the 512-token input limit for the prefix + transliteration.</p>\n<ul>\n<li><strong>SYSTEM_PROMPT</strong>: Used for samples requiring splitting (script determined by tokens ≥ 400). A single request handled: Splitting + Alignment Check + Noise Trimming.</li>\n<li><strong>SYSTEM_PROMPT_TRIM</strong>: Used for samples not requiring splitting. A single request handled: Alignment Check + Noise Trimming.</li>\n<li><strong>Alignment Strategy</strong>: Source and translation must semantically correspond segment-by-segment. If the translation contained parts not in the source (or vice versa), only corresponding parts were kept, and explicitly redundant parts were deleted.</li>\n<li><strong>Core Rule</strong>: \"Only delete, never add\" to ensure data remains authentic.</li>\n<li><strong>Action Labeling</strong>: Gemini was required to output an <code>action</code> label for each entry:<ul>\n<li><code>keep</code>: Kept in original form, no deletions made.</li>\n<li><code>trim</code>: Deleted a part (trimmed redundant or non-corresponding content).</li>\n<li><code>delete</code>: Entire entry invalid or unable to align, suggested for discard (source and translation do not correspond at all).</li></ul></li>\n<li><strong>Format</strong>: JSON output.</li>\n</ul>\n<h3>B. Publication Data (~56,000 samples)</h3>\n<ol>\n<li><strong>Pseudo-labels (16,000 samples)</strong>:\nPseudo-labels were generated twice for publication transliteration text. Since Gemini has poor handling of specific proper nouns (people, places, gods, and especially diacritics), I built a correction pipeline:<ul>\n<li><strong>Blacklist</strong>: Established a \"non-proper noun\" blacklist to exclude common vocabulary and prevent semantic issues.</li>\n<li><strong>Lexicon Extraction</strong>: Used <code>OA_Lexicon_eBL.csv</code>, <code>onomasticon.csv</code>, and <code>train.csv</code> to extract transliteration-to-replacement pairs.</li>\n<li><strong>Frequency Filtering</strong>: Scanned <code>train.csv</code>; if a transliteration had multiple translation variants, only the most frequent one appearing in <code>train.csv</code> was used.</li>\n<li><strong>Noise Control</strong>: Manually corrected common vocabulary that leaked into the mapping. These words often appear in the data and lead to significant noise.</li>\n<li><strong>Implementation</strong>: These proper noun mappings were provided as notes to Gemini during pseudo-labeling.</li></ul></li>\n<li><strong>publication.csv Content (40,000 samples)</strong>:\nDue to inaccurate transliterations in <code>publication.csv</code>, the same proper noun correction method was applied. Gemini was used to extract paragraphs containing both source and translation.</li>\n</ol>\n<h3>C. Final Cleaning</h3>\n<p>Due to model instability, I performed a final cleanup of erroneous samples, including empty values and samples where the source was more than twice as long as the translation (source is usually shorter than translation).</p>\n<ul>\n<li><strong>Total Samples</strong>: ~8,000 (Split Train) + ~16,000 (Pseudo-labels) + ~40,000 (Publication Content) = <strong>~64,000 samples</strong>.</li>\n</ul>\n<h2>4. Training Details</h2>\n<ul>\n<li><strong>Epochs</strong>: 15 (Best checkpoint usually around Epoch 10).</li>\n<li><strong>Optimizer</strong>: AdamW (Found to be more effective than Adafactor, despite the latter being faster and more memory-efficient).</li>\n<li><strong>Precision</strong>: <strong>FP32</strong> (Used to prevent NaN values).</li>\n<li><strong>Hyperparameters</strong>: LR 2e-4, Batch Size 4, Gradient Accumulation 16, Max Length 512.</li>\n<li><strong>Observation</strong>: Pre-training on large data followed by fine-tuning on <code>train.csv</code> was effective for scores below 35. However, after exceeding 36, fine-tuning on <code>train.csv</code> caused a drop in LB score. I switched to training on the mixed dataset directly.</li>\n<li><strong>Training Time</strong>: ~10-12 hours with <code>group_by_length</code> enabled.</li>\n</ul>\n<h2>5. Inference &amp; Ensemble</h2>\n<ul>\n<li><strong>Inference</strong>: Long and short texts were separated for different inference logic using chunking.</li>\n<li><strong>Ensemble Strategy</strong>: <ul>\n<li>Combined two high-score models (&gt;37) with two lower-score models (&lt;36.5) trained on different data ranges.</li>\n<li><strong>Weighting</strong>: (High-Score * 0.8) + (Low-Score * 0.2) to form two model pairs (a and b).</li>\n<li><strong>MBR Decoding</strong>: Minimum Bayes Risk (MBR) was performed on these pairs using <strong>chrF++</strong> as the similarity metric.</li>\n<li><strong>Settings</strong>: <code>num_beam_cands = 4</code>, <code>num_beams = 8</code>.</li></ul></li>\n</ul>\n<h2>6. What Worked vs. What Didn’t</h2>\n<ul>\n<li><strong>Effective (but not in final sub)</strong>:<ul>\n<li><strong>Test Time Training (TTT)</strong>: Improved single-model scores, but wasn't included in the final submission due to deadline. Effective TTT requires Adafactor, BF16, and dynamic padding for efficiency.</li></ul></li>\n<li><strong>Ineffective Attempts</strong>:<ul>\n<li>Certain post-processing rules (logically sound but didn't work in practice).</li>\n<li><strong>Reinforcement Learning (DPO)</strong>: Likely failed due to training methods or data issues. While I had enough pseudo-labels, high-quality \"real\" label data may have been insufficient.</li></ul></li>\n</ul>\n<h2>7. Future Directions</h2>\n<ul>\n<li><strong>Chunking Optimization</strong>: I believe a dedicated model could be trained specifically to perform chunking for Akkadian text.</li>\n</ul>\n<h2>8.About Code</h2>\n<ul>\n<li>Our Ensemble method based on the <a href=\"https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline\" target=\"_blank\">public code</a> (but with models are own.) </li>\n<li>The Model Training strategy has been mentioned above. </li>\n</ul>",
  "messages": [
    {
      "id": "3427406",
      "postDate": "03/24/2026 03:35:50",
      "content": "<h2>0.Preface</h2>\n<p>First and foremost, I would like to express my gratitude to the organizers for hosting this excellent Akkadian translation competition (even though we encountered—and subsequently resolved—various challenges throughout the event). Despite these hurdles, it remained a truly remarkable contest !</p>\n<p>I would like to give special thanks to one of my teammates, <a href=\"https://www.kaggle.com/colhomy\" target=\"_blank\">@colhomy</a> , who invested a tremendous amount of effort into training the models and cleaning the data during the competition. I also wish to thank my other teammates for the diverse ideas and approaches they contributed during the early stages of the competition, which were instrumental in helping us achieve such a successful result. \nAt the end of, I would like to thank <a href=\"https://www.kaggle.com/giovannyrodrguez\" target=\"_blank\">@giovannyrodrguez</a> 's <a href=\"https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline\" target=\"_blank\">code</a>. his code provides a robust ensemble method.</p>\n<h2>1. Overview</h2>\n<ul>\n<li><strong>Model</strong>: ByT5-base only (Prefix: <code>\"translate Akkadian to English: \"</code>)</li>\n<li><strong>Hardware</strong>: Single RTX 4090</li>\n<li><strong>Key Strategy</strong>: For me, the only reliable way to consistently improve the score in this competition was increasing the data volume.</li>\n</ul>\n<h2>2. Pre-processing &amp; Post-processing</h2>\n<ul>\n<li><strong>Handling</strong>: Processed based on discussion information, similar to public code but with key differences.</li>\n<li><strong>Preprocessing Details</strong>: I used full <code>&lt;gap&gt;</code> and decimal processing in the preprocessing stage, whereas some public code versions put these steps in post-processing.</li>\n<li><strong>Decimal Normalization</strong>: In addition to converting decimals into the <code>⅚</code> form, I also handled the <code>5/6</code> forms in the data, processing both decimal and <code>5/6</code> formats into the <code>⅚</code> form.</li>\n<li><strong>Official Suggestions</strong>: Several official processing methods mentioned in the discussions did not lead to a score increase (e.g., <code>-textiles —&gt; kutānum textiles</code>, etc.).</li>\n<li><strong>Inference Chunking</strong>: To prevent exceeding the ByT5-base capacity, two chunking methods were considered: splitting by keywords (as seen in public code) and splitting by token counts at spaces. I ultimately chose the latter.</li>\n</ul>\n<h2>3. Data Engineering (Powered by Gemini-3.0-flash-preview)</h2>\n<p>Gemini-3.0-flash-preview was used for splitting, correction, pseudo-labeling, and PDF identification.</p>\n<h3>A. Training Set Optimization (1,500 → 8,000 samples)</h3>\n<p>Used Gemini-3.0-flash-preview to split <code>train.csv</code> to avoid the 512-token input limit for the prefix + transliteration.</p>\n<ul>\n<li><strong>SYSTEM_PROMPT</strong>: Used for samples requiring splitting (script determined by tokens ≥ 400). A single request handled: Splitting + Alignment Check + Noise Trimming.</li>\n<li><strong>SYSTEM_PROMPT_TRIM</strong>: Used for samples not requiring splitting. A single request handled: Alignment Check + Noise Trimming.</li>\n<li><strong>Alignment Strategy</strong>: Source and translation must semantically correspond segment-by-segment. If the translation contained parts not in the source (or vice versa), only corresponding parts were kept, and explicitly redundant parts were deleted.</li>\n<li><strong>Core Rule</strong>: \"Only delete, never add\" to ensure data remains authentic.</li>\n<li><strong>Action Labeling</strong>: Gemini was required to output an <code>action</code> label for each entry:<ul>\n<li><code>keep</code>: Kept in original form, no deletions made.</li>\n<li><code>trim</code>: Deleted a part (trimmed redundant or non-corresponding content).</li>\n<li><code>delete</code>: Entire entry invalid or unable to align, suggested for discard (source and translation do not correspond at all).</li></ul></li>\n<li><strong>Format</strong>: JSON output.</li>\n</ul>\n<h3>B. Publication Data (~56,000 samples)</h3>\n<ol>\n<li><strong>Pseudo-labels (16,000 samples)</strong>:\nPseudo-labels were generated twice for publication transliteration text. Since Gemini has poor handling of specific proper nouns (people, places, gods, and especially diacritics), I built a correction pipeline:<ul>\n<li><strong>Blacklist</strong>: Established a \"non-proper noun\" blacklist to exclude common vocabulary and prevent semantic issues.</li>\n<li><strong>Lexicon Extraction</strong>: Used <code>OA_Lexicon_eBL.csv</code>, <code>onomasticon.csv</code>, and <code>train.csv</code> to extract transliteration-to-replacement pairs.</li>\n<li><strong>Frequency Filtering</strong>: Scanned <code>train.csv</code>; if a transliteration had multiple translation variants, only the most frequent one appearing in <code>train.csv</code> was used.</li>\n<li><strong>Noise Control</strong>: Manually corrected common vocabulary that leaked into the mapping. These words often appear in the data and lead to significant noise.</li>\n<li><strong>Implementation</strong>: These proper noun mappings were provided as notes to Gemini during pseudo-labeling.</li></ul></li>\n<li><strong>publication.csv Content (40,000 samples)</strong>:\nDue to inaccurate transliterations in <code>publication.csv</code>, the same proper noun correction method was applied. Gemini was used to extract paragraphs containing both source and translation.</li>\n</ol>\n<h3>C. Final Cleaning</h3>\n<p>Due to model instability, I performed a final cleanup of erroneous samples, including empty values and samples where the source was more than twice as long as the translation (source is usually shorter than translation).</p>\n<ul>\n<li><strong>Total Samples</strong>: ~8,000 (Split Train) + ~16,000 (Pseudo-labels) + ~40,000 (Publication Content) = <strong>~64,000 samples</strong>.</li>\n</ul>\n<h2>4. Training Details</h2>\n<ul>\n<li><strong>Epochs</strong>: 15 (Best checkpoint usually around Epoch 10).</li>\n<li><strong>Optimizer</strong>: AdamW (Found to be more effective than Adafactor, despite the latter being faster and more memory-efficient).</li>\n<li><strong>Precision</strong>: <strong>FP32</strong> (Used to prevent NaN values).</li>\n<li><strong>Hyperparameters</strong>: LR 2e-4, Batch Size 4, Gradient Accumulation 16, Max Length 512.</li>\n<li><strong>Observation</strong>: Pre-training on large data followed by fine-tuning on <code>train.csv</code> was effective for scores below 35. However, after exceeding 36, fine-tuning on <code>train.csv</code> caused a drop in LB score. I switched to training on the mixed dataset directly.</li>\n<li><strong>Training Time</strong>: ~10-12 hours with <code>group_by_length</code> enabled.</li>\n</ul>\n<h2>5. Inference &amp; Ensemble</h2>\n<ul>\n<li><strong>Inference</strong>: Long and short texts were separated for different inference logic using chunking.</li>\n<li><strong>Ensemble Strategy</strong>: <ul>\n<li>Combined two high-score models (&gt;37) with two lower-score models (&lt;36.5) trained on different data ranges.</li>\n<li><strong>Weighting</strong>: (High-Score * 0.8) + (Low-Score * 0.2) to form two model pairs (a and b).</li>\n<li><strong>MBR Decoding</strong>: Minimum Bayes Risk (MBR) was performed on these pairs using <strong>chrF++</strong> as the similarity metric.</li>\n<li><strong>Settings</strong>: <code>num_beam_cands = 4</code>, <code>num_beams = 8</code>.</li></ul></li>\n</ul>\n<h2>6. What Worked vs. What Didn’t</h2>\n<ul>\n<li><strong>Effective (but not in final sub)</strong>:<ul>\n<li><strong>Test Time Training (TTT)</strong>: Improved single-model scores, but wasn't included in the final submission due to deadline. Effective TTT requires Adafactor, BF16, and dynamic padding for efficiency.</li></ul></li>\n<li><strong>Ineffective Attempts</strong>:<ul>\n<li>Certain post-processing rules (logically sound but didn't work in practice).</li>\n<li><strong>Reinforcement Learning (DPO)</strong>: Likely failed due to training methods or data issues. While I had enough pseudo-labels, high-quality \"real\" label data may have been insufficient.</li></ul></li>\n</ul>\n<h2>7. Future Directions</h2>\n<ul>\n<li><strong>Chunking Optimization</strong>: I believe a dedicated model could be trained specifically to perform chunking for Akkadian text.</li>\n</ul>\n<h2>8.About Code</h2>\n<ul>\n<li>Our Ensemble method based on the <a href=\"https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline\" target=\"_blank\">public code</a> (but with models are own.) </li>\n<li>The Model Training strategy has been mentioned above. </li>\n</ul>",
      "rawMarkdown": "## 0.Preface\nFirst and foremost, I would like to express my gratitude to the organizers for hosting this excellent Akkadian translation competition (even though we encountered—and subsequently resolved—various challenges throughout the event). Despite these hurdles, it remained a truly remarkable contest !\n\n I would like to give special thanks to one of my teammates, @colhomy , who invested a tremendous amount of effort into training the models and cleaning the data during the competition. I also wish to thank my other teammates for the diverse ideas and approaches they contributed during the early stages of the competition, which were instrumental in helping us achieve such a successful result. \nAt the end of, I would like to thank @giovannyrodrguez 's [code](https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline). his code provides a robust ensemble method.\n\n## 1. Overview\n- **Model**: ByT5-base only (Prefix: `\"translate Akkadian to English: \"`)\n- **Hardware**: Single RTX 4090\n- **Key Strategy**: For me, the only reliable way to consistently improve the score in this competition was increasing the data volume.\n\n## 2. Pre-processing & Post-processing\n- **Handling**: Processed based on discussion information, similar to public code but with key differences.\n- **Preprocessing Details**: I used full `<gap>` and decimal processing in the preprocessing stage, whereas some public code versions put these steps in post-processing.\n- **Decimal Normalization**: In addition to converting decimals into the `⅚` form, I also handled the `5/6` forms in the data, processing both decimal and `5/6` formats into the `⅚` form.\n- **Official Suggestions**: Several official processing methods mentioned in the discussions did not lead to a score increase (e.g., `-textiles —> kutānum textiles`, etc.).\n- **Inference Chunking**: To prevent exceeding the ByT5-base capacity, two chunking methods were considered: splitting by keywords (as seen in public code) and splitting by token counts at spaces. I ultimately chose the latter.\n\n## 3. Data Engineering (Powered by Gemini-3.0-flash-preview)\nGemini-3.0-flash-preview was used for splitting, correction, pseudo-labeling, and PDF identification.\n\n### A. Training Set Optimization (1,500 → 8,000 samples)\nUsed Gemini-3.0-flash-preview to split `train.csv` to avoid the 512-token input limit for the prefix + transliteration.\n- **SYSTEM_PROMPT**: Used for samples requiring splitting (script determined by tokens ≥ 400). A single request handled: Splitting + Alignment Check + Noise Trimming.\n- **SYSTEM_PROMPT_TRIM**: Used for samples not requiring splitting. A single request handled: Alignment Check + Noise Trimming.\n- **Alignment Strategy**: Source and translation must semantically correspond segment-by-segment. If the translation contained parts not in the source (or vice versa), only corresponding parts were kept, and explicitly redundant parts were deleted.\n- **Core Rule**: \"Only delete, never add\" to ensure data remains authentic.\n- **Action Labeling**: Gemini was required to output an `action` label for each entry:\n  - `keep`: Kept in original form, no deletions made.\n  - `trim`: Deleted a part (trimmed redundant or non-corresponding content).\n  - `delete`: Entire entry invalid or unable to align, suggested for discard (source and translation do not correspond at all).\n- **Format**: JSON output.\n\n### B. Publication Data (~56,000 samples)\n1. **Pseudo-labels (16,000 samples)**:\n   Pseudo-labels were generated twice for publication transliteration text. Since Gemini has poor handling of specific proper nouns (people, places, gods, and especially diacritics), I built a correction pipeline:\n   - **Blacklist**: Established a \"non-proper noun\" blacklist to exclude common vocabulary and prevent semantic issues.\n   - **Lexicon Extraction**: Used `OA_Lexicon_eBL.csv`, `onomasticon.csv`, and `train.csv` to extract transliteration-to-replacement pairs.\n   - **Frequency Filtering**: Scanned `train.csv`; if a transliteration had multiple translation variants, only the most frequent one appearing in `train.csv` was used.\n   - **Noise Control**: Manually corrected common vocabulary that leaked into the mapping. These words often appear in the data and lead to significant noise.\n   - **Implementation**: These proper noun mappings were provided as notes to Gemini during pseudo-labeling.\n2. **publication.csv Content (40,000 samples)**:\n   Due to inaccurate transliterations in `publication.csv`, the same proper noun correction method was applied. Gemini was used to extract paragraphs containing both source and translation.\n\n### C. Final Cleaning\nDue to model instability, I performed a final cleanup of erroneous samples, including empty values and samples where the source was more than twice as long as the translation (source is usually shorter than translation).\n- **Total Samples**: ~8,000 (Split Train) + ~16,000 (Pseudo-labels) + ~40,000 (Publication Content) = **~64,000 samples**.\n\n## 4. Training Details\n- **Epochs**: 15 (Best checkpoint usually around Epoch 10).\n- **Optimizer**: AdamW (Found to be more effective than Adafactor, despite the latter being faster and more memory-efficient).\n- **Precision**: **FP32** (Used to prevent NaN values).\n- **Hyperparameters**: LR 2e-4, Batch Size 4, Gradient Accumulation 16, Max Length 512.\n- **Observation**: Pre-training on large data followed by fine-tuning on `train.csv` was effective for scores below 35. However, after exceeding 36, fine-tuning on `train.csv` caused a drop in LB score. I switched to training on the mixed dataset directly.\n- **Training Time**: ~10-12 hours with `group_by_length` enabled.\n\n## 5. Inference & Ensemble\n- **Inference**: Long and short texts were separated for different inference logic using chunking.\n- **Ensemble Strategy**: \n  - Combined two high-score models (>37) with two lower-score models (<36.5) trained on different data ranges.\n  - **Weighting**: (High-Score * 0.8) + (Low-Score * 0.2) to form two model pairs (a and b).\n  - **MBR Decoding**: Minimum Bayes Risk (MBR) was performed on these pairs using **chrF++** as the similarity metric.\n  - **Settings**: `num_beam_cands = 4`, `num_beams = 8`.\n\n## 6. What Worked vs. What Didn’t\n- **Effective (but not in final sub)**:\n  - **Test Time Training (TTT)**: Improved single-model scores, but wasn't included in the final submission due to deadline. Effective TTT requires Adafactor, BF16, and dynamic padding for efficiency.\n- **Ineffective Attempts**:\n  - Certain post-processing rules (logically sound but didn't work in practice).\n  - **Reinforcement Learning (DPO)**: Likely failed due to training methods or data issues. While I had enough pseudo-labels, high-quality \"real\" label data may have been insufficient.\n\n## 7. Future Directions\n- **Chunking Optimization**: I believe a dedicated model could be trained specifically to perform chunking for Akkadian text.\n\n## 8.About Code\n* Our Ensemble method based on the [public code](https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline) (but with models are own.) \n* The Model Training strategy has been mentioned above.",
      "votes": null
    },
    {
      "id": "3427538",
      "postDate": "03/24/2026 08:02:06",
      "content": "<p>great, wonderful approach , can you share your training code</p>",
      "rawMarkdown": "great, wonderful approach , can you share your training code",
      "votes": null
    },
    {
      "id": "3427582",
      "postDate": "03/24/2026 09:11:10",
      "content": "<p>My training code is similar to the public DPC Starter Train; the differences are minimal, as the primary focus was on the data.</p>",
      "rawMarkdown": "My training code is similar to the public DPC Starter Train; the differences are minimal, as the primary focus was on the data.",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 3427538,
      "author_name": "nacefmbarek",
      "author_url": "",
      "post_date": "03/24/2026 08:02:06",
      "content": "<p>great, wonderful approach , can you share your training code</p>",
      "votes": null,
      "replies": [
        {
          "id": 3427582,
          "author_name": "colhomy",
          "author_url": "",
          "post_date": "03/24/2026 09:11:10",
          "content": "<p>My training code is similar to the public DPC Starter Train; the differences are minimal, as the primary focus was on the data.</p>",
          "votes": null,
          "replies": []
        }
      ]
    }
  ],
  "raw_markdown_by_id": {
    "3427406": "## 0.Preface\nFirst and foremost, I would like to express my gratitude to the organizers for hosting this excellent Akkadian translation competition (even though we encountered—and subsequently resolved—various challenges throughout the event). Despite these hurdles, it remained a truly remarkable contest !\n\n I would like to give special thanks to one of my teammates, @colhomy , who invested a tremendous amount of effort into training the models and cleaning the data during the competition. I also wish to thank my other teammates for the diverse ideas and approaches they contributed during the early stages of the competition, which were instrumental in helping us achieve such a successful result. \nAt the end of, I would like to thank @giovannyrodrguez 's [code](https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline). his code provides a robust ensemble method.\n\n## 1. Overview\n- **Model**: ByT5-base only (Prefix: `\"translate Akkadian to English: \"`)\n- **Hardware**: Single RTX 4090\n- **Key Strategy**: For me, the only reliable way to consistently improve the score in this competition was increasing the data volume.\n\n## 2. Pre-processing & Post-processing\n- **Handling**: Processed based on discussion information, similar to public code but with key differences.\n- **Preprocessing Details**: I used full `<gap>` and decimal processing in the preprocessing stage, whereas some public code versions put these steps in post-processing.\n- **Decimal Normalization**: In addition to converting decimals into the `⅚` form, I also handled the `5/6` forms in the data, processing both decimal and `5/6` formats into the `⅚` form.\n- **Official Suggestions**: Several official processing methods mentioned in the discussions did not lead to a score increase (e.g., `-textiles —> kutānum textiles`, etc.).\n- **Inference Chunking**: To prevent exceeding the ByT5-base capacity, two chunking methods were considered: splitting by keywords (as seen in public code) and splitting by token counts at spaces. I ultimately chose the latter.\n\n## 3. Data Engineering (Powered by Gemini-3.0-flash-preview)\nGemini-3.0-flash-preview was used for splitting, correction, pseudo-labeling, and PDF identification.\n\n### A. Training Set Optimization (1,500 → 8,000 samples)\nUsed Gemini-3.0-flash-preview to split `train.csv` to avoid the 512-token input limit for the prefix + transliteration.\n- **SYSTEM_PROMPT**: Used for samples requiring splitting (script determined by tokens ≥ 400). A single request handled: Splitting + Alignment Check + Noise Trimming.\n- **SYSTEM_PROMPT_TRIM**: Used for samples not requiring splitting. A single request handled: Alignment Check + Noise Trimming.\n- **Alignment Strategy**: Source and translation must semantically correspond segment-by-segment. If the translation contained parts not in the source (or vice versa), only corresponding parts were kept, and explicitly redundant parts were deleted.\n- **Core Rule**: \"Only delete, never add\" to ensure data remains authentic.\n- **Action Labeling**: Gemini was required to output an `action` label for each entry:\n  - `keep`: Kept in original form, no deletions made.\n  - `trim`: Deleted a part (trimmed redundant or non-corresponding content).\n  - `delete`: Entire entry invalid or unable to align, suggested for discard (source and translation do not correspond at all).\n- **Format**: JSON output.\n\n### B. Publication Data (~56,000 samples)\n1. **Pseudo-labels (16,000 samples)**:\n   Pseudo-labels were generated twice for publication transliteration text. Since Gemini has poor handling of specific proper nouns (people, places, gods, and especially diacritics), I built a correction pipeline:\n   - **Blacklist**: Established a \"non-proper noun\" blacklist to exclude common vocabulary and prevent semantic issues.\n   - **Lexicon Extraction**: Used `OA_Lexicon_eBL.csv`, `onomasticon.csv`, and `train.csv` to extract transliteration-to-replacement pairs.\n   - **Frequency Filtering**: Scanned `train.csv`; if a transliteration had multiple translation variants, only the most frequent one appearing in `train.csv` was used.\n   - **Noise Control**: Manually corrected common vocabulary that leaked into the mapping. These words often appear in the data and lead to significant noise.\n   - **Implementation**: These proper noun mappings were provided as notes to Gemini during pseudo-labeling.\n2. **publication.csv Content (40,000 samples)**:\n   Due to inaccurate transliterations in `publication.csv`, the same proper noun correction method was applied. Gemini was used to extract paragraphs containing both source and translation.\n\n### C. Final Cleaning\nDue to model instability, I performed a final cleanup of erroneous samples, including empty values and samples where the source was more than twice as long as the translation (source is usually shorter than translation).\n- **Total Samples**: ~8,000 (Split Train) + ~16,000 (Pseudo-labels) + ~40,000 (Publication Content) = **~64,000 samples**.\n\n## 4. Training Details\n- **Epochs**: 15 (Best checkpoint usually around Epoch 10).\n- **Optimizer**: AdamW (Found to be more effective than Adafactor, despite the latter being faster and more memory-efficient).\n- **Precision**: **FP32** (Used to prevent NaN values).\n- **Hyperparameters**: LR 2e-4, Batch Size 4, Gradient Accumulation 16, Max Length 512.\n- **Observation**: Pre-training on large data followed by fine-tuning on `train.csv` was effective for scores below 35. However, after exceeding 36, fine-tuning on `train.csv` caused a drop in LB score. I switched to training on the mixed dataset directly.\n- **Training Time**: ~10-12 hours with `group_by_length` enabled.\n\n## 5. Inference & Ensemble\n- **Inference**: Long and short texts were separated for different inference logic using chunking.\n- **Ensemble Strategy**: \n  - Combined two high-score models (>37) with two lower-score models (<36.5) trained on different data ranges.\n  - **Weighting**: (High-Score * 0.8) + (Low-Score * 0.2) to form two model pairs (a and b).\n  - **MBR Decoding**: Minimum Bayes Risk (MBR) was performed on these pairs using **chrF++** as the similarity metric.\n  - **Settings**: `num_beam_cands = 4`, `num_beams = 8`.\n\n## 6. What Worked vs. What Didn’t\n- **Effective (but not in final sub)**:\n  - **Test Time Training (TTT)**: Improved single-model scores, but wasn't included in the final submission due to deadline. Effective TTT requires Adafactor, BF16, and dynamic padding for efficiency.\n- **Ineffective Attempts**:\n  - Certain post-processing rules (logically sound but didn't work in practice).\n  - **Reinforcement Learning (DPO)**: Likely failed due to training methods or data issues. While I had enough pseudo-labels, high-quality \"real\" label data may have been insufficient.\n\n## 7. Future Directions\n- **Chunking Optimization**: I believe a dedicated model could be trained specifically to perform chunking for Akkadian text.\n\n## 8.About Code\n* Our Ensemble method based on the [public code](https://www.kaggle.com/code/giovannyrodrguez/lb-35-9-ensembling-post-processing-baseline) (but with models are own.) \n* The Model Training strategy has been mentioned above.",
    "3427538": "great, wonderful approach , can you share your training code",
    "3427582": "My training code is similar to the public DPC Starter Train; the differences are minimal, as the primary focus was on the data."
  },
  "source": "existing_discussion",
  "complete": true,
  "competition_id": 121150,
  "competition_slug": "deep-past-initiative-machine-translation",
  "team_id": 15026559,
  "solution_url": "/competitions/deep-past-initiative-machine-translation/writeups/27th-solution-byt5-base-gemini-3-0-ensembl"
}