neavo
neavo
> > LLM 并不是特别擅长处理精确的数字，所以最好还是跑完以后再手工或者通过脚本对翻译结果进行后处理 > > 用se倒是可以强行截断对应字数，出现说一半没了的情况。就是大多数行都得重新整理语句手打才行。主要是bin文本，不破解程序只能是做截断了，不知道目前遇到这个情况一般是怎么做？ 看游戏引擎是否支持译文比原文行数更多，支持就很简单，在合适的位置插入一个换行就可以了，不支持那就只能重新润色了 数量多的话可以先把这部分文本找出来，然后再让 AI 帮你保持原意的情况下重新精简润色，然后再想办法塞回去
下个版本加个开关
已完成 [MANUAL_BUILD_v0.28.2](https://github.com/neavo/LinguaGacha/releases/tag/MANUAL_BUILD_v0.28.2)
试一下： ```yaml packing: True ``` 这似乎是一个BUG，如果不开启 packing，多少显存都会用完 可能还跟其他的参数有关
> 感觉是你的样本长度不均匀，你可以看看是不是有某些训练样本是超长的 不是这个问题，应该是BUG，理由： 1、最长的条目也不过700t出头 2、加载数据是随机的，但是每次启动大概都在10多步的时候爆显存，是相对固定的 3、在不补齐的时候，1bs也会爆，直接按768（超过最长的条目）补齐的话，4bs显存还有剩余
> 700t > > > > 感觉是你的样本长度不均匀，你可以看看是不是有某些训练样本是超长的 > > > > > > 不是这个问题，应该是BUG，理由： 1、最长的条目也不过700t出头 2、加载数据是随机的，但是每次启动大概都在10多步的时候爆显存，是相对固定的 3、在不补齐的时候，1bs也会爆，直接按768（超过最长的条目）补齐的话，4bs显存还有剩余 > > 700t是指？印象中pack是按max len补齐后截断的，非pack是直接按max len截断的，好像没有单独控制pack长度的参数？ 700 token，cut off len 只要长度比最长的语料还长，那么就只会补齐不会截断了吧，我没看源码，不过我猜应该跟tfr原始的接口是一样的
这里关键的问题在于也有很多用户是用来分析游戏文本的，游戏文本多个文件加起来才是一个项目，得一起分析 而目前 `KG` 是一个命令行应用，在 UI 交互上给用户提醒的能力是很弱的 这种已经是固有习惯的逻辑如果要进行调整或者设置的话，很难让用户知道其中的变化 如果哪天要给 `KG` 做GUI了，可能会提供一个切换 （会做吗 x
Python2 2020年就停止维护了，使用一个 “已死” 的系统有什么好处吗？ 归根结底，造成这种问题的根本原因就是不跟着每个小版本更新 积少成多以后，发现跨越N个版本更新维护成本太高，索性摆烂不维护了 你可以说 “因为历史遗留原因迫不得以只能继续使用Python2”，但是不应该说 Python2 就是 “最合适的” 永远跟着跟随组件的版本更新，才是维护成本最低的方式 笑死
> Contributor 我说的就是 Python2 呀，你也承认 Python2 已死对不对 那趁着周边系统对它的支持还没停止，还没完全死透，趁早迁移，有什么问题吗 能用就行这种形态不是技术人员应该有的，使用新版不需要什么理由，停留在旧版才需要 “特殊的理由” 你停留在旧版的理由是什么？