文档问答本质是两种截然不同的机制——全文截断放入上下文窗口,或检索相关段落;前者丢失远程信息,后者依赖检索质量,两者失败模式相反,误判根源是 bug、limit 还是用法错误。
"上传一份文档然后向它提问"描述的是两个完全不同的机制,它们以相反的方式失败。你使用的是哪一种,决定了"它没有找到文件中明确存在的内容"究竟是 bug、局限,还是你的错。
没有任何东西被"学会"。文件没有被添加到模型中,模型不会在明天还记得它,其他用户也无法通过模型访问到它。实际发生的过程更为平淡:文件被转换为纯文本,其中部分文本连同你的问题一起被放到模型面前。模型读取它的方式,和读取你输入的其他任何内容完全一样。
由此立即得出三个后果。格式大多会丢失,所以 PDF 中看起来清晰的表格,到达时可能变成一串没有列对齐的数字。任何原本是图像的内容——扫描件、图表、拍摄的照片——只有在产品先运行字符识别后才能起作用,而这步操作本身也有其自身的错误率。此外,模型一次能处理的文本量存在一个硬上限,这就是所谓的上下文窗口。
每个产品对你的文件做的只有两件事之一,而差异正是问题的全部。
检索失败是让人抓狂的那一种,因为文本明明在文件中可见。系统根本没有看到它。这种情况最常发生在你的问题与文档对同一事物使用了不同词语时:你问的是"员工流失",文档写的是"自然缩减",段落匹配永远无法将它们连接起来。其内部机制与企业搜索产品使用的是同一套,而文档被切分成段落的方式对质量的影响之大,出乎很多人意料。
产品很少会主动说明。两个测试各花一分钟,且每个工具都值得做一次,因为答案会改变你使用它的方式。
针测试。在一份长文档的靠后位置放一个独特的无意义字符串——比如 ZEPHYR-COUNT-7734,单独成段。然后问 ZEPHYR-COUNT-7734 是什么。如果它找到了,说明文档末尾是可达的。再把标记放到中间位置跑一次。
全量测试。问一个需要阅读全部内容才能回答的问题:"'risk'这个词出现了多少次,并按顺序列出所有标题"。全文件型系统做这个还算勉强及格。检索系统则会严重失败,因为任何小的段落集合都无法包含完整答案。如果它给出了一个看似合理但残缺的标题列表,那你用的就是检索系统。
如果你用的是检索系统,就别问那些需要阅读整篇文档才能回答的问题。改问可以定位的问题,而且一次只问一个。
这些问题每个工具值得回答一次,每个类别的文档也值得回答一次,而不是每个文件都答一遍。答案通常在供应商的隐私政策和服务条款里,而不是在营销页面上。
我是否有权发送这些内容? 客户文件、病历、员工数据、任何受保密协议约束的东西、以及任何负有职业保密义务的内容,都不会因为你图方便就变成了可以交给第三方的东西。这是会产生实际职业后果的问题,而且它在技术问题之前就应当被回答。
它是否被用于训练? 消费级产品和商业级产品即使在同一品牌下也常常在这一项上不同。如何读懂回答这个问题的条款。
它被保留多久,我可以删除吗? 不用于训练和不予保留是两个不同的承诺,大多数产品只做到了前者。
我组织中的其他人能看到它吗? 共享工作区有时会让上传的文件对同事可见。这是个功能——直到文件是一封纪律处分信为止。
如果任何一个答案不可接受,解决方案通常是做脱敏处理而不是放弃整个方案。在文字处理器中花两分钟把姓名替换成 PERSON_A 和 PERSON_B,就能消除大部分异议,而且答案可以轻松映射回真实姓名。
这里花五分钟,比任何提示词技巧都值。
优先选择基于文本的文件而不是扫描件。如果能用光标选中文字,那就是文本。如果不能,那就是一张文字的图片,一切都取决于识别质量——而识别质量最差的恰恰是人们最常扫描的那些文档:表格、表格、以及任何带有手写内容的文件。
将超长文档按章节拆分。一份 300 页的手册作为单个文件,强迫工具进入检索模式。同样的手册分成十二个章节文件,你就能直接指向你所说的那个章节,这比任何检索系统都好。
抢救表格。把关键表格复制到电子表格中并单独附加。从 PDF 转换而来的表格是最常见的错误数字来源,因为列边界消失后,数字就会跑到错误的标题下。为什么 PDF 提取至今仍然困难,这是一个真正尚未解决的工程问题,而不是你所用工具的 bug。
保留页码。如果文本中有页码或章节标记,它们会保留到提取结果中,你可以在回答中要求提供它们,这样就可以进行检查了。
这一条单一指令对文档工作的可靠性提升超过其他任何技巧:
Answer using only the attached document.
For every claim, quote the sentence you took it from, in quotation
marks, with its page or section number.
If the document does not answer the question, say "not in the
document" and stop. Do not use general knowledge to fill the gap.
这做了两件事。它让答案可以在几秒内核查——你在文档中搜索引用的句子即可。它还让一种特定的失败变得可见:如果引用的句子不在文件中,你就抓住了一个本会信以为真的虚构内容。找不到出处的引用是所有文档工作中最可靠的警告信号。
一次只问一个问题。一条消息里放六个问题,可靠地得到三个好答案、两个单薄的答案和一个被忽略的答案。批量提问没有任何好处——代价相同,耗时也差不多。
它无法告诉你文件中没有的内容。"这份合同是否包含赔偿条款?"是检索系统无法自信给出否定回答的问题,因为找不到某样东西和它根本不存在从系统内部看起来是完全一样的。对于"是否存在"类问题,需要自己去搜索文本。
它无法可靠地对长文档中的内容进行计数、求和或比较。任何"有多少"、"总和是多少"或"哪个最大"形式的问题,都应该被视为草稿答案并重新计算。对于电子表格中的数字,有一种更好的方法参见"理解电子表格"。
而且它不知道自己拿的是哪个版本。如果你上传的是草案而不是已签名的合同,每条答案都会自信地围绕草案展开。系统中没有任何东西会提到这一点。