财报电话会议正在成为观察企业 AI 落地进度的窗口。管理层在电话会议里怎么提 AI、把 AI 和成本、效率、收入放在什么语境下讨论往往比一页漂亮的战略 PPT 更能看出真实状态。这篇博客把“AI and Productivity: What Firms Are Saying on Earnings Calls”这个主题拆成一个可复用的分析流程从会议记录获取、AI 关键词抽取、生产力信号分句到指标设计、批量处理和结果验证。内容不是某一期财报的复述而是一套方法论。你可以拿它去分析任意一个行业、任意一家公司的公开会议记录也可以把它改造成内部项目追踪工具定期观察自家产品发布后对外沟通中 AI 信号的变化。适合做产业研究、行业趋势分析、AI 产品商业化观察或是想在内部跟踪 AI 项目 ROI 的团队参考。下面直接给规格、给流程、给代码最后给常见坑。1. 核心分析能力速览先说明这套分析流程解决什么问题。企业财报电话会议里的文本属于长文档、口语化、数字密集、高噪音直接统计“AI”出现次数只能得到表面信号真正有价值的是AI 出现在什么语境、与哪些业务指标挂钩、是否转化成生产力表达。能力项说明数据来源公开财报电话会议转写文本、IR 页面、公开事件摘要核心功能AI 关键词抽取、语义分句、生产力信号分类、情绪/时态分析、多文档对比输入格式PDF、TXT、SRT、JSON 文本记录语言支持中英文会议记录均可英文效果通常更稳定推荐做法先跑关键词统计再做语义分类最后人工复核是否支持批量支持按公司或季度批量处理是否支持 API支持文本分析可封装为本地或远端 API 服务硬件要求CPU 可以跑统计和规则方法大模型语义分类需要 GPU 或 API显存占用取决于模型7B 量化约 6G13B 量化约 10G实际以部署环境为准输出结果CSV、JSON、Markdown 报告适合场景行业研究、竞品分析、AI 产品商业化趋势、内部 ROI 追踪这里要强调没有一份公开材料能覆盖所有公司的真实说法所以分析结果的可靠性取决于语料质量和分类规则。本文给的是通用流程不绑定任何独家数据源。2. 适用场景与使用边界2.1 适合谁用关注 AI 生产力的行业研究员需要从大量财报内容里提炼共性信号。产品技术团队的商业化同学想了解客户在对外沟通中如何描述 AI 带来的效率提升。AI Infra 团队希望用公开文本评估不同行业对 AI 基础设施需求的表达强度。个人开发者想练习长文本的 NLP 分析 pipeline 和提示词工程。2.2 能解决的问题回答“AI 是否真的进入了企业核心业务语言”。如果 AI 只出现在“技术创新展望”段落很少出现在“成本下降、人效提升、交付速度”段落说明产品化程度有限。回答“不同行业对 AI 的生产力定义是否一致”。科技行业更强调效率工具和研发提效制造行业更强调良率、故障预测零售行业更强调库存和转化率。回答“AI 相关表述随时间如何变化”。对比多个季度可以观察从“试点”到“规模化”的语言迁移。2.3 不适合什么场景不适合判断公司具体财务数据是否真实。电话会议是经过包装的对外沟通不是内部经营数据。不适合做个股买卖建议。文本信号只能作为辅助观察。不适合直接用于内部 KPI 考核。管理层对外措辞和内部执行效果之间有明显差距。2.4 合规与版权边界使用财报电话会议转写文本注意来源的公开性和版权声明。尽量使用公司 IR 页面免费公开的内容或明确允许引用的第三方数据。不要将分析结果与具体个人发言挂钩避免断章取义。如果用 AI 模型生成内容摘要要保留原始文本链接分析结论必须可回溯。涉及未公开信息的处理必须慎重只使用公开信息。3. 环境准备与前置条件3.1 基础环境建议使用 Python 3.10主要用到文本处理、PDF 解析、数据分析和简单的机器学习工具。# 创建虚拟环境 python -m venv earnings_ai_env source earnings_ai_env/bin/activate # Windows 下使用 earnings_ai_env\Scripts\activate # 安装基础依赖 pip install pandas numpy pdfplumber openpyxl如果需要做语义分类可以准备一个轻量模型接口或本地模型。推荐两种方式规则 关键词CPU 可跑速度快适合先做粗筛。大模型分类准确率更高适合复杂语义场景需要 GPU 或云端 API。3.2 模型和 API 准备如果使用 Hugging Face 模型做语义分类示例配置如下但请按实际环境调整model: name: distilbert-base-uncased # 仅作示例实际可按需替换 device: cuda # 无 GPU 改为 cpu batch_size: 16如果使用云端 API需要准备 API Key 和基础调用封装后续会给出通用调用示例。注意不要在生产环境中硬编码 Key。3.3 数据目录准备建议建一个清晰的目录结构把原始文档、中间结果、最终输出分开earnings_ai/ ├── data/ │ ├── raw/ # 原始 PDF、TXT │ ├── processed/ # 已清洗文本 │ └── output/ # 分析结果 CSV / JSON ├── config/ │ └── settings.yaml ├── scripts/ │ ├── extract_text.py │ ├── analyze_keywords.py │ ├── classify_signals.py │ └── generate_report.py这样的好处是批量处理多个季度或公司时不会把不同阶段的数据混在一起。4. 安装部署与启动方式这里的“部署”指的是把分析脚本跑起来。我们先从最基础的文本抽取开始。4.1 从 PDF 中抽取会议记录大多数财报电话会议记录是 PDF 或网页文本。如果是 PDF可以用 pdfplumber 提取文字import pdfplumber import re def extract_text_from_pdf(pdf_path: str) - str: full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: page_text page.extract_text() if page_text: full_text.append(page_text) return \n.join(full_text) if __name__ __main__: text extract_text_from_pdf(data/raw/sample_earning_call.pdf) with open(data/processed/sample_earning_call.txt, w, encodingutf-8) as f: f.write(text)如果网页内容已经以 TXT 或 JSON 形式给出可以跳过抽取直接进入清洗。4.2 清洗与分段电话会议文本通常包含演讲者标签、问题、非语言描述清洗时保留关键信息import re def clean_text(text: str) - str: # 去掉时间戳和过于碎的行 text re.sub(r\[\d{2}:\d{2}:\d{2}\], , text) # 去掉占位符 text re.sub(r\(.*?\), , text) # 合并多余空行 text re.sub(r\n{2,}, \n, text) return text.strip() def split_into_sentences(text: str) - list: # 按句子切分保留段落结构 sentences re.split(r(?[.!?。])\s, text) return [s.strip() for s in sentences if len(s.strip()) 5]注意简单的句子切分在英文缩写词上会有误差比如U.S.会被切开。如果需要更准确可以使用 spaCy 的 sentencizer。4.3 启动批量处理批量处理建议用一个配置文件管理公司列表和季度列表companies: - name: company_a quarter: 2025Q2 file: data/raw/company_a_q2.pdf - name: company_b quarter: 2025Q2 file: data/raw/company_b_q2.pdf然后写一个遍历脚本import yaml from pathlib import Path def load_config(config_path: str): with open(config_path, r, encodingutf-8) as f: return yaml.safe_load(f) def process_all(config_path: str): config load_config(config_path) for item in config[companies]: pdf_path item[file] text extract_text_from_pdf(pdf_path) clean clean_text(text) out_path Path(data/processed) / f{item[name]}_{item[quarter]}.txt out_path.write_text(clean, encodingutf-8) print(fProcessed {item[name]} {item[quarter]}, length{len(clean)})5. 功能测试与效果验证分析流程主要有四个功能点AI 关键词统计、生产力信号分句、语义分类、跨季度对比。5.1 AI 关键词统计先定义一组 AI 相关关键词可以包含通用词和技术词AI_KEYWORDS [ artificial intelligence, AI, machine learning, deep learning, generative AI, LLM, large language model, automation, copilot, agent, workflow automation, predictive model ]对清洗后的文本统计词频和命中的句子import re def find_ai_sentences(sentences: list, keywords: list) - list: matched [] for sent in sentences: lowered sent.lower() if any(kw.lower() in lowered for kw in keywords): matched.append({ sentence: sent, matched_keywords: [kw for kw in keywords if kw.lower() in lowered] }) return matched sentences split_into_sentences(clean_text) matches find_ai_sentences(sentences, AI_KEYWORDS) print(fTotal sentences: {len(sentences)}) print(fAI related sentences: {len(matches)})输出示例Total sentences: 1280 AI related sentences: 86这个数字本身没有绝对意义但是对比不同季度或不同公司时能看出趋势。5.2 生产力信号分句只统计 AI 关键词不够还要看这些句子是否和生产力挂钩。定义生产力信号词PRODUCTIVITY_KEYWORDS [ productivity, efficiency, cost saving, cost reduction, faster, time savings, throughput, workflow, automation, headcount, revenue per employee, cycle time, yield ]然后筛选“既包含 AI 关键词又包含生产力关键词”的句子作为高优先级信号def find_ai_productivity_sentences(sentences, ai_keywords, prod_keywords): results [] for sent in sentences: lowered sent.lower() ai_hit [kw for kw in ai_keywords if kw.lower() in lowered] prod_hit [kw for kw in prod_keywords if kw.lower() in lowered] if ai_hit and prod_hit: results.append({ sentence: sent, ai_keywords: ai_hit, productivity_keywords: prod_hit }) return results priority_signals find_ai_productivity_sentences(sentences, AI_KEYWORDS, PRODUCTIVITY_KEYWORDS) print(fAI productivity co-occurrence sentences: {len(priority_signals)})这个步骤的价值在于过滤掉空洞的 “we are excited about AI” 这类表述留下 “AI reduces processing time by 30%” 这类具体信号。5.3 语义分类关键词共现只能做粗筛更准确的分类可以交给语义模型。这里提供一个通用思路不绑定具体模型分类标签Capability、Productivity、Investment、Risk、Other。输入句子“We deployed AI agents to handle customer support tickets.”预期输出Productivity。使用大模型 API 时可以用一个简单的提示词模板。这里给的是通用 Python 调用示例实际接口以你使用的服务为准import requests def classify_with_llm(sentence: str, api_url: str, api_key: str): headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: your-model-name, # 需要按实际服务修改 messages: [ { role: system, content: ( You are an analyst. Classify the sentence into one label: Capability, Productivity, Investment, Risk, Other. Return only the label. ) }, { role: user, content: sentence } ], temperature: 0 } response requests.post(api_url, jsonpayload, headersheaders, timeout30) response.raise_for_status() return response.json()[choices][0][message][content]运行前把api_url、api_key、model替换成真实配置。5.4 判断成功的标准如何判断整个分析流程是否成功数据层所有 PDF 都被成功抽取为纯文本没有乱码段落完整。关键词层AI 关键词命中的句子数量稳定同一份文本重复运行结果一致。分句层高优先级信号句子能被人工识别为确实涉及 AI 和生产力准确率建议用人工抽检 20 条达到 70% 以上再继续。分类层分类结果的抽检准确率大于 80%如果低于这个值需要调整提示词或增加 few-shot 示例。批量层批量处理完成后输出文件行数和原始文档条目数一致。5.5 常见失败原因失败现象可能原因排查方式抽取文本为空PDF 是扫描件需要 OCR先用 pdfplumber 预览前 3 页文本关键词命中率过高关键词过于宽泛比如 “AI” 可能匹配 “Aim”使用词边界匹配\bAI\b或统一转小写后精确匹配语义分类结果混乱提示词缺少示例增加 few-shot 或规则兜底大量句子被错误切分句号、缩写干扰切换到 spaCy 或 NLTK 句子分割器重叠关键词导致重复计数同一句话同时含 “AI” 和 “machine learning”去重时按句子维度计数而不是按关键词维度6. 接口 API 与批量任务如果要把这套分析能力做成服务可以让其他系统提交文本返回结构化结果。这里展示一个最小的 FastAPI 服务框架。6.1 服务端示例from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class AnalyzeRequest(BaseModel): text: str batch: bool False class BatchAnalyzeRequest(BaseModel): texts: list[str] app.post(/analyze) def analyze(req: AnalyzeRequest): if not req.text.strip(): raise HTTPException(status_code400, detailtext is empty) sentences split_into_sentences(req.text) matches find_ai_sentences(sentences, AI_KEYWORDS) return { total_sentences: len(sentences), ai_sentences: len(matches), sentences: matches[:20] } app.post(/analyze/batch) def analyze_batch(req: BatchAnalyzeRequest): results [] for idx, text in enumerate(req.texts): sentences split_into_sentences(text) matches find_ai_sentences(sentences, AI_KEYWORDS) results.append({ index: idx, total_sentences: len(sentences), ai_sentences: len(matches) }) return {results: results}启动服务uvicorn api_server:app --host 127.0.0.1 --port 80006.2 调用示例import requests url http://127.0.0.1:8000/analyze payload { text: This quarter we deployed AI to automate invoice processing. It improved productivity significantly. } response requests.post(url, jsonpayload, timeout30) print(response.json())批量调用时要注意请求体大小和超时时间。一个批次建议不要超过 50 个长文档防止内存占用过高。6.3 批量任务队列设计当文档数量很多时可以用简单的队列脚本from concurrent.futures import ThreadPoolExecutor, as_completed def analyze_one(text: str, idx: int): # 实际分析逻辑 return {index: idx, ai_sentences: 0} texts [long text 1, long text 2, ...] with ThreadPoolExecutor(max_workers4) as executor: futures [executor.submit(analyze_one, t, i) for i, t in enumerate(texts)] for future in as_completed(futures): result future.result() print(result)线程数不要开太大CPU 密集型任务可以先测试 2、4、8 三档选择耗时最低的配置。7. 资源占用与性能观察7.1 纯规则和统计方法如果只做关键词统计和共现筛选CPU 就能跑内存占用取决于文本大小。一份电话会议记录大概几十 KB 到几百 KB完全不是瓶颈。但要注意如果使用正则表达式做大量关键词匹配句子数量很多时性能会下降。可以先对每个句子做一次小写转换减少重复的.lower()调用。7.2 大模型语义分类使用本地大模型时首先要看显存。假设你部署一个 7B 量化模型建议显存不小于 6G推理批量大小越大显存占用越高。如果显存不足可以把 batch_size 调小或改用 CPU 推理但速度会慢很多。判断显存占用的方法是启动服务后观察 nvidia-smiwatch -n 1 nvidia-smi关注Volatile GPU-Util和Memory-Usage如果显存溢出降低 batch_size 或换更小模型。7.3 API 服务资源观察如果用云端 API需要观察的是延迟和 QPS 限制。调用量大的时候要加错误重试和退避import time import requests def call_with_retry(api_url, payload, retries3, timeout30): for attempt in range(retries): try: response requests.post(api_url, jsonpayload, timeouttimeout) response.raise_for_status() return response.json() except Exception as e: print(fAttempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) raise RuntimeError(API call failed after retries)7.4 影响性能的因素文本长度句子越多分割和匹配耗时越长。关键词列表长度300 个关键词和 30 个关键词的耗时差距明显。语义模型类型大模型推理时间和输入 token 数成正比。并发数线程数过高会导致上下文切换开销过低则显存利用率不够。磁盘 IO大量小文件写入会拖慢整体速度尽量合并输出。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动 API 后端口被占用其他服务占用 8000 端口netstat -ano | findstr :8000更换启动端口--port 8001PDF 抽取后中文乱码PDF 编码不支持打印前 500 字符查看编码改用 OCR 或选择文本可复制的 PDF关键词统计为 0大小写或边界问题打印一条原始句子看格式统一lower()或加入同义词大模型分类返回乱码输出格式不受控检查返回内容提示词中要求只返回 JSON批量任务卡住单条文本过大或模型推理过慢打印当前索引和耗时拆分长文本增加超时时间分析结果和人工判断差别大分类标签定义不清晰抽样 50 条人工标注调整标签体系或增加示例显存溢出batch_size 过大nvidia-smi 观察显存降低 batch_size或开积分精度9. 最佳实践与使用建议9.1 先建立小样本测试集不要第一次就跑几百个文件。先选 3 到 5 份不同行业的会议记录手动标注一遍把“AI 信号”“生产力信号”的定义固定下来再让代码去拟合。机器辅助分析是效率工具不是替代判断的工具。9.2 保留可回溯源每条分析结果都应该保留原句、出处文件、季度信息。输出的 JSON 建议包含{ company: company_a, quarter: 2025Q2, sentence: We used AI to reduce processing time by 30%., ai_keywords: [AI], productivity_keywords: [reduce, processing time], classification: Productivity, source_file: company_a_q2.pdf }这样任何人看到结果都可以回到原始文本避免“看起来有道理但无法验证”的问题。9.3 指标设计要能解释单纯的“AI 词频”没有业务意义。建议计算几个可解释的指标AI 相关句子占比AI 句子数 / 总句子数。AI 与生产力共现率AI生产力句子数 / AI 句子数。生产力信号置信度人工抽检的正确比例。跨季度变化率本季度共现句子数 / 上个季度共现句子数 - 1。注意这些指标只反映对外沟通的措辞倾向不代表实际效率提升。使用时要明确适用范围。9.4 注意隐私和授权不要使用付费数据库中的内部转写文本除非你有授权。不公开分析未经允许的商业信息。涉及大模型 API 调用时注意文本是否包含敏感业务数据。建议使用脱敏后的数据或本地部署。9.5 工程化配置把常用参数写入配置文件而不是散落在脚本里analysis: ai_keywords: - artificial intelligence - AI - machine learning productivity_keywords: - productivity - efficiency - cost reduction output: format: csv include_sentence: true这样新同事接手时不需要理解代码里的每个魔法字符串。10. 总结与下一步“AI and Productivity”这个主题最值得做的不是统计某个季度里 AI 被提到多少次而是建立一套从原始文本到结构化信号的流程持续观察 AI 如何从概念性表达变成具体的生产力叙事。回到部署和分析本身最应该先验证的是关键词共现公式拿一份真实会议记录跑通PDF - 文本 - 句子 - AI 关键词 - AI生产力共现这条链路。整条链路跑通后再考虑引入大模型做语义分类。最容易踩的坑有三个一是 PDF 抽取不检查直接进入分析导致文本为空二是把“AI 出现次数”当成立即达成的生产力指标忽略了语境三是批量任务跑起来以后不记录中间结果最后无法回溯。后续可以继续扩展的方向是引入情感分析判断管理层是“防御性回应 AI”还是“主动押注 AI”还可以把同一批关键词用于分析技术大会演讲稿对比财报沟通和产品发布之间的表述差异。建议把这套方法存成一套可复用脚本每季度更新一次数据就能形成自己的企业 AI 生产力指数。