三月下旬的一个下午，林晨抱着笔记本走进陈博士办公室的时候，白板上还留着上午产品评审的痕迹。他拿起板擦把那些流程图擦干净，然后拧开记号笔的盖子。
陈博士正在回邮件，头也没抬。你那个数据方案，想清楚了？
想清楚了。但先说一个前提——林晨在白板左上角写了个数字：70%。券商授权数据大概只能覆盖我们需要的七成场景。国泰那边总量策略和行业配置签了，个股深度锁死不给。另外两家还在谈，别乐观，一家进度卡在法务审条款，另一家连技术对接人都还没定。
陈博士这才转过来，靠在椅背上看着白板。七成不够。剩下三成你怎么填？
公开数据。林晨在白板上画了第二个框，年报问询函、监管处罚公告、投资者关系活动记录——全是交易所和证监会公开的，没有版权问题。张雨的爬虫已经搭好了，第一批八千份问询函正在入库。
八千份问询函，质量怎么样？
参差不齐。有的问询函回复特别详细，连子公司担保链都拆开了写；有的就几页套话。林晨顿了顿，但量摆在那儿，清洗之后可用的部分我估计能过半。而且问询函有个天然优势——它是交易所质疑上市公司时发的，里面的措辞自带风险线索标记。模型从这种语料里学到的风险信号，比研报里四平八稳的分析要锐利得多。
陈博士站起来走到白板前，盯着那个第二个框看了几秒。你说公开数据没有版权问题——技术上没有。但你有没有想过一个问题：你爬了几千份问询函喂给模型，模型输出的时候如果有一段跟某家公司问询函回复的措辞高度相似，那算不算侵犯这家公司的信息权？
林晨的手停在记号笔上。
这个问题他确实没有深入想过。问询函是公开文件没错，但如果模型生成的文本和某家上市公司的回复原文高度重合，在金融合规语境下确实可能出问题。尤其是涉及未公开的经营数据——虽然出现在问询函回复里，但那家公司可能并不希望这些信息被AI模型重新组合后二次传播。
我加一条规则——林晨在白板上写了几个字，输出环节做去重。模型生成后过一遍跟训练语料的相似度比对，超过阈值的段落自动标注来源并附原文链接。跟我们在国泰那边的溯源设计一脉相承。
陈博士点了下头，视线移到白板空白处。还有呢？券商授权和公开数据加在一起，缺了什么？
市场微观结构。林晨在白板最右边画了第三个框，研报讲的是机构逻辑，问询函讲的是监管视角。但每天实际交易里价格怎么动、量怎么变、信号出了之后市场多长时间反应——这些数据两种来源都没有。
你自己那套量化交易日志？陈博士问。
对。三年，几千条交易信号和对应的市场反应。另外FinGpt v2在金融事业部的客服试运行数据，脱敏之后也能用。但这两个加在一起，量不大。交易日志大概三千条，客服日志脱敏过滤之后能用的可能不到两千条。
陈博士转过身面对林晨。你刚才说七成靠券商，剩下靠公开数据补。那市场微观结构这部分呢？五千条样本撑不起一个维度。
撑不起。但这五千条的用法不一样——它混在总量数据里做辅助特征。就像你做NLp的时候加个词性标注，词性本身提供不了主要语义，但能让模型在歧义句上判断更准。交易日志和客服日志起的就是这个作用。
陈博士沉默了一会儿。他拿起白板旁边的一支笔，在第三个框下面画了一条短线。那问题来了——你这个辅助特征的数据量够不够起到辅助的作用？五千条混在总量一万多条的语料里，占比不到三成。模型会不会干脆忽略这个维度的信号？
林晨承认这个问题存在。如果某个特征在训练数据里占比太低，模型可能直接把它当噪声过滤掉。他想了几秒钟。那我把交易日志的数据做一次增强。每条原始信号加反向条件和扰动条件——比如如果信号发出时大盘在跌，结果会怎样。逻辑上是合理的，量化回测本来就做这种条件分解。增强之后数据量能翻三四倍。
翻三四倍——人工合成的数据，模型能分出来吗？
分不出来，前提是增强规则本身是对的。我做了三年量化，增强逻辑不会有问题。
陈博士把笔放回笔槽。数据方案大方向行。但有两个风险点你要盯住——第一，公开数据的合规边界比你以为的模糊，找法务出一份正式的意见书，不要自己判断；第二，券商授权那边另外两家，下周我再帮你推一把，你别花太多精力在上面。你现在的重点应该放在数据清洗和标注上。
标注人手不够。林晨说了他最想说的一件事。
Jd已经给hR了，三天了，简历就收了七份。其中四个是计算机专业的——我们需要的是懂财务的，不是懂代码的。另外三个金融相关的，两个是大三的，基础太薄，一个倒是研二的，但在广州，人过不来。
陈博士想了想。hR那边我去说，让他们加急推。另外你把Jd里的薪资往上提一档，鹏城这地方实习生薪资到位了人不难找。
提多少？
日薪从一百五提到两百。别在这上面省。
林晨点了下头，把白板上的内容拍了一张照片，转身出了办公室。
回到工位，张雨的显示器分成左右两块。左边是scrapy的运行日志，绿色的200 oK一行一行往下滚，偶尔跳出一行红色的403 Forbidden——被反爬了，但scrapy的自动重试机制在十秒之后换了个代理Ip重新请求，又变回了绿色。右边是数据看板，三条入库曲线都在往上走。
入库顺利。张雨指着左边那块屏，深交所的页面结构很规矩，css选择器写完基本不用改。上交所的稍微麻烦一点，有些老页面还是table布局，不过也能搞定。
出问题了？林晨看到他浏览器里另外开了一个tab，标题是tesseract ocR。
张雨的表情一下子变了。他把右边屏幕切到一个预览界面——上面是一份年报问询函的扫描件，中间夹了一张财务数据表格。你看这个。问询函本身是纯文本的，爬取没问题。但有些公司在回复问询函的时候，直接把财务附表贴成了图片。pdF转文本到这一步就断了——ocR出来的东西你看。
他点开ocR结果。表格原本是五行六列的结构，ocR输出的文本里行和列全混在了一起——第三行的数字跑到第二行末尾，表头和表体粘在一起，小数点后面的数字被截断或者拼到了隔壁单元格。
我试了三个参数配置——张雨把tesseract的配置文件拉出来给林晨看，psm模式从3到6到11都试了，表格结构识别最好的是psm 6，但你看到结果了，还是乱的。字符识别率倒是不低，单个数字几乎没认错，关键是位置信息全丢了。
林晨盯着那张乱掉的表格看了半分钟。字符识别对了但位置丢了——那问题不是ocR引擎，是表格检测。你先做个预处理——把pdF页面做版面分析，表格区域单独切出来，然后用专门的表格识别模型做结构解析，不要把整页丢给tesseract。
专门的表格识别模型？有什么现成的？
微软去年开源了一个table-transformer，专门干这个的。你先拿它试试，识别出表格的行和列的边界框，然后在每个单元格内做ocR。两步拆开做，比一步到位要靠谱。
张雨记了两行笔记。那非表格的部分呢？
纯文本的让模型自动清洗，不用人工介入。只把含表格的页面标记出来，table-transformer跑完之后，单元格级ocR再校验一遍。校验的工作量——他估算了一下，八千份问询函里带财务表格的大概两成，一千六百份左右。每份校验三到五分钟，全走人工得要——
一百多个小时。张雨算得很快。
所以需要标注实习生。林晨把下午和陈博士讨论的结论说了，薪资提了，hR那边在推。人到了之后清洗和标注并行，你这边爬虫和表格识别继续优化。
张雨已经把table-transformer的Github页面打开了。
晚上九点多，林晨坐在工位上整理今天的数据方案讨论。他没有写什么总思考，只是在项目文档里加了三个待办事项：法务意见书——公开数据合规边界确认；hR——标注实习生招聘加急；张雨——table-transformer表格识别方案验证。想了想又在下面补了一条：券商授权的另外两家，进度周报单独跟踪，别让它们自己拖着。