PP-Structure的在提取图片文字转markdown的局限；
之前使用PP-Structure提取pdf文档又快又好，后面也顺势用PP-Structure提取图像的文字，但是出现了ocr能识别到文字，但文字不会转为markdown的问题
为什么用PP-Structure，而不是纯ocr
由于转结构化数据的需求，Markdown格式与ocr提取的纯文本，主要优势体现在以下几个方面：
- 保留语义层级： Markdown 的 # (标题)、- (列表)、** (加粗) 能告诉 LLM 哪些是核心字段，哪些是附属说明。纯 OCR 只是散乱的行，LLM 需要耗费额外的算力去猜测“谁是谁的标题”。
- 表格处理： 这是 Markdown 最大的优势。纯 OCR 识别表格通常会变成一串乱序的数字和文字，LLM 极难还原。而 Markdown 的表格格式（|---|）能完美保留行列关系。
- Token效率： 相比于带坐标的 JSON（纯 OCR 原始输出），Markdown 去掉了冗余的像素位置信息，只保留结构。这能节省 50%-80% 的 Token，同时降低 LLM 的推理成本和幻觉概率。
PP-Structure出现的问题
在结构化模型里，“image”块默认被当作非文本区域处理。
在提取银行卡和身份证时，往往是人手拍图，与pdf文档不同的是：身份证和银行卡会被打上image标签。就会产生以下问题：
- 即使 OCR 模型在图片区域内识别到了文字坐标和内容，也提取不到其中的文字。
- 它担心如果把图里的文字也转成 Markdown，会造成排版混乱（比如流程图、架构图里的文字乱序堆叠）。
Markdown 生成器在处理 image 类型的块时，优先级是保留图像引用，而不是提取其中的文字。
现在的解决方案
由于数据量不大，我现在是直接将图像扔给多模态模型，让多模态模型直接提取结构化数据。
媒体流接口响应体（Response）
现在需要将文本转换为音频，实时播放给前端，响应方式与之前的Web API（JSON 接口）有些不同
- FastAPI 默认的 return JSON 行为（JSONResponse）
把Python对象转成JSON，JSON序列化
设置响应头：Content-Type: application/json - 文件接口响应体（Response）
传统的“全量交付”文件，HTTP需要明确Content-Type。
音频文件是二进制流，尽量不让 FastAPI自动推断，通过以下代码指定：
return Response(content=audio_bytes, media_type="audio/wav") - 媒体流接口响应体（StreamingResponse）
高效的“分块传输”文件。
服务器开启一个迭代器（Generator） 👉 产生一块数据（Chunk） 👉 立即发送给客户端 👉 重复直到结束。
return StreamingResponse(BytesIO(audio_bytes),media_type="audio/wav")
内存占用极低。无论文件多大，服务器内存里通常只存当前发送的那一小块数据。
会议内容实时转文字中说话人分离（Diarization）
今天准备部署一个能让说话人分离的模型，发现funasr框架中本身就支持说话人分离，于是开始学习
从funasr文档中得知，cam ++（Diarization）模型使用非常简单，
model = AutoModel(model="paraformer-zh",punc_model="ct-punc", spk_model="cam++" 👈说话人分离模型)
阅读funasr得知，通常模型输入限制时长30s以下，组合vad_model后，才能支持任意时长音频输入，所以这个会议记录场景中vad模型是必须的。
以上暂时是初步学习funasr除了语音转文字以外的其他功能。