JotMe 被选择的理由，说到底就一个字——“准”。每天、每周，总有一些会议，里面的关键信息一个字都不能译错。在会议翻译这样的场景里，这正是许多客户选择 JotMe 的首要原因。

那么，为什么明明都用上了 AI，很多翻译却依然不尽如人意？

这篇文章，我想坦诚地聊一聊：我们究竟是怎么使用你的数据，让翻译真正贴合你的工作场景的。

首先要说清楚一点：如今大多数翻译工具，在语法上其实都能给出正确的译文，并不能说它们“错”。真正的关键在于——同一句话，往往会因为语境不同而有多种译法。当你觉得某个译文“不太对劲”时，原因多半是：AI 并不知道你想表达什么，也不知道听的人已经掌握了哪些信息。

举个例子。假设有这样一句话：

"The model is hallucinating."

如果没有上下文，这里的 model 到底指什么？可能是一位服药后正在产生幻觉的时装模特（模特），也可能是一个正在编造错误信息的 AI 模型（模型）。哪怕译成中文里的“模型”，它本身也还是模糊的——是数学模型、实体模型，还是 AI 模型？

而如果 AI 知道你最近一直在开发 AI 产品、正在讨论新功能，它就能毫不犹豫地选中第二种含义——AI 模型。

这只是一个很简单的例子。当对话越来越复杂、涉及的信息越来越多，这种“语境误判”会变成一个棘手得多的问题。

理解了这一点，我们就进入正题：JotMe 为了交付贴合语境的准确翻译，究竟是怎么使用你的数据的。

JotMe 的翻译分为两种

JotMe 的翻译大致分为两类：

1. 实时翻译：实时字幕，以及语音到语音的翻译
2. 文本翻译：转录文字、文本输入和聊天

两者在“上下文”的构建方式上，略有不同。

实时翻译如何利用你的上下文

在实时翻译中，我们会把下面这些信息当作上下文来使用。

用户画像

从你登录的那一刻起，我们所掌握的关于你的一切信息。为了进一步提升翻译精度，我们的 AI 智能体有时还会去检索网络上关于你的公开信息。

业务上下文

也就是你在工作中“做什么”。它由会议记录、JotMe Chat 的消息、你上传的文件，以及你与 JotMe AI 的互动共同拼接而成。对于符合条件的用户，还可以连接 Gmail、Outlook、Notion、Google Drive 和 Microsoft Teams，从而构建出更丰富的业务上下文。

实时记忆

也就是你在这场会议里正在讨论的内容，会随着对话的推进不断更新。

自定义术语与行话

公司内部用语、行业特有的说法，都可以由你自己添加。对于符合条件的用户，这些术语还能根据业务上下文自动更新。

衔接上一段发言

为了让译文不至于支离破碎，我们会带上前一到两段已翻译的内容。这样一来，整段对话读起来就更自然、更连贯。

文本翻译如何利用你的上下文

文本翻译的思路完全一样。只不过，它不再依赖语音的实时记忆，而是借助对话记忆和过往的聊天消息。

其中，用户画像和业务上下文的构建方式，与实时翻译完全一致。文本翻译特有的部分，主要是下面两点。

对话记忆

也就是你在聊天里正在进行的这段对话，每发送一条消息都会实时更新。

衔接前几条消息

我们会带上前一到两条聊天消息，让翻译后的对话既连贯又自然。和实时翻译一样，自定义术语与行话在这里同样适用。

AI 让翻译更好了，但仍差“最后一步”

AI 确实让翻译质量有了质的飞跃。但坦白讲，还有一道尚未填平的鸿沟。

正如前面所说，同一句话的译法从来不止一种。上下文不够，AI 就无法笃定地判断出说话人的意图，也给不出听者所期待的那个译文。

但这并不意味着“上下文越多越好”。上下文一旦过多，译文质量反而会下降——这种现象通常被称为上下文腐烂（context rot）：信息太杂，模型反而会丢掉那些真正关键的线索。

此外，还有一个速度上的权衡。实时翻译是一套实时系统，塞进的上下文越多，出译文所需的时间就越长。在我们的实测中，甚至出现过等待超过 30 秒才出结果的情况——这在实时对话里根本没法用。

反复试验之后，我们得出的答案是：把延迟控制在大约 1–5 秒。在这个区间里，大多数人会觉得节奏自然，同时又能留出足够的上下文，保证足够高的翻译准确度。

上下文、速度、准确度——如何在这三者之间找到最佳平衡，正是 JotMe 眼下正在攻克的核心研究课题之一。

未来，我们会继续投入，力求做出在真实商业场景中真正好用、尽可能准确的 AI 翻译。

今天就聊到这里，我们下次再见。