看到 @Summer最聪明 医生这条被 ChatGPT-4o 坑的微博，尝试从技术角度解读一下，这样也许能更好的理解现阶段大语言模型的优缺点，在实际应用中能扬长避短。
首先回顾一下原博文中的用法，以保证我们讨论的是一件事，避免因为我的误解而错误解读。
“病人连续5天的化验结果，24页PDF发送给 ChatGPT，让其抓取4个指标（白细胞、中性粒细胞、血红蛋白、C反应蛋白），按照时间顺序排列”
结果：“抓取缺项漏项很多”
然后：“把大量的检验结果生成成文字，然后复制给GPT，再让它抓取”
结果：“它不仅会无中生有，还会误判时间，漏掉最低值和最高值，把有些值乱放。”
这个结果确实不尽人意，然而对于现阶段的大模型来说，也不奇怪，这里面涉及几个大模型的短板：
1. 上下文窗口长度不够长
2. 纯文本难以表达和解析结构化的数据
3. 推理能力较弱，需要通过 Prompt 引导
首先说上下文窗口长度不够的问题
每一次和 LLM 的交互，输入和输出的长度是有限制的，以 ChatGPT-4o 为例，上限是 32K Tokens，也就是输入和输出加起来大约是 2 万左右的汉字或英文单词，大约 50 页。看起来还不少，但是每次交互的上下文内容越多，生成质量会下降，成本也会急剧上升。就好比我们做阅读理解，一次阅读一小段文章和几页文章的效果是完全不一样的。
所以当你一次给 GPT 24页的PDF，并希望快速得到你想要的内容，这很可能超出了上下文窗口长度，或者说过长影响了生成效果。如果能减少输入的内容可能会效果更好一些。
然后就是文本格式的问题
现在大语言模型主要是以文本信息为主，像 GPT-4o 属于多模态，也就是还能支持图片、视频和音频。但是对于一些复杂的格式，比如图表、表格可能就效果没那么好了。
如果用户输入的是 PDF，那么通常会将 PDF 转换成纯文本，然后再进一步和大语言模型交互，这就意味着像化验结果这种包含图表、表格的数据，在转换成纯文本的过程中，会丢失很多有效信息，最终会影响生成结果。
即使后来通过复制粘贴再次输入，对于表格这样的数据，在复制粘贴的过程中，一样会丢失掉其格式，而一旦失去行列关系，大语言模型是很难从中解析出来有效的信息。
目前大语言模型有几种方案可以比较好的表达结构化的数据：
1. Markdown，Markdown可以表达表格格式
2. JSON，JSON支持数组、对象等复杂格式的表达
3. XML，XML类似于JSON，也能表达复杂的数据结构，只是冗余较多
4. 其他格式，例如 YAML、HTML、TypeScript 的 Type 等等
通常所有大语言模型对于Markdown都很友好， GPT 对于 JSON 支持更好，而 Claude 对 XML 支持更好
最后就是推理能力
所有复杂的任务都需要一定的推理能力，比如医生交代实习生：“抓取4个指标（白细胞、中性粒细胞、血红蛋白、C反应蛋白），按照时间顺序排列”，实习生会将其拆分成若干个子任务：
1. 找到所有的指标信息
2. 过滤出其中的 4 个指标
3. 对结果排序
但是这个对于大语言模型来说，还很难，哪怕推理能力最强的 GPT-4（依然是比GPT-4o、Claude 3和 Gemini 更强），这任务也不一定能做得很好，但稍弱一些的模型几乎是做不到的。
不过，这类复杂的推理任务，如果借助提示工程，也就是在 Prompt 里面，把要求改一下：
“接下来你按照以下步骤帮我抓取指标信息，并打印每一步结果：
1. 列出所有XXX指标的信息，以Markdown的表格格式显示
2. 仅列出其中 包含白细胞、中性粒细胞、血红蛋白、C反应蛋白 的指标信息，以表格格式显示
3. 对结果按照时间排序“
（根据需要1-2步也可以合并，但是打印第一步可以知道是否第一步就出错了）
这样的话，通常会更容易得到更好的结果，这其实也就是提示工程中的 CoT（思维链），也就是将复杂的任务拆分成一步步来执行。
上面列的三点，主要是从技术的角度来指出了问题，以及可能的改善方法。回头最开始医生使用 AI 来辅助查看报告这个应用场景，如果想能真正有用，有没有方法可以改善呢？
按照我的经验，是有一些事情可以做的，尤其是如果这是高频的应用场景的话，做好了可以极大的提升医生的效率，但需要做的却超出医生的控制范围，因为这可能需要整个医疗 IT 系统的升级。
现阶段的 AI 应用，还远没有达到 AGI （通用人工智能）的程度，需要从整个工作流上来配合，将 AI 作为整个工作流的重要一环，但是上游和下游有其他应用程序的配合。
首先是报告的输出格式，能输出 LLM 友好的格式，比如支持 Markdown 格式，将表格和图表都用 Markdown 通用格式表达，有利于 LLM 解析。
然后就是预先对报告内容分类，以减少上下文窗口大小，比如可以将医生关心的指标信息单独提取成 Markdown 表格，就不需要 LLM 大海捞针一样从整个报告去提取
再有就是对于 LLM 返回的格式可以有程序二次处理，比如说如果数据很多，让大语言排序其实是做不到的，但是结构化的数据让程序排序，反而很简单。
最后再总结以下：
LLM 擅长处理和生成文本，但是受限于上下文窗口长度，并且对于复杂的数据格式，需要用格式化的数据格式表达，并且要借助提示工程将复杂的任务进行拆解。
如果要用好 LLM，最好是充分利用 LLM 的长处，把一些高频的使用场景，但是原本不适合或者无法自动化的工作流的，借助 LLM 的文本处理能力，变成自动化的工作流。
首先回顾一下原博文中的用法，以保证我们讨论的是一件事，避免因为我的误解而错误解读。
“病人连续5天的化验结果，24页PDF发送给 ChatGPT，让其抓取4个指标（白细胞、中性粒细胞、血红蛋白、C反应蛋白），按照时间顺序排列”
结果：“抓取缺项漏项很多”
然后：“把大量的检验结果生成成文字，然后复制给GPT，再让它抓取”
结果：“它不仅会无中生有，还会误判时间，漏掉最低值和最高值，把有些值乱放。”
这个结果确实不尽人意，然而对于现阶段的大模型来说，也不奇怪，这里面涉及几个大模型的短板：
1. 上下文窗口长度不够长
2. 纯文本难以表达和解析结构化的数据
3. 推理能力较弱，需要通过 Prompt 引导
首先说上下文窗口长度不够的问题
每一次和 LLM 的交互，输入和输出的长度是有限制的，以 ChatGPT-4o 为例，上限是 32K Tokens，也就是输入和输出加起来大约是 2 万左右的汉字或英文单词，大约 50 页。看起来还不少，但是每次交互的上下文内容越多，生成质量会下降，成本也会急剧上升。就好比我们做阅读理解，一次阅读一小段文章和几页文章的效果是完全不一样的。
所以当你一次给 GPT 24页的PDF，并希望快速得到你想要的内容，这很可能超出了上下文窗口长度，或者说过长影响了生成效果。如果能减少输入的内容可能会效果更好一些。
然后就是文本格式的问题
现在大语言模型主要是以文本信息为主，像 GPT-4o 属于多模态，也就是还能支持图片、视频和音频。但是对于一些复杂的格式，比如图表、表格可能就效果没那么好了。
如果用户输入的是 PDF，那么通常会将 PDF 转换成纯文本，然后再进一步和大语言模型交互，这就意味着像化验结果这种包含图表、表格的数据，在转换成纯文本的过程中，会丢失很多有效信息，最终会影响生成结果。
即使后来通过复制粘贴再次输入，对于表格这样的数据，在复制粘贴的过程中，一样会丢失掉其格式，而一旦失去行列关系，大语言模型是很难从中解析出来有效的信息。
目前大语言模型有几种方案可以比较好的表达结构化的数据：
1. Markdown，Markdown可以表达表格格式
2. JSON，JSON支持数组、对象等复杂格式的表达
3. XML，XML类似于JSON，也能表达复杂的数据结构，只是冗余较多
4. 其他格式，例如 YAML、HTML、TypeScript 的 Type 等等
通常所有大语言模型对于Markdown都很友好， GPT 对于 JSON 支持更好，而 Claude 对 XML 支持更好
最后就是推理能力
所有复杂的任务都需要一定的推理能力，比如医生交代实习生：“抓取4个指标（白细胞、中性粒细胞、血红蛋白、C反应蛋白），按照时间顺序排列”，实习生会将其拆分成若干个子任务：
1. 找到所有的指标信息
2. 过滤出其中的 4 个指标
3. 对结果排序
但是这个对于大语言模型来说，还很难，哪怕推理能力最强的 GPT-4（依然是比GPT-4o、Claude 3和 Gemini 更强），这任务也不一定能做得很好，但稍弱一些的模型几乎是做不到的。
不过，这类复杂的推理任务，如果借助提示工程，也就是在 Prompt 里面，把要求改一下：
“接下来你按照以下步骤帮我抓取指标信息，并打印每一步结果：
1. 列出所有XXX指标的信息，以Markdown的表格格式显示
2. 仅列出其中 包含白细胞、中性粒细胞、血红蛋白、C反应蛋白 的指标信息，以表格格式显示
3. 对结果按照时间排序“
（根据需要1-2步也可以合并，但是打印第一步可以知道是否第一步就出错了）
这样的话，通常会更容易得到更好的结果，这其实也就是提示工程中的 CoT（思维链），也就是将复杂的任务拆分成一步步来执行。
上面列的三点，主要是从技术的角度来指出了问题，以及可能的改善方法。回头最开始医生使用 AI 来辅助查看报告这个应用场景，如果想能真正有用，有没有方法可以改善呢？
按照我的经验，是有一些事情可以做的，尤其是如果这是高频的应用场景的话，做好了可以极大的提升医生的效率，但需要做的却超出医生的控制范围，因为这可能需要整个医疗 IT 系统的升级。
现阶段的 AI 应用，还远没有达到 AGI （通用人工智能）的程度，需要从整个工作流上来配合，将 AI 作为整个工作流的重要一环，但是上游和下游有其他应用程序的配合。
首先是报告的输出格式，能输出 LLM 友好的格式，比如支持 Markdown 格式，将表格和图表都用 Markdown 通用格式表达，有利于 LLM 解析。
然后就是预先对报告内容分类，以减少上下文窗口大小，比如可以将医生关心的指标信息单独提取成 Markdown 表格，就不需要 LLM 大海捞针一样从整个报告去提取
再有就是对于 LLM 返回的格式可以有程序二次处理，比如说如果数据很多，让大语言排序其实是做不到的，但是结构化的数据让程序排序，反而很简单。
最后再总结以下：
LLM 擅长处理和生成文本，但是受限于上下文窗口长度，并且对于复杂的数据格式，需要用格式化的数据格式表达，并且要借助提示工程将复杂的任务进行拆解。
如果要用好 LLM，最好是充分利用 LLM 的长处，把一些高频的使用场景，但是原本不适合或者无法自动化的工作流的，借助 LLM 的文本处理能力，变成自动化的工作流。
