Lunatranslator更新了Google lens OCR，效果挺不错的
最新的是5.28版和我之前的5.11版有了不少差别，1 取消了OCR的后处理选项，之前我很喜欢灰度化后过滤亮度过高的背景 2 多了个免配置的Google Lens，在较高频率的2秒一次的请求时候依然能高效返回结果，效果比5.11的本地OCR还好。而5.11的OCR本身就比过去的本地OCR更好。 配合最近的GPT4o mini或者deepseek，已经能非常高速高准确率的实时翻译了。我的设置，OCR引擎是Google Lens。
Chatgpt 4o mini模型，附带上下文数：2，自定义系统prompt：“你将输入的日文翻译成中文，你直接给出结果不要任何解释。该日文可能来自于OCR或者语音识别，因此存在漏字和错误的日文，你要纠正后再翻译。”
顺便说句，麻生华澄的师生恋剧情真好啊，除了不知道男主家长和同学到底会怎么看，小两口倒是把高中生活过成啥师生恋大舞台了。
请教下楼主GPT4o mini和deepseek的翻译能力差距，日语和英语的
现在用deepseek感觉翻译效果已经很不错了，完爆在线翻译和本地部署的小参数模型，如果差距不大就不用gpt了 本帖最后由 泰坦失足 于 2024-12-23 08:57 编辑
浅井惠 发表于 2024-12-23 01:13
请教下楼主GPT4o mini和deepseek的翻译能力差距，日语和英语的
现在用deepseek感觉翻译效果已经很不错了， ...
感觉没啥区别。我一般把上下文数量设为4 max tokens 4096，把过去的上下文添加进去。这样前后人名翻译和背景翻译更连贯。
虽然DeepSeek和4o mini价格差不多，但是DeepSeek的命中缓存时候的输入明显便宜的多。你可以考虑先用DeepSeek的深度思考，输入游戏的英文/日文/中文wiki，让它把游戏的人名/专有名词总结做成一个词典，作为自定义prompt输入，这样不会把同一个人名翻译成不同版本。
注意，只有当两个请求的前缀内容相同时（从第 0 个 token 开始相同），才算重复。中间开始的重复不能被缓存命中。
https://api-docs.deepseek.com/zh-cn/news/news0802
泰坦失足 发表于 2024-12-23 08:50
感觉没啥区别。我一般把上下文数量设为4 max tokens 4096，把过去的上下文添加进去。这样前后人名翻译和背 ...
感谢分享，我用本地模型的时候默认设置一般maxtoken是1024，因为很少有一句话几百个单词的情况，太长容易让意思偏离，倒是上下文为什么只设为4？我一般上下文是4096 浅井惠 发表于 2024-12-23 12:16
感谢分享，我用本地模型的时候默认设置一般maxtoken是1024，因为很少有一句话几百个单词的情况，太长容易 ...
4096个上下文是不是太多了点？那可是4096条过去的输入啊。input中上下文长度也拖慢output译文速度。
数字倒是可以适当提升下，因为OCR如果识别一句话输出到一半时候，会一句话其实占用了多个上下文，把原本上下文中的对话记录挤走 泰坦失足 发表于 2024-12-23 12:21
4096个上下文是不是太多了点？那可是4096条过去的输入啊。input中上下文长度也拖慢output译文速度。
数字 ...
4096的上下文也就是3000个word左右，差不多一个场景对话的数量？
这样可以尽量保证一个场景内的翻译保持连贯
拖慢速度倒还好，实测基本影响不大
本帖最后由 泰坦失足 于 2024-12-23 12:42 编辑
浅井惠 发表于 2024-12-23 12:27
4096的上下文也就是3000个word左右，差不多一个场景对话的数量？
这样可以尽量保证一个场景内的翻译保持 ...
这个指的4096个input吧。最终prompt=system+4096条历史input+当前input，然后按maxtoken进行截断。 泰坦失足 发表于 2024-12-23 12:39
这个指的4096个input吧。最终prompt=system+4096条历史input+当前input，然后按maxtoken进行截断。 ...
上下文长度context length是按token计算的 本帖最后由 泰坦失足 于 2024-12-23 13:15 编辑
浅井惠 发表于 2024-12-23 12:46
上下文长度context length是按token计算的
这怎么看都比4个tokens长吧. 这个“附带上下文个数”选项
你专业的翻译我输入的日文。这些日文来自日本校园背景的恋爱故事情节的视觉小说galgame。因此可能头两个字表示说话人名。同时这些日文来自于OCR，你要考虑到OCR的错误识别和错误断成多行，你要纠正这些OCR导致的错误日文原文，推理出正确的日文后再翻译出对应的中文。你直接给出翻译后的结果，不要其他多余的废话。结果不能是英文，一定要是中文！<|eot_id|><|start_header_id|>user<|end_header_id|>\n\n君がいなくなるって考えるだけで\n涙がふ一出ちゃうんだよ<|eot_id|><|start_header_id|>assistant<|end_header_id|>\n\n光是想象你不在我身边就，眼泪就要流出来了<|eot_id|><|start_header_id|>user<|end_header_id|>\n\n巨題全部回到刀区<|eot_id|><|start_header_id|>assistant<|end_header_id|>\n\n回到开头<|eot_id|><|start_header_id|>user<|end_header_id|>\n\n++ ×\n bash Ihuan139 刀塔的旧刀塔\nFalse, max_tokens-2e48, min_tokens--.\npter_request: None.bash Ihuan139\n以后本区不寸診<|eot_id|><|start_header_id|>assistant<|end_header_id|>\n\n', params: SamplingParams(n=1, presence_penalty=0.0, frequency_penalty=0.0, repetition_penalty=1.0, temperature=0.2, top_p=0.3, top_k=-1, min_p=0.0, seed=None, stop=[], stop_token_ids=[], bad_words=[], include_stop_str_in_output=False, ignore_eos=False, max_tokens=2048, min_tokens=0, logprobs=None, prompt_logprobs=None, skip_special_tokens=True, spaces_between_special_tokens=True, truncate_prompt_tokens=None, guided_decoding=None), prompt_token_ids: None, lora_request: None, prompt_adapter_request: None.
泰坦失足 发表于 2024-12-23 13:10
这怎么看都比4个tokens长吧. 这个“附带上下文个数”选项
你专业的翻译我输入的日文。这些日文来自日本校 ...
上下文长度指的不是一次对话中对所有指令的记忆，而是回答的参考内容，它只影响回答的质量
上下文长度以token计算应该是没什么疑义的
页:
[1]