企业官网建设流程全解析

1. 项目起底：当数仓遇见大模型，先想清楚要解决什么问题

先说结论：这个项目的核心不是“用大模型做了什么炫酷的聊天机器人”，而是把大模型当作一条数据管道里的普通算子，让它承担一类以前怎么搞都搞不干净的工作——非结构化数据的结构化。

我在某电商公司的数据团队做过一个类似的改造项目。公司内部有海量的非结构化数据：供应商合同、发票扫描件、客服工单文本、商品评论、售后备注，甚至还有一堆历史遗留的Excel和PDF报表。这些数据长期游离在数仓之外，业务部门每次要分析都得靠人工整理，提数需求排队排到半个月后。

传统的处理路线无非是两条：第一，用正则表达式和规则引擎硬解，写一个规则跑三个月，源文件格式稍微变一下，规则就废了；第二，花钱买第三方数据清洗服务，贵不说，字段映射还是得自己人肉对。

大模型嵌入数据管道后，思路完全变了。LLM承担的是“理解+转换”的角色：它读得懂异构文本，能按照预设的字段结构输出JSON，还能处理格式漂移和语义歧义。这就意味着，非结构化数据不用再走“人肉清洗进Excel再导入数仓”的旧路，而是可以在管道内部自动完成识别、抽取、标准化，直接落进数仓的贴源层、明细层。

这个方案适合谁看？两类人最适合： 一是正在被非结构化数据折磨的数仓工程师、数据分析师，天天接业务方的“帮我看看这批PDF里有哪些字段”，手抽筋的那种； 二是准备在企业内部引入大模型能力，但不确定从哪下手的技术决策者——你可以把本文的思路当成一个低风险、高复用的切入点：不是重构业务系统，而是在数据链路上加一个“聪明的转换引擎”。

2. 架构设计：为什么是把LLM“嵌入”管道，而不是“对话式”调用

2.1 聊天式接口的本质缺陷：面向人，不是面向数据

很多团队第一次接触大模型时，想到的都是“我们做个知识库问答吧”。但真实业务里，如果你给业务方一个对话框，让他们自己上传文件然后提问，本质上还是把结构化工作推回给了人。数据团队依然要处理那些“格式千奇百怪、字段藏得深、一页纸上三套口径”的文件，只是从手动变成了半自动。

嵌入管道的核心区别在于：LLM不再是终点的交互界面，而是链路中的一个转换节点。上游是文件解析器，下游是标准化的表结构，LLM在中间负责把“一段文本”映射成“一组字段”。这个位置决定了它的输出必须稳定、可校验、可重试，而不只是“看起来像那么回事”。

我见过不少团队一开始直接调大模型API做抽取，把结果往回填，跑了两周发现数据质量根本没法验收。原因很简单：聊天式输出没有强约束，模型自由发挥的空间大，字段时有时无，格式时对时错。而管道场景需要的是契约——输入什么、输出什么、失败怎么办，必须事先定义清楚。

2.2 三个可选的嵌入位置：清洗、标准化、语义校验

把LLM嵌入管道，并不是说只能放在某一个固定环节。根据项目目标不同，至少有三个可选嵌入点，它们的复杂度、成本和收益各不相同。

第一个位置是清洗阶段，也就是把原始文本变成干净的、可解析的中间格式。比如扫描版PDF先做OCR，OCR出来的文本乱七八糟：页眉页脚混在一起、表格断裂、特殊字符一堆。传统做法是写一堆后处理脚本，逐字符清理。用LLM做清洗，相当于让它“读懂”这份OCR文本，把有效内容挑出来、脏数据丢掉。这种做法适合量大但字段不太复杂的场景。

第二个位置是标准化阶段，也就是把清洗后的文本映射到预定义字段。这是我最常用的插入点，也是本文后面重点讲的部分。标准化不只是“把字提取出来”，还包括：

• 日期格式统一（“2023年4月1日”和“Apr. 1st, 2023”都变成2023-04-01）；
• 货币单位换算（“USD 1000”和“$1,000”都归一到美元分单位）；
• 同义表述映射（“客户”“甲方”“买方”归一为customer）。

这些事情让规则引擎做，每个都要写独立逻辑，而且随着业务变化不断加补丁。LLM只需要在提示词里描述清楚“你想要什么”，它就能理解变体并归一。

第三个位置是语义校验阶段，通常放在数据入仓之前。数仓的数据质量域一般有完整性、准确性、一致性等维度，但那些校验规则都是基于结构化字段设计的。对于原始文本，校验规则很难写——你不知道一份合同里“金额”到底应该出现在哪个段落、以什么形式出现。LLM可以承担语义层的检查：比如判断“这个文本片段是否覆盖了合同的关键条款”“这段客服工单里用户是否明确表达了投诉意图”。这属于锦上添花，但对某些行业（如金融审计、法务合规）来说价值极高。

2.3 方案选型：自建模型服务还是调用商用API

这是所有团队都会纠结的问题。我的建议是分阶段决策，不要一上来就自建。

第一阶段，也就是验证阶段，直接用托管API（不管是大厂云服务还是模型厂商的在线接口都好），花小钱快速验证“这条路走不走得通”。在这个阶段，你要验证两件事：一是抽取的准确率是否达到业务要求，二是延迟和成本是否在可接受范围内。

第二阶段，如果确认要长期稳定地用在核心数据链路上，再考虑自建推理服务。自建的好处是数据不出内网，且调用成本随着量增大而摊薄；坏处是GPU资源、模型部署和推理优化都需要专人维护，短期内不会比API便宜。

我在实际项目中采取的是混布方案：批量小、字段复杂度高的合同类数据走自建的专用小模型；批量大、结构相对规整的发票走API，因为API的泛化能力在处理“没见过的新版式”时更稳。混布方案的核心是“同一套管道抽象，背后接不同的模型端点”，通过一个模型网关层切换。

这里还有一个容易被忽视的点：无论自建还是用API，都要在管道里加一层缓存。同一个文件被重复处理是常有的事（业务方经常反复提交同一批文件），缓存命中可以省掉大量token费用。

3. 核心实现：一套可复用的“非结构化数据转数仓”管道

3.1 管道骨架：调度器、队列与状态管理

说回实操。我先把管道骨架搭起来，整体分五层：

文件接入层 -> 文本解析层 -> LLM抽取层 -> 校验回填层 -> 数仓写入层

文件接入层监听对象存储或FTP目录，新文件落地后触发处理；文本解析层负责把PDF、图片、Word等转换成纯文本或按页切分；LLM抽取层通过统一的网关调用模型服务；校验回填层负责把LLM输出的JSON做规则校验，失败则触发重试或人工介入；最后一层把高置信度的数据批量写入数仓。

调度器我用的是轻量级任务队列，每个文件对应一个任务，任务状态包含待处理、解析中、抽取中、校验中、已完成、需人工介入等。这个状态机是整个管道的脊柱——因为LLM调用可能超时、返回异常、结果不合格，每一环都要能重试或者退出。

状态管理这一层，新手项目最容易忽略。很多人写脚本跑批，写个for循环就完事了，一旦中间某个文件处理失败，整个批次挂掉，重跑时不知道哪些成功哪些失败。我建议把状态记录在一个简单的数据库表里，每次处理前查一下当前状态。哪怕公司没有成熟调度平台，这个状态表也能让你保住基本盘。

3.2 提示词设计：给LLM一份可执行的字段提取协议

这是整个项目里投入产出比最高的一件事。提示词写得好不好，直接决定抽取质量的上下限。

我设计提示词的思路是“把它当协议文档写，而不是当对话来写”。具体包含以下部分：

第一，角色定义。明确告诉模型它是在做数据抽取，不是聊天。“你是发票信息抽取引擎，只返回JSON”比“请帮我看看这张发票”稳定得多。

第二，字段说明。对每一个字段，说明名称、类型、允许取值和示例。不要只给一个字段名，要给“字段的语义解释”。比如total_amount的解释是“发票含税总金额，单位元，不含币种符号，不需要千分位逗号”。

第三，边界说明。告诉模型遇到什么情况必须返回什么值。比如“如果文本中不存在该字段，返回空字符串，不要猜测”“如果金额同时出现含税价和不含税价，取含税价”。这一步是抑制幻觉最直接的手段。

第四，输出约束。要求模型“只输出一个合法的JSON对象，不要Markdown，不要解释”。

我用过的最稳定的提示词结构大概长这样：

你是一个文档信息抽取引擎。请从下面OCR文本中提取指定字段，并严格按照给定JSON Schema输出。 字段定义： - invoice_no: 发票号码，字符串 - amount_total: 含税金额，字符串，数字格式，不含币种符号 - date_issued: 开票日期，格式YYYY-MM-DD 要求： 1. 只输出一个JSON对象，不要输出其他任何内容 2. 如果字段在原文中没有出现，填空字符串 3. 不要对原文缺失信息做推断 文本内容： {{TEXT}}

注意我是把Schema和示例一起放在提示词里的，这比纯文字描述稳定得多。如果模型支持函数调用（Function Calling）能力，优先用那个模式，因为模型输出的JSON结构会更规整、逃逸字符的问题也会更少。

3.3 分块处理：当文本超出上下文窗口怎么办

提示词设计好了，接下来遇到的最大拦路虎就是上下文窗口限制。一份合同动辄几十页，OCR出来几万字，直接塞进提示词肯定超限。

我的方案是“先分块、后聚合”。整体思路分两层：

第一层是文档切分。把PDF按页或按章节切成多个片段，每个片段单独过LLM，抽取该片段能确定的信息。这里有个关键设计：不是每一页都需要全量字段抽取。比如合同的前三页通常包含甲乙双方信息、合同金额、有效期；中间页是条款详情；最后一页是签章。你可以根据版面信息（每页的大小、关键词出现情况）来决定该页抽取哪些字段，这样能减少不必要的token消耗。

第二层是结果合并。多个片段的抽取结果需要合并成一个记录。合并逻辑有优先级：字段如果在前面片段中已经抽到了，后面片段的同名字段就不再覆盖；只有当前片段抽到了新字段时才写入。这个逻辑看起来简单，但能避免“同一个合同出现了三个不同金额，模型在每页抽出不同的值”这种经典问题。

分块还有一个实践层面的好处：单块失败重试的代价低。如果整个文档一次性交给模型，一旦超时或返回非法JSON，整个任务就要重来；但拆成20个块之后，哪块出了问题只重哪块，代价小一个数量级。

3.4 校验与回填：别把LLM的输出直接当真相

大模型抽取的结果，在企业数据管道里不能默认是“对的”。这跟聊天bot不同——聊天时回答错了，用户可能看两行就发现了；但数仓里的错误字段会直接污染下游报表和模型训练，而且污染是悄无声息的。所以在写数仓之前，我必定加一层规则校验。

校验分两层：硬校验和软校验。

硬校验是机器可判定的规则，比如：

• 字段是否非空（必填项有没有值）；
• 格式是否符合正则（日期、金额、邮箱）；
• 枚举值是否在允许列表中（比如“发票类型”只能是增值税专用发票、增值税普通发票等几种）；
• 数值是否在合理区间（金额大于0、日期不晚于当前时间）。

软校验则需要规则外面再接一次LLM或相似度计算，比如：“提取出的商品名称是否跟历史数据中的商品名录匹配”“这一个字段的值与其他字段的值在语义上是否冲突”。软校验的成本高一些，不需要全字段启用，只挑关键字段用。

校验不通过的数据进入“待人工复核”队列，而不是直接丢弃。我见过太多团队因为“数据不合格就丢掉”最后被业务方追着骂。正确做法是：不合格数据保留原文件路径、抽取中间结果和失败原因，给业务方提供一个简单的人工审核界面，让他们快速确认或修改。哪怕只有“通过/不通过”两个按钮，也比数据消失强得多。

3.5 数仓写入：如何兼顾批处理效率和时效性

数据通过校验之后，写入数仓的方式也需要设计。我这里的场景是：每天有几百到几千个文件需要处理，量不大但字段复杂。因此我没有走流式管道，而是用批处理，每隔固定时间（比如每10分钟）把已经完成校验的抽取结果攒成一批，批量写入。

写入前要做两件小事： 一是字段映射。LLM输出的字段名可能跟数仓表字段名不完全一样，写一个显式的映射配置，避免在SQL里大改； 二是拉链处理。如果同一个业务对象（比如同一张合同）会被多次抽取（比如文件被重新上传），在明细表后面加一列batch_id，区分不同批次的数据，这样下游报表可以只看最新批次。

写入端我用标准JDBC批量插入，性能上完全够用。如果你所在的团队有Hive或Iceberg这类数仓底座，也可以把抽取结果落成临时表，再走正常加载流程——核心是不要让LLM处理环节拖累数仓的常规写入节奏。

4. 踩坑实录：那些文档里不会写的问题排查技巧

4.1 模型“漂移”：同一段文本，今天跑和明天跑结果不一样

这是我遇到最多、也最隐蔽的问题。LLM的随机性导致它在某些边界场景下输出不稳定。可能同一个合同模板，昨天抽出来金额是10000，今天是10000.00，后天直接给你抽成“壹万元整”。

应对思路有两个：第一是把模型的temperature参数设成0。虽然模型厂商会告诉你“即使temperature=0也不是完全确定”，但至少能大幅降低随机性；第二是增加后处理归一化。我前面提的硬校验层在这里也起作用——把金额字段统一replace(',', '')，把日期字段统一parse成标准格式。永远不要在管道里假设LLM“记得”你的格式要求，它今天记得、明天可能就忘了。

4.2 幻觉字段：模型自信地输出了一堆原文里没有的东西

幻觉在抽取场景里集中表现为“补全”：原文里没有的字段，模型会根据常识填一个看起来合理的值。典型场景是合同里没有写明付款日期，模型默认填了“合同签订后30日内”。

我的排查经验是：把幻觉检测前置到提示词层面。在提示词里明确写“如果文本中没有该字段，不要填默认值，返回空字符串”。同时在校验层做一个“反向验证”：把模型的JSON输出和原文文本做一个模糊匹配，如果某个字段值在原文中完全找不到出处，则标记为待复核。

这个“字段值是否能在原文中找到”的检查方法很简单，但对拦截幻觉非常有效。我碰到过一个案例：模型从发票备注里抽出了“项目名称”，但原文的项目名称其实是藏在表格折行里的，模糊匹配确实匹配不上，后来人工去看才发现是漏了OCR断行导致匹配失败。这类边界情况需要你积累自己的“放行名单”，但大方向是对的。

4.3 成本失控：token消耗账单比外包清洗还贵

大模型嵌入管道后，成本是按token计的，往往会超出预期。我建议在管道前面加一道“成本关卡”：

第一，能不调用就不调用。在文件解析层先做一次规则预筛。文件里如果已经存在结构化字段区域（比如PDF的表格区有内嵌文本），直接用规则抽取，只有规则抽不到的内容才交给LLM。这一步能砍掉三成到一半的token量。

第二，压缩输入文本。OCR原始文本夹杂大量页眉页脚、扫描噪点，直接塞给模型等于烧钱。可以先做一轮文本预处理，去掉与目标字段无关的区域。比如抽取发票信息，就只保留包含“发票号码”“金额”“日期”关键字的邻近行。

第三，结果缓存。我前面提过缓存，这里再强调一次：给抽取结果做一层持久化缓存，以文件内容的hash为key。相同内容重复提交时直接命中缓存，不经过模型。对于经常被反复提交的同一批历史文件，效果立竿见影。

4.4 并发控制与限流：模型API老是429怎么办

把大模型API接到管道之后，会碰到的第二个经典问题是并发限流。文件多的时候，P开路冲过去大量并发调用，接口直接给你返回限流错误。

这里的排查思路是：把并发控制放在管道中间，不要指望API厂商不限制你。我在调度器里为模型调用单独加了信号量，控制同时进行的任务数；同时做退避重试——遇到429或5xx错误时，按指数退避策略重试（第一次等1秒，第二次等4秒，第三次等9秒，最多重试5次）。

还有一个容易踩的坑：超时设置。模型API在高峰期的响应时间波动很大，从几秒到几十秒都有可能。如果超时设置太短（比如5秒），大量任务会因为客户端超时被误判为失败，白白消耗重试次数。我一般把超时设置到模型库建议值的1.5到2倍，比如建议60秒，我就设90秒。宁可等待，不要误杀。

4.5 数据质量的持续观测：你需要一张“置信度仪表盘”

最后想说一件事：大模型管道的运维思路，应该跟传统ETL不同。传统ETL跑挂了立刻报警，跑通了就完事；大模型管道即使跑通了，输出也可能是错的。所以必须加一个持续的质量观测机制。

我在项目里做了一张简单的置信度仪表盘，核心指标有四个：

• 处理成功率（任务完成且通过硬校验的占比）；
• 字段抽全率（必填字段中非空的字段比例）；
• 人工复核率（被软校验标记为需人工介入的比例）；
• 缓存命中率（命中缓存省掉的调用占比）。

每个指标设置阈值，比如人工复核率超过20%就触发告警，说明当前批次的文档格式或者提示词可能出了问题。这个仪表盘不需要额外开发，直接基于管道状态表，用现成的BI工具拉两个柱状图就行。

5. 一点个人体会：这个方案还能往哪个方向延伸

我自己做完这个项目之后，最大的感受是：大模型在数据链路上的价值，远不止“聊天机器人”一个落点。它真正让人头疼的地方不在技术，而在信任机制——你怎么让下游敢用这个数据、怎么让业务方相信自动抽取的结果、怎么在模型出错时快速定位。这套“提示词约束+规则校验+人工复核+质量观测”的框架，本质上是给模型输出加了一道信任保险。

顺着这个思路，后续还能做几件延伸的事情：

第一是把LLM抽取扩展到多模态。现在处理的还主要是文本和OCR结果，但业务方手里有大量图片、扫描件、甚至视频截图里的信息。多模态模型可以直接从图片中抽字段，省掉OCR这一步，管道会更短、延迟更低。

第二是把LLM从“抽取”升级到“决策”。比如在数据分发的场景里，根据文件内容自动判断应该进入哪个数仓主题域，或者自动生成数据质量规则的推荐。这些本质上都是“让模型理解数据内容并做出合理决策”，跟抽取的底层能力是一致的。

第三是沉淀一套“提示词模板库”。每个业务方每天都在提相似的抽取需求，与其每次重新设计提示词，不如沉淀成模板库。模板库的字段定义、边界说明、校验规则都可以复用，能大幅降低新业务接入的成本。我实测下来，一套成熟的模板可以让新需求的开发时间从两周压缩到一到两天。

如果让我给还没动手的团队一个建议，那就是：别追求一步到位，先选一类你手上最痛、字段最少、量相对可控的非结构化数据（比如发票），把从文件接入到数仓写入的整条链路跑通，再去扩展复杂场景。管道一旦跑起来，你会发现业务方真正关心的并不是“用了什么模型”，而是“数据能不能按时按质地进到数仓里”。能交出这个结果，这个项目就算成功了。