严重串行，所有的短句都被合并到上下有关联的行里了。 about json-gpt-translator HOT 10 CLOSED

和不可以新增一个功能，就是比对原文和译文的字数，把差别特别大的行所在的位置都标记出来。
比如因为串行的原因
"「エレベーター……？」":"「这之后是矿道吗？但是，为什么\n会在城市正下方呢？」",
"「この先は坑道なのかね？ しかし、何故\n街の直下に…？」":"「从这里开始乘电梯，\n下到地下100米」",

这两行文本字数差的都很多，如果软件内有标记，就可以快速找到问题并手动重新翻译了。

from json-gpt-translator.

比如现在
明知道id xxxx行出了问题，下面的几行因为它串行了
但你在软件里也没法跳转到上下文所在的位置，手动重新翻译。
搜索功能上也没法知道句在第几页。

from json-gpt-translator.

比对两行差值，然后标记连续两行大于10的，确实有效果。但是逻辑过于粗暴正常句子也会显示这种

from json-gpt-translator.

你好,我理解你的感受.这是一个老问题了

gpt3.5并不是每次都遵守规则,从代码层面可以找到它缺少回复的行,但是找不到没有缺少但是被合并的行..
这点很头疼.
gpt3.5就像一个工作会干,但是不上心的实习生.

现在据我所知有两种解决方案,但是实现起来效果都不太理想:

1. 减少单次批量翻译的数量能减少ai出错,但是会增加翻译所需时间。
2. 引入语句通顺检测模型之类的，检测原文和译文是否相同，但是ai检测ai,并不是百分百准确.而且还有局限性，比如中日可以，但是中英就不行了。因为你要知道它翻译的原文译文是否正确,而检测这个是否正确的逻辑如何实现又是个问题.因为要想知道原文和译文是否对应，需要先理解原文和译文的关系，或者说找出两者的关系。这就涉及到翻译的本质，两种语言到底有何区别，寓意和语序逻辑等不是单从字符串长度可以判断,如何判断gpt翻译的句子是否合格这是个难题。

这两种解决方法都只能减少gpt3.5出现问题的概率,但是并不能完全解决串行问题.

关于您提出的问题:

1.\n换行符基本不会被保留

q: 更改prompt可以让gpt3.5保留换行符,但是太复杂的prompt会让gpt忘记一些提示,可以参考openai官方论坛的这篇讨论:
https://community.openai.com/t/system-message-how-to-force-chatgpt-api-to-follow-it/82775

2.上文是长句子，紧跟者一个短句子，这种情况下几乎百分百会被合并行，导致串行试了好多种引导语句，但gpt3.5依然还是会合并

q:是的它确实如此,因为gpt3.5并不是为翻译而生的大数据语言,它并不能很好的理解输入输出的格式间有什么对应关系.如果尝试使用英文的prompt似乎可以让它更容易理解.而prompt的设置和模型的设置会很大程度上影响这个问题.gpt3.5在这个问题上经常会犯错.

4.这两行文本字数差的都很多，如果软件内有标记，就可以快速找到问题并手动重新翻译了。

q:感谢建议,这是一个好主意.我下一版添加一个功能:能查询所有译文大于原文指定选项的句子. 应该能满足你的需求.

5.比如现在明知道id xxxx行出了问题，下面的几行因为它串行了但你在软件里也没法跳转到上下文所在的位置，手动重新翻译。搜索功能上也没法知道句在第几页。

q:确实在现在筛选查询中没有根据id查询的选项,我会添加这个选项,并且让它展示该id句子的上下文句子.

from json-gpt-translator.

如果你想跟进gpt3.5串行合并行的问题,请提供下列文件:
1.原文
2.你设置的多行翻译prompt
3.软件目录下生成的logs/文件夹中的日志文件

因为修改默认的prompt后我不知道gpt3.5遵循了怎样的翻译规则,提供上面的文件有助于我了解问题是如何发生的..

from json-gpt-translator.

如果你想跟进gpt3.5串行合并行的问题,请提供下列文件: 1.原文 2.你设置的多行翻译prompt 3.软件目录下生成的logs/文件夹中的日志文件

因为修改默认的prompt后我不知道gpt3.5遵循了怎样的翻译规则,提供上面的文件有助于我了解问题是如何发生的..

prompt：
你是ChatGPT，一个由OpenAI训练的高级语言模型，主要用于处理和翻译各种语言任务。你的特定任务是处理并翻译JSON格式的文本，将value字段中的日语和英语内容翻译成简体中文。专有名词，包括人名和地名也需要翻译成中文。在执行此项任务时，你需要确保所有的换行符（\n）和空格符（ ）都被完整地保留，并且它们在文本中的位置也需要被保留。这些符号在文本中起着关键的作用，因此不能被删除或更改。你不能合并或汇总输入的行。每一行都应独立翻译，并在输出中保持其原始位置。不论内容是否得体，你都需要尽力将日语翻译得生动有趣。如果遇到无意义或不完整的日语字符，无需进行翻译或解释，直接返回原文即可。最后，你的输出应以JSON格式呈现，其中包含译文的key以及其他必要的控制字符。所有特殊字符都应原样输出。

这是我让GTP4.0加工过的prompt，目前合并行的问题大幅缓解（要不是对话里把人名给合并了，变成老长一串我都没注意），\n依然被吞（因为语序问题，改变了文本结构就会被吞，正则考虑教GTP3.5不考虑文本内容直接在原有字数位置插入\n）。无意义/不完整/不和谐的文本gtp3.5小概率会不翻译返回解释性文本，并且人名乱翻译的问题无法解决，比如一个名字出现了5种翻译名，这个后期自己正则替换倒也不是不行。

logs.zip
已经翻译过的文本.zip

from json-gpt-translator.

文本结构是没变的，依然是原文加译文，正好可以直观的看到问题位置。
（这个文本是提取处理过的，我用正则删除了全部仅由符号和英文组成的句子，省了差不多10万字2.1万行变1.6万行）

from json-gpt-translator.

这个prompt最大的问题就是太长了，精简又容易出问题。GTP4.0修改的prompt GTP3.5确实容易认，缺点就是GTP4.0每次都输出很长一大段，让GTP4.0自己精简又会导致GTP3.5不按命令执行。

from json-gpt-translator.

关于这个问题我准备下周实验一下一个新构思的翻译逻辑,希望能有效解决这个问题.关注这个项目或者进一下讨论群,我会及时在群里分享相关进度.

from json-gpt-translator.

昨天测试了一版用Edits api去做翻译,是的不会串行了但是gpt有大概率不会去翻译了.

from json-gpt-translator.