付费前应该试什么
付费前要试的，是自己工作中的问题。准备 5〜10 个问题，把同样的问题交给 2 个模型，按定好的维度评分。最后，把结果与用途页面上的评价对照。如果只想看看最初的感觉，3〜5 个也可以，但要决定付费给谁，就要用 5〜10 个，以免被偶然的差距左右。
公开的评价汇总的是别人的问题或共同题目上的结果。在自己工作的文章和措辞上表现如何，从中无法完全读出。即使只有几个问题，只要有自己试过的结果，就能把评价的数字套用到自己的工作上来解读。
试用的对象缩小到 2 个。一次比较 3 个以上，评分的工作量会增加，差别也难记住。先在用途页面看评价和价格，选出犹豫中的 2 个再开始。
从自己的工作中选出 5〜10 个问题
问题要从平时工作中真正想交给它做的事情里选。把简单的和难的混在一起，并选自己能确认答案是否正确的。因为不知道是否正确的问题，无法决定哪边更好。
- 短的问题和让它读长资料的请求都要放进去
- 至少放 1 篇敬语和措辞很重要的日语文章
- 放 1 个过去没做好的请求
例如销售工作，问题会是“从这份会议记录中提取接下来要做的 3 件事”“写一封礼貌的邮件，告知客户交货延迟”“确认这份报价的合计是否正确”这样的。每一个都能由自己判断回答好不好。
问题的文本 (提示词) 写好后就不要改。改了措辞，就分不清回答的差别是模型的差别还是文本的差别。好回答的条件，也要在试用前用 1〜2 行写下来。看了回答之后再定条件，会被先读到的回答牵着走。
把同样的问题交给 2 个模型
交给 2 个模型的问题要一字不差。每个问题都开启新的对话，不让前一个问题的来往混进回答里。有些应用记住以往对话的功能会影响回答，试用期间最好关掉。
用 API (从程序使用 LLM 的接口) 试用时，可以写系统提示词 (放在对话之前的指令)。2 个模型要用同样的内容，或者两边都留空。只给一边写指令，比较的条件就不一致。
评分时要隐去名称。把回答贴到另一份文档里，打乱顺序到看不出哪个是哪个模型后再读。Arena 的人类评价也是隐去名称收集的，截至 2026 年 10 月，还提供了自己选 2 个模型并排比较的用法。打乱顺序时，交换电子表格的列，或者请别人给回答编上记号，会比较快。
按正确性、是否按指令、日语和速度评分
评分的维度有以下 4 个。每个维度都用 0〜2 分这样的小分值打分，并附上一句打分的理由。
- 正确性：事实和计算有没有错误
- 是否按指令：是否遵守了长度、形式和禁止事项
- 日语是否自然：敬语和措辞有没有别扭的地方
- 速度：等回答全部出来的时间能否接受
例如让它写道歉邮件的回答，日期和金额的错误看正确性，是否遵守了字数要求看是否按指令。过于谦卑或不自然的敬语，看日语是否自然。不把同一个缺点算进 2 个维度，分数的合计就不会偏。
在正确性上输了的模型，即使在其他维度上赢了也不选，这是基本原则。有错误的回答，修改的精力会超过易读带来的好处。速度在用于对话时起作用，但在批量处理的工作中作用不大。要根据用途，先定好看重哪个维度。
免费试用的条件要在各公司的价格页面确认
可以免费试用的范围和次数上限由开发方调整。不要记数字，试用前到各公司的价格页面确认。应用的月费和 API 每 100 万 token 的价格是两回事，所以打算用哪种方式，要看的页面也不同。token 是把文本细分后的单位。
在免费额度中，输入内容的处理方式有时与付费额度不同。截至 2026 年 10 月，Google 在价格页面上写明，Gemini API 的免费额度会把输入的内容用于改进产品，付费额度则不用。不能对外公开的文本，不要在免费额度中试。试用的问题要改写成被人看到也无妨的形式。
处理方式取决于服务和合同的形式。拿不准时，先阅读所用服务的使用条款或数据处理页面再输入。
总结 - 把结果与页面上的评价对照
如果自己的评分与页面上的评价方向一致，就可以认为该评价也适用于自己的工作。如果方向相反，在自己的工作中就优先采用自己的结果。不过只有 5〜10 个问题时，1〜2 题的差距也可能是偶然造成的。差距小时，选便宜的或用惯了的就好。
用过的问题和评分表要保留下来。表中每行写上问题、2 个回答的分数和注意到的事就够了。推出新版本时或考虑更换时，用同样的问题重新并排，就能在短时间内比较。如果看重日语的表现，就把用于日语的页面的评价和自己的评分并排确认。