Python生成器在NLP实战中的原理、用法与踩坑

1. 先搞清楚一个源头问题为什么NLP里到处都在用生成器我在跑自然语言处理任务的时候有一件事印象特别深刻。当时手里是一份22GB的维基百科语料想着用最朴素的办法读取——data open(wiki.txt).readlines()。结果代码还没跑完系统先给我上了一课内存占用直接飙到95%风扇起飞最后整台机器卡到只能强制重启。那会儿我还没认真学过生成器以为它就是Python里一个“有点特别但不着急掌握”的语法糖。后来在NLP实战里反复遇到内存爆炸、流式处理、延迟计算这些需求才发现生成器不只是语法糖它是解决这类问题的核心工具之一。简单来说生成器是一个“惰性求值”的迭代器。你可以把它理解成一家现烤现卖的面包店你买一个师傅才烤一个绝不提前把一百个面包全堆在柜台里占地方。对比普通列表列表就像一次把一百个面包全部烤好摆出来客人不吃也得先占着那块展示台。放到代码里前者生成一个元素消耗一个元素的内存后者把所有元素全部放在内存里等着你取。这篇文章不绕弯子核心讲透五件事生成器的定义方式和执行机制、生成器表达式到底省不省内存、NLP实战里生成器最常见的三种用法、send/throw/yield from这些进阶机制以及我从实际项目中踩出来的坑和排查思路。适合刚学Python不久、但已经在处理真实文本数据的朋友也适合看了很多教程却始终没把生成器“真正用起来”的人。2. yield到底做了什么生成器函数的暂停-恢复机制2.1 从普通函数到生成器函数区别就在这一个关键字先看最常用的创建方式生成器函数。只要一个函数里出现了yieldPython解释器就会把它标记为生成器函数。注意标志是在函数定义阶段完成的而不是在调用的时候。def count_up_to(n): current 0 while current n: yield current current 1调用count_up_to(5)不会真的执行函数体而是返回一个生成器对象。只有当你主动去请求元素时函数体才开始执行并且会在yield那一行暂停把值传给你然后等你下一次索要再从暂停的位置继续往下走直到函数自然结束或者遇到return。这里有一个新手最容易犯迷糊的点yield和return都能从函数里“交出一个值”但return交出值之后函数就彻底终结了而yield只是临时挂起函数的所有局部变量、执行位置、循环状态都会原封不动地保存下来等下一次next()调用时接着运行。2.2 执行机制拆解一张流程地图我用一个带输出日志的例子来演示暂停-恢复到底是怎么发生的def demo_gen(): print(第一次走进函数) yield A print(第二次走进函数从上一次的 yield 之后继续) yield B print(整个流程收尾) g demo_gen() print(此刻还没执行函数体) first next(g) print(f拿到的第一个值: {first}) second next(g) print(f拿到的第二个值: {second})执行结果和顺序如下此刻还没执行函数体 第一次走进函数 拿到的第一个值: A 第二次走进函数从上一次的 yield 之后继续 拿到的第二个值: B 整个流程收尾细心的朋友应该已经发现了创建g demo_gen()时函数体一行都没跑第一次next(g)跑到了第一个yield拿到A函数暂停第二次next(g)从yield A下一行继续最后跑到第二个yield拿到B。如果你继续第三次next(g)函数会从yield B下面开始执行把“整个流程收尾”这段跑完然后抛出StopIteration异常代表生成器已经彻底耗尽。这种暂停-恢复机制才是生成器真正的底层核心。理解了这个后面看send、yield from、协程甚至async/await都会顺很多。2.3 return和yield混用时的停止信号生成器函数里出现return时Python有个特殊约定return后面跟着的值会藏在StopIteration异常的value属性里。不过一般情况下我们用for循环遍历生成器时根本感知不到这个异常因为for循环自己会捕获它当作结束信号。def gen_with_return(): yield 1 yield 2 return 结束时的附加信息 g gen_with_return() for item in g: print(item)这段代码只会打印1和2那个结束时的附加信息不会出现在循环里。如果非要用next()硬取第三次调用会抛出StopIteration而异常对象里的value属性正好能拿到这个值。这个特性与生成器委托、协程的返回值传递有关后面的章节会用到。从NLP的角度看理解这个机制最大的意义在于你可以写一个生成器逐条产出分词后的句子当句子全部产出完毕之后再通过返回值报告一下处理了多少条、过滤了多少条。这个做法听起来别扭但当你学会yield from之后它会变成一个非常优雅的批量处理模式。3. 生成器表达式列表推导式的“省内存替身”与实际取舍3.1 生成器表达式的写法与惰性机制除了生成器函数Python还提供了一种极简的创建方式生成器表达式。写法就是把列表推导式的方括号换成圆括号。words [自然语言, 处理, 是, 人工智能, 的重要, 方向] gen_exp (len(word) for word in words) print(gen_exp) # 输出的是一个 generator object注意打印出来的不是元素内容而是一个生成器对象地址。这说明(len(word) for word in words)这行代码并不会立刻计算每个词的长度它只是构建了一个“计算计划”。当你用for循环遍历它或者调用next()的时候才真的开始算。如果一个生成器表达式只有一个参数像sum(len(word) for word in words)这样那对括号可以省略。日常写代码我更喜欢保留圆括号或者保留函数自身的括号可读性更好也不容易让不熟悉这个语法的同事看懵。3.2 一个直观的内存对比实验光说“省内存”不够有说服力我做一个可以自己复现的小实验。用sys.getsizeof看对象占用的内存再对比一下列表推导式和生成器表达式的结果import sys nums range(1000000) list_comp [x * 2 for x in nums] gen_exp (x * 2 for x in nums) print(sys.getsizeof(list_comp)) # 列表已经把所有结果算好并存放占用明显 print(sys.getsizeof(gen_exp)) # 生成器对象本身只占几十到几百字节在我本地的实测里列表推导式那行占了接近8MB而生成器表达式只占几十字节。差距如此悬殊核心原因就是列表推导式当场执行把所有x*2的结果全部放进了内存生成器表达式只是创建一个可迭代对象真正的计算被推迟到每次迭代时。需要特别提醒的是生成器表达式省的是“存放所有元素的内存”但不省“计算耗时”。面对一千万个数它的总计算量并没有减少只是把计算分摊到每次迭代。所以不要把“惰性求值”误解成“免费计算”。它的本质是空间换时间——把集中一次性的大内存开销换成随取随算的小步长开销。3.3 什么时候别用生成器表达式生成器表达式并不是万能钥匙。至少有两类场景我建议直接用列表推导式需要反复遍历同一批数据时。生成器只能遍历一次遍历完就空了列表可以随时重新遍历。数据量小且后续要频繁索引时。比如words[3]直接取值列表一步到位生成器根本没有下标访问能力。所以在NLP预处理阶段像读取整个配置文件、加载几百条样本这种轻量场景用列表完全没有问题。只有当数据量大到“无法一口气塞进内存”或“全量计算是浪费”的时候才值得请出生成器。这也是我一直强调的技术选型要跟着数据规模走不要为了“酷”而用生成器。4. NLP实战中生成器的三种高频落地姿势4.1 大文件逐行读取从一次读完到按需消费NLP第一步几乎都是和文本文件打交道。这里给一个可以直接抄作业的写法def read_lines(file_path, encodingutf-8): with open(file_path, r, encodingencoding) as f: for line in f: line line.strip() if line: yield line这个生成器函数做了什么open()返回的文件对象本身就是一个可迭代对象for line in f会按行取出内容yield line把每一行交出去同时函数暂停。处理完一行内存里就只剩这一行不会把整个文件塞进内存。我处理22GB语料时用的正是这个思路每读出一行分词、去停用词、统计词频、然后丢弃这一行内存峰值稳定在几百MB以内。如果是直接用readlines()同样一份文件大概率直接把内存打穿。这里补充一个容易被忽略的细节open()里的encoding参数别漏。处理中文NLP语料时如果文件是UTF-8编码漏掉encoding参数在某些平台默认编码不是UTF-8的情况下会直接抛UnicodeDecodeError。很多机器的默认编码是gbk读一个UTF-8文件就会出现乱码或者报错。这一点我在Windows环境上踩过好几次每次处理中文语料都要先确认编码再动手。4.2 词频统计与Top-N过滤数据像流水线一样流过读文件只是第一步。更典型的需求是从大量文本文件中统计词频最后只关心出现次数最多的前几十个词。这里可以让生成器把数据流串成一条流水线。from collections import Counter import jieba def tokenize_lines(line_iter): for line in line_iter: words jieba.lcut(line) yield from words # 把分词结果逐个抛出去 def filter_stopwords(token_iter, stopwords): for token in token_iter: if token.strip() and token not in stopwords: yield token file_gen read_lines(news_corpus.txt) tokens tokenize_lines(file_gen) stopwords {的, 了, 在, 是, 和, 等} filtered_tokens filter_stopwords(tokens, stopwords) counter Counter(filtered_tokens) top_50 counter.most_common(50)这一套代码的精妙之处在于read_lines产出每一行tokenize_lines消费一行并产出这一行对应的分词结果filter_stopwords再对每个词做过滤最后的Counter一边消费一边计数。整个链路里任何时刻内存中只有“当前这一行”和“当前这个词”而不是所有文件内容、所有分词结果同时存在。你可能会问直接用for嵌套不行吗当然可以但可读性差而且每一步的过滤逻辑绑在一起想调整某一个环节就得大改代码。生成器流水线的好处是每个环节都是一个独立的生成器函数可以单独测试、替换、复用。从维护角度讲这种写法比把所有逻辑写在一个函数里舒服太多了。tokenize_lines里的yield from words是个关键点。它的作用是把一个可迭代对象这里是分词后的words列表里的每个元素逐个yield出去。等价写法是for word in words: yield wordyield from的好处是少写一层循环逻辑更清晰。但它背后的机制远不止“语法缩写”这么简单这个在第5章会展开讲。4.3 流式Batch生成为深度学习训练喂数据如果做深度学习相关的NLP任务通常会有一个DataLoader之类的组件来按批读取数据。在没有框架默认支持的情况下写一个生成器做动态batch打散也是个非常实用的方案def batch_generator(data_path, batch_size32, shuffleTrue): buffer [] for line in read_lines(data_path): buffer.append(line) if len(buffer) batch_size: if shuffle: random.shuffle(buffer) yield buffer buffer [] if buffer: # 最后不足一个 batch 的部分也要交出去 yield buffer这个生成器的思路是攒够batch_size行就交出一个batch不够就继续攒读完后把剩余不足一个batch的残料也吐出来。这样训练进程每请求一次就拿到确定数量的样本内存里始终只有batch_size份数据而不是整个训练集。对于NLP任务还有更进阶的玩法在batch内部做padding到相同长度或者按长度排序后再分批减少padding浪费。这些都可以封装在生成器内部让训练主循环完全不用关心数据组织逻辑。我的经验是把数据预处理和batch组装做成生成器流水线能让训练代码极度精简同时也方便在多个数据集之间切换策略。5. send、throw、close与yield from生成器没你想的那么简单5.1 send给暂停的生成器“递话”next()只能单方向从生成器取数据而send()可以往生成器里传数据。调用send(value)时这个value会成为当前yield表达式的返回值生成器内部拿到这个值之后继续往下跑。def echo_upper(): while True: text yield print(text.upper()) g echo_upper() next(g) # 让生成器先跑到 yield 处 g.send(hello) # 输出 HELLO g.send(nlp) # 输出 NLP注意一个关键细节生成器第一次启动时必须先调用next(g)或者g.send(None)让它跑到yield那一行否则直接send(hello)会报TypeError——因为生成器还没准备好接收值。这一点是很多新手卡住的地方。send在NLP里有什么用最典型的场景是做动态配置生成器在处理数据时你可以随时通过send传入新的阈值或开关让它改变行为。比如词频统计中动态调整停用词集合或者多语言处理时切换语言模型参数都不需要重新创建生成器。5.2 throw和close主动终止一个生成器throw(exc_type)会在生成器暂停的位置抛入一个异常。如果生成器内捕获了这个异常就可以继续执行如果不捕获异常会向外传播生成器也会随之终结。close()则更直接它在生成器暂停处抛出GeneratorExit异常让生成器进入结束状态。之后任何next()操作都会抛StopIteration。def safe_counter(): try: n 0 while True: yield n n 1 except GeneratorExit: print(生成器被关闭清理资源...) c safe_counter() print(next(c)) c.close() print(next(c)) # 会抛 StopIteration这种显式关闭机制在处理“打开的文件句柄”或“数据库连接”这类资源场景时很有价值。如果生成器内持有文件对象写一个try/finally配合close()就能确保无论生成器是被正常耗尽还是被外部提前关闭资源都能被释放。需要注意一个常见的认知偏差生成器的close()不同于文件对象的close()它不会帮你释放“生成器内部引用到的任何外部资源”它只负责让生成器结束并抛出GeneratorExit。如果内部持有文件需要自己在finally块中关闭文件或者用contextlib.closing来确保万无一失。5.3 yield from背后子生成器的委托与返回值传递yield from不是简单的“语法替换”它为生成器之间的委托提供了完整协议外层生成器会向内层生成器转发next、send、throw、close同时内层生成器的return值会成为yield from表达式的最终值。def inner(): total 0 for i in range(5): total i yield i return total def outer(): result yield from inner() print(finner 的返回值是: {result}) for item in outer(): pass # 输出: inner 的返回值是: 10这个能力让代码的模块化程度提升一个档次。回到NLP的场景——你可以写一个“基础分词生成器”然后写一个“清洗生成器”委托给它再写一个“统计生成器”委托给它。每一层只管自己的事但最外层的调用者可以像一个完整的生成器一样从头到尾迭代中间任意层的返回值都能传递出来。这种组合方式比多层for嵌套、或者在生成器之间手动搬运数据要干净得多。5.4 生成器与协程的关系传统意义上的生成器多用于迭代数据但你如果掌握了send和yield双向通信它就具备了协程的基本能力一个函数既可以从外部接收数据又可以向外部输出数据执行过程可以随时暂停和恢复。这也是为什么很多人说“生成器是协程的祖先”。Python的async/await底层就大量借用了生成器的挂起恢复机制。区别在于生成器是显式通过yield暂停协程是隐式通过await挂起生成器的恢复靠next/send协程的恢复由事件循环调度。理解生成器之后再去看async/await你会发现底层逻辑其实是通的不会是两眼一抹黑。我在日常项目中并不建议为了协程去硬用生成器毕竟asyncio已经足够成熟。但这份理解很重要因为它能帮你更快地看懂异步框架源码也能帮你理解为什么某些生成器代码会与事件循环有类似的行为。6. 生成器踩坑实录与内存实测我把能犯的错都犯了一遍6.1 坑一生成器只能迭代一次耗尽了就是空了这是最高频的误解。很多人在实际项目里写g (x for x in range(100)) print(sum(g)) # 4950 print(sum(g)) # 0因为第一次 sum 已经把生成器耗尽了第二个sum返回0不是巧合而是生成器已经走到终点后续迭代拿到的是空。如果你需要遍历多轮数据就不要用一次性生成器老老实实把它转成列表或者重新创建一个生成器。我在一次文本分类任务里就为这个坑付出过代价当时我写了一个生成器读取训练样本第一轮训练用得很顺手到了第二轮epoch时发现模型loss从大写开始就不动了。查了半天才发现第二轮迭代时数据集已经空了。后来我把数据缓存到列表里或者每次epoch重新创建生成器才解决了问题。6.2 坑二无限生成器忘了写退出条件生成器允许你写while True无限产出数据这在流式处理中有价值。但如果你忘了写消费侧的终止条件程序就会像脱缰的野狗一样停不下来。比如def infinite_text_stream(): while True: yield 这是一行假设的实时语料没有break、没有计数上限、没有外部信号这个生成器会无限产出。你能想象它出现在线上服务里是什么后果吗在测试阶段通常是没问题的一旦接入正式流程缺乏终止条件可能导致消息处理任务永远无法结束。我处理实时语料流时的做法是在消费侧明确设置一个最大条数或时间窗口到了就主动break。如果你拿到的数据源天然是无限的那么消费侧必须自己定义“结算点”。6.3 坑三send之前的第一个next绝不能忘我见过很多协程教程里一上来就直接send然后就报错然后新手一脸困惑。重申一遍生成器刚创建时还没执行到yield此时你根本没地方接收send的值。必须先用next(g)或g.send(None)让它跑起来到第一个yield暂停之后才能使用send。我曾在一个文本增强脚本里用生成器做动态改写模型外部传一些参数进来第一次运行的时候忘记做启动next直接报TypeError: cant send non-None value to a just-started generator。这个报错信息已经写得很明确了但它背后反映的是对生成器“暂停点”理解的缺失。6.4 坑四在生成器里顺手就return了一个结果很多初学者把生成器函数当普通函数用以为:return result能让外部立刻拿到结果。实际上生成器函数的返回值要么被忽略要么藏在StopIteration里for循环里根本取不到。这个坑和2.3节的理解直接相关。所以如果你要返回终值要么用外部变量收集要么用yield from委托给内部生成器并拿它的返回值。更直接的办法是把“返回最终统计结果”和“逐条产出数据”分开用一个包装函数内部负责产出数据外部再收集最终结果。6.5 实测对比列表推导式 vs 生成器表达式为了把“省内存”这件事说得更扎实我直接用一个大一点的文本列表做对比。假设我们现在有十万个句子要对每个句子做长度统计import sys, random, string sentences [.join(random.choices(string.ascii_letters string.punctuation, k50)) for _ in range(100000)] lengths_list [len(s) for s in sentences] lengths_gen (len(s) for s in sentences) print(sys.getsizeof(lengths_list)) # 列表空间较大 print(sys.getsizeof(lengths_gen)) # 生成器空间极小结果差异依然显著。用列表推导式时十万个句子长度全部预先算好并暂存用生成器表达式时每次迭代只算一个长度然后立即消费。实际跑一遍之后你会发现内存占用差距非常可观。但这并不意味着列表推导式一无是处——如果需要把lengths_list反复做统计分析列表反而是更方便的选择。6.6 排查思路总结生成器不按预期工作时看哪里如果生成器的行为和你预期不一致我的排查顺序一般是先看创建方式——是生成器函数还是生成器表达式两者执行时机不同。再看迭代次数——同一个生成器对象被迭代过多轮了吗多轮建议重新创建。再看函数内部——有没有意外return有没有提前抛出异常再看消费侧——无限生成器的退出条件写了吗send之前做next了吗最后看资源——生成器被close()之后还在使用吗文件资源真的释放了吗这套顺序看起来简单但能覆盖绝大多数实际问题。这些年我帮同事排查过不少生成器相关的bug最后发现几乎都逃不出这几个范畴。7. 从生成器到async/await最后补充一个认知升级很多学Python的人分不清生成器和协程其实两者的血缘关系非常紧密。生成器通过yield在“调用者”和“生成器”之间实现单向或双向通信协程通过await实现任务挂起和恢复。Python的async/await语法在早期实现里本质就是基于生成器的yield机制做出来的。具体来说async def定义的协程函数调用之后返回一个协程对象。这个对象内部逻辑上也是一个可暂停、可恢复的状态机——很像生成器。事件循环负责调度协程在await处挂起等I/O完成后恢复。所以说你今天把生成器的暂停-恢复机制吃透了明天学async/await就会舒服得多。那NLP里用到协程的场景有吗有比如同时请求多个外部API做文本增强、并发的Web爬虫采集语料、异步读取多个数据源等。但这些场景通常直接用asyncio的协程不需要手写生成器。我的建议是生成器仍然是NLP中最基础、最常用的数据流工具协程是它在异步方向上的演进。先把生成器用熟再去碰异步路径更顺。关于生成器我最后分享一个个人经验不要沉迷于花哨用法。在NLP项目里90%以上的需求用“生成器函数惰性求值流水线思维”就能解决send和yield from属于进阶装备用到的时候再去深挖也完全来得及。真正重要的是建立“数据像流水一样流过程序”的思维模式这才是生成器带给我的最大收获也是我想在这篇文章里传递给你的核心认知。