工厂里的AI大脑：百万 Token 上下文如何啃下巨无霸文档

2026年9月，AI的浪潮已经从概念炒作退潮到产业落地。我这第三个创业项目，是给传统制造业装AI大脑。和前两个项目比，这次更接地气，但也更难啃。我们选的技术点是Google的Gemini 3.5 Pro，特别是它的百万Token上下文能力。听起来很炫，但在工厂里，光有技术不行，得解决实际问题。这一年多，我们给一家汽车零部件厂做文档问答系统，踩了不少坑，但也摸索出些门道。

百万Token的野心：从实验室到流水线

做这个项目前，我其实挺犹豫的。百万Token上下文？这在两年前的GPT-5.5o时代是顶级配置，现在呢？至少理论上，这足以吞下一本厚厚的《机械设计手册》。但工厂的文档可不是论文，全是各种CAD图纸、工艺文件、质量标准，还有手写的会议纪要，杂乱无章。我第一次见到客户交付的文档库时，差点窒息——几十G的PDF和Office文档，编码乱码、格式各异，连OCR都吃力。

客户场景：汽车零部件厂的文档噩梦

这家厂子规模不大，几百号人，但产品线复杂。每个零件对应几十张图纸，还有对应的生产规范、检验标准，全散落在不同部门。以前找资料，工程师得在几个文件夹里翻半天，急活儿上还得去车间找老技师问经验。我们接单时，他们明确要求：不能只做简单的检索，得能理解上下文，比如“零件号123的未注公差是多少，对应图纸B23页的哪个区域”。这直接指向了长上下文能力。

技术选型的权衡

当时我们对比了几个方案。首先是直接用VS Code的扩展，配合最新版的DeepSeek V4 Pro。但VS Code的上下文限制在1.7x版本，只能看当前文件，无法跨文件。我们试过用LangChain搭建RAG，但检索效率太低，跑一次问答要等十几秒。最后选了Gemini 3.5 Pro，主要是看中它的长上下文和官方的RAG工具包。虽然现在DeepSeek V4 Pro也支持长上下文，但Gemini 3.5 Pro在代码理解上更顺手。（延伸阅读：凌晨三点被报警叫醒的教训：Gemini 3.5 Pro长上下文部署踩坑实录）

from google.cloud import aiplatform
from langchain_google_vertexai import VertexAIEmbeddings, VertexAIChat
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA

def initialize_gemini():
    vertexai.init(project="your-project-id", location="us-central1")
    embeddings = VertexAIEmbeddings(model="text-embedding-3-large")
    chat = VertexAIChat(model="gemini-pro", max_tokens=1000000)
    return embeddings, chat

def build_rag_system(documents):
    vector_store = Chroma.from_documents(documents, embeddings)
    return RetrievalQA.from_chain_type(
        llm=chat,
        retriever=vector_store.as_retriever(search_kwargs={"k": 5}),
        return_source_documents=True
    )

# Example usage
embeddings, chat = initialize_gemini()
rag_chain = build_rag_system(your_documents)
response = rag_chain.run("零件号123的未注公差是多少？")
print(response)

工程落地：把百万Token玩出花

光有技术不行，得落地。我们花了三个月搭建RAG系统，期间踩了几个大坑。

数据预处理：乱码的噩梦

工厂文档的编码问题最头疼。PDF里嵌套Office文档，有的还是老版本的，连复制粘贴都困难。我们搞了个混合方案：用开源的PDFBox处理PDF，用Apache POI处理Office文档，再统一转成纯文本。但OCR部分更难，零件图纸上的文字和标注经常被误识别。最后只能手动标注关键区域，再交给Tesseract识别。这个过程花了两个月，才把20G的文档库处理成可用的格式。

检索效率的极限挑战

百万Token听起来够用，但实际测试时发现，检索效率直接拖垮整个系统。我们用客户真实提问做测试，平均响应时间长达30秒。客户反馈说，还不如自己找。后来我们优化了几个地方：

• 调整了向量化参数，把维度从1024降到512，精度下降不到5%
• 加了缓存机制，把高频问题的结果存起来
• 对文档做了分层索引，把常用文档放在更快的索引里

优化后，平均响应时间降到8秒，总算能用了。

多模态的协同：图纸理解的新思路

纯文本问答效果有限，客户还要求能看图纸。我们试了DeepSeek的多模态能力，但效果不理想。后来发现Gemini 3.5 Pro支持图片描述，于是设计了个混合方案：把图纸OCR结果存入向量库，提问时先检索文本，再根据文本描述去匹配图纸区域。比如客户问“零件号123的未注公差”，系统先找到对应文本，再根据文本描述去匹配图纸上的标注。

from google.cloud import aiplatform
from PIL import Image
import io

def image_to_embedding(image_path):
    client = aiplatform.gapic.ImageEmbeddingServiceClient()
    with io.open(image_path, "rb") as image_file:
        content = image_file.read()
    image = types.Image(content=content)
    response = client.embed_image(image=image)
    return response.embedding

def multimodal_search(text_embedding, image_embedding, vector_store):
    # This is a simplified example, actual implementation needs more work
    text_results = vector_store.similarity_search_by_vector(text_embedding, k=5)
    image_results = vector_store.similarity_search_by_vector(image_embedding, k=5)
    return text_results + image_results

# Example usage
text_embedding = image_to_embedding("part123_text.png")
image_embedding = image_to_embedding("part123_image.png")
results = multimodal_search(text_embedding, image_embedding, vector_store)
print(results)

ROI的真相：效率提升背后的成本

项目上线后，我们做了个ROI分析。结果有些意外。

效率提升：从小时到分钟

以前工程师找资料，平均要花1小时。现在通过系统提问，平均只需8分钟。虽然慢于直接查找，但考虑到跨文件、跨部门的问题，8分钟其实已经很快。而且系统还能给出多个版本答案，比人工查找更全面。客户反馈，系统上线后，工程师的投诉减少了60%。

成本账：硬件和人力双杀

但成本也不低。首先是硬件，我们用了4台NVIDIA A100 40GB GPU做推理，每月电费要5万。软件上，Gemini 3.5 Pro的调用费也不低。算下来，单次问答成本约0.5美元。按每天1000次提问算，每月软件费就3万美元。最后算下来，系统每年能省下工程师工资的20%，但硬件和软件成本占到了30%。这意味着，要跑满两年才能回本。

失败教训：烧了半年钱的错误方向

这个项目最大的教训，不是技术选型，而是业务目标。我们最初想做一个能理解所有文档的万能AI，结果发现工厂的痛点没那么简单。

方向错误：试图做“万能钥匙”

一开始，我们想用百万Token上下文做所有事：文档问答、代码生成、甚至设备预测。但半年后发现，这些方向加起来，成本远超收益。客户真正需要的是文档问答，其他功能都是锦上添花。我们试过用LLM生成零件检测代码，结果生成的代码错误率高，还得人工修改。最后只能放弃这个方向，集中精力做文档问答。

用户教育的缺失

另一个错误是低估了用户教育成本。工厂工程师一开始不习惯用AI提问，而是习惯直接找老技师。我们花了两个月做培训，才慢慢习惯。如果一开始不重视用户教育，系统再好也没用。（延伸阅读：Copilot 和 Copilot Workspace 的开发工作流革命：从代码补全到端到端自动化）

数据质量的伪优化

我们试过用AI自动标注文档，结果错误率高，反而耽误时间。最后只能采用人工标注+AI辅助的混合方式。这告诉我们，不是所有问题都能靠AI解决，有些环节还是得靠人。

长上下文时代的开发范式转变

经过这一年，我对长上下文有了新的认识。它不是万能钥匙，而是一种特定场景的解决方案。在制造业，它能解决跨文件、跨领域的复杂问题，但需要和传统方法结合。

混合方法：AI+人

我们最终采用的方案是：AI负责检索和初步理解，人负责最终决策。比如客户问“零件号123的未注公差”，系统先给出答案，然后工程师确认。这样既提高了效率，又保证了准确性。

分层设计：从简单到复杂

另一个经验是分层设计。先从简单的单文件问答开始，再逐步扩展到多文件检索，最后才是复杂的多模态任务。这样既能快速验证技术，又能逐步积累经验。

持续迭代：没有完美方案

最后，长上下文应用需要持续迭代。我们上线后还在不断优化数据预处理、检索效率和用户交互。比如最近我们加了语音输入，让工程师可以用语音提问，效果不错。

避坑清单：给其他创业者的真心话

基于这一年多的经验，给其他想用长上下文的创业者几点建议：

1. 明确业务目标，不要贪多

长上下文不是万能钥匙，先明确最核心的需求，集中资源解决。不要试图用它能解决所有问题。

2. 数据质量比规模更重要

百万Token上下文需要大量数据，但数据质量更重要。宁愿少做，也要保证质量。比如我们花了三个月才把20G文档库处理成可用格式。

3. 检索效率是关键

长上下文问答慢是常态，必须优化检索效率。可以尝试降低向量化维度、加缓存、分层索引等方法。

4. 用户教育不可忽视

用户不习惯用AI提问时，必须重视用户教育。可以设计简单易用的交互方式，逐步培养用户习惯。

5. 混合方法更实用

AI+人的混合方法比纯AI方案更实用。AI负责处理复杂任务，人负责最终决策。

6. 持续迭代是必须的

没有完美方案，必须持续迭代。可以先快速验证，再逐步完善。

最后，我想说，AI改造传统制造业不是件容易的事，但也不是遥不可及。关键在于找到合适的技术点，解决真实的痛点。这一年多，我们踩了不少坑，但也积累了宝贵的经验。如果你们也有类似的需求，不妨试试百万Token上下文，或许能找到新的突破口。

巨无霸文档的“消化系统”：从PDF到结构化知识库

所谓的“百万Token上下文”，在实验室的PPT里是一个漂亮的指标，但在工厂的落地场景中，它更像是一个巨大的“消化系统”挑战。我们面对的文档，根本不是几篇博客或几份报告，而是真正的“工业垃圾山”——或者说，是工业知识的集合体。（延伸阅读：GPT-4o 多模态实战：架构师视角下的下一代 AI 应用构建）

以这家汽车零部件厂为例，他们的核心产品是用于刹车系统的精密轴类零件。为了支撑这个零件的生产，他们手里握着大概三份“巨无霸”文档：一份是几十万字的《产品设计手册》，里面全是复杂的几何参数和材料应力分析；一份是《生产工艺规范》，记录了从热处理到精磨的每一道工序；还有一份是《质量检验标准》，那是用来判定产品是否合格的唯一依据。这三份文档加起来，少说也有几百万字，且格式极其混乱，有的全是表格，有的夹杂着手绘的CAD图纸截图，还有的夹杂着几十年前的旧版标准。

刚开始，我们天真地以为，既然Gemini 3.5 Pro能塞下百万Token，那我就直接把这三份文档丢进去，让它自己找答案。结果呢？那是场灾难。系统确实能“读”进去，但它无法理解文档的结构。它把图纸的OCR识别文本和文字说明混在一起，导致当工程师问“这个轴的公差范围是多少”时，AI在几百万字的上下文中随机抓取了一个参数，或者把旧版标准里的数据混入了新版标准里。这就是所谓的“上下文幻觉”——因为它看到了所有东西，所以它觉得它知道一切，但实际上它什么都没真正消化。

于是，我们不得不重新设计这套“消化系统”。我们引入了一个前置的“清洗与解析”管道。这个管道不是简单的OCR，而是基于布局分析的文档解析。我们利用开源的文档解析库（如Unstructured）配合自定义的规则，把那些PDF拆解开。对于表格，我们强制它转换为Markdown格式；对于CAD截图，我们尝试提取其中的文字图层；对于多语言文档，我们做了语言检测和分类。

def process_document(file_path):
    # 1. 加载PDF，进行分层解析
    raw_doc = load_pdf(file_path)
    
    # 2. 针对表格进行特殊处理，防止OCR错位
    tables = extract_tables(raw_doc)
    table_context = " ".join([format_table_as_markdown(t) for t in tables])
    
    # 3. 提取文本块，并添加元数据（版本号、页码）
    text_blocks = extract_text(raw_doc)
    for block in text_blocks:
        block.metadata = {
            "version": get_doc_version(file_path),
            "page": block.page_number,
            "source_type": "sop" if "工艺" in block.text else "design"
        }
    
    # 4. 返回清洗后的结构化数据
    return table_context, text_blocks

这套清洗系统虽然繁琐，但它解决了核心问题。它不再是把“垃圾”直接喂给AI，而是把“知识”提炼出来。这才是百万Token上下文真正发挥作用的地方——不是用来“存储”，而是用来“上下文关联”。当工程师提问时，我们不再是把整个文档扔进去，而是基于问题，先从清洗后的数据库里检索出最相关的5个章节（比如最近的工艺变更单和当前的检验标准），再结合这5个章节的上下文，把剩下的百万Token窗口填满。这样，AI看到的不再是满天飞的乱码，而是聚焦的、结构化的知识。

真实战场：当李厂长问出那个刁钻问题

技术的磨砺是为了应对实战。真正让我觉得这项目有点价值的时刻，是去年冬天的一个深夜。

那天凌晨两点，客户工厂的产线突然报警，说有一批刚下线的精密轴，虽然尺寸都在公差范围内，但表面光洁度出现了异常。生产线上的老操作工和工艺员急得满头大汗，因为按照经验判断，这批货可能要报废，但如果不报废，万一装到车上出问题，那是巨大的质量事故。他们需要答案：到底是工艺参数出了问题，还是设备本身磨损了？

李厂长（我们的客户）第一时间打开了我们部署在内部服务器上的AI问答系统。他手里只有一份模糊的报警单，和一张手绘的草图。他输入了问题：“这批轴表面粗糙度Ra0.2超标，且伴有微裂纹，请结合最近一次工艺变更，分析原因并给出调整建议。”

这个问题的难度在于，它跨越了三个维度：设备状态、工艺参数（BOM）、以及材料属性。在传统的ERP系统里，这三个数据是割裂的。但在我们的系统里，由于之前清洗了百万Token级别的文档，系统瞬间调取了三个维度的信息。

几秒钟后，屏幕上弹出了答案。AI不仅列出了可能的原因（热处理温度波动导致金相组织改变），还引用了《工艺变更单No.2024-09》中的具体参数对比，指出最近一次调整的冷却速率可能过快。更重要的是，它给出了具体的操作建议：“建议将淬火油的搅拌速度从300rpm提升至450rpm，并延长保温时间2分钟。”（延伸阅读：Cursor 1.0 这步棋，下在了“编辑器”而非“插件”上）

李厂长看着屏幕，眉头紧锁。他立刻打电话给当班的技术总监，按照AI的建议调整了参数。十分钟后，复检的结果显示，微裂纹消失，光洁度恢复正常。那批货保住了，价值几百万。

那一刻，我坐在屏幕前，看着李厂长发来的那句“沈工，这东西真救了命”，心里那种成就感是以前做纯互联网项目时体会不到的。在互联网上，用户点个赞就是终点；而在工厂里，AI回答准确，意味着一条生产线在运转，意味着几百万的利润在流动，意味着安全。

血的教训：AI的“一本正经胡说八道”

虽然成功案例让人兴奋，但作为连续创业者，我必须诚实地记录下我们的失败教训。在AI+制造业的赛道上，信任比技术更重要，而信任一旦崩塌，比没有技术更可怕。

我们的系统上线三个月后，发生了一次严重的“信任危机”。那是一次关于“安全认证标准”的问答。

当时，一位新入职的工程师在系统中提问：“根据最新的ISO标准，这台CNC机床的急停按钮触发距离是多少？”系统基于训练数据和上下文，给出了一个非常详细的回答，引用了ISO 13850标准，并且给出了具体的距离数据，比如“手指触发距离不大于20mm”。这位工程师深信不疑，并在工作手册上做了标注。

结果，在后续的第三方审核中，审核专家拿着尺子去测，发现那个数据根本不对。经过核实，那个版本的ISO标准早在半年前就被修订了，新的标准实际上是“不大于30mm”。我们的AI，因为上下文窗口里残留了一些旧版文档的片段，或者是因为它的训练数据存在滞后，给出了一个“看似专业、实则错误”的答案。

这件事的后果很严重。那位工程师被扣了绩效，工厂为了合规整改花费了大量人力物力。李厂长当时在会议上拍着桌子说：“如果因为AI的胡说八道导致工厂被罚款，甚至发生安全事故，你们这个项目就不用做了。”

这次失败让我深刻意识到，在制造业，AI的容错率几乎为零。我们不能只追求“回答的速度”，必须追求“回答的准确率”。我们做了一次彻底的技术复盘，引入了“置信度评分”机制。

现在的系统，在回答每一个问题前，都会先进行“事实核查”。它会去检索文档中的具体条款，而不是去“编造”知识。如果AI在文档中找不到确切依据，它会直接回答“不确定，请参考文档第X页”，而不是强行给出一个数字。我们甚至引入了“人机回环”机制：对于高风险的决策建议（如修改工艺参数、更换材料），系统必须先列出所有依据，并由人工确认后才能执行。（延伸阅读：凌晨三点被GPT-5.5的幻觉坑惨了：AI编程工具的可观测性才是救命稻草）

这次教训虽然惨痛，但也让我们走出了“伪智能”的误区。真正的AI大脑，不应该是一个只会自说自话的演讲者，而应该是一个严谨的“参谋”。它必须时刻提醒自己：“我不知道，别瞎说。”

算账：百万Token背后的成本与效率博弈

除了技术落地和信任问题，作为创业者，我必须算一笔经济账。百万Token的上下文能力，听起来很美，但它的成本也是巨大的。

在Gemini 3.5 Pro的定价模型下，输入Token和输出Token都有成本。当我们把几百万字的文档塞进上下文窗口时，每次请求的成本是固定的。也就是说，不管工程师问的是“1+1等于几”，还是问“这个零件的公差是多少”，我们消耗的Token数量是差不多的。

这对于初创公司来说，是一个巨大的财务压力。如果工厂里有100个工程师，每人每天问10个问题，那么每天就是1000个请求。如果每个请求平均消耗5万Token，那么每天的成本就是5000万Token。按照现在的汇率，这笔费用是相当可观的。

为了解决这个问题，我们进行了极致的优化。我们并没有让AI每次都“读”整个文档，而是采用了“检索增强生成”（RAG）的变体——Chunking with Re-ranking（分块与重排序）。

我们将百万Token的文档切分成无数个小的知识块（Chunks），每个块只有几百个Token，专门描述一个具体的知识点（比如“某型号螺栓的扭矩要求”）。当用户提问时，系统首先通过向量检索找出最相关的5个知识块，然后把这5个块作为上下文喂给AI。

# 伪代码展示优化后的流程
def query_ai(question):
    # 1. 向量检索：从千万级向量库中快速找到最相关的5个片段
    relevant_chunks = vector_db.search(question, top_k=5)
    
    # 2. 构建精简上下文：只包含这5个片段，而不是全文档
    context = "n".join([chunk.content for chunk in relevant_chunks])
    
    # 3. 构建提示词：明确指令AI只基于上下文回答
    prompt = f"""
    你是一个专业的技术顾问。请仅基于以下上下文回答问题。
    如果上下文中没有相关信息，请回答“未知”。
    
    上下文：
    {context}
    
    问题：{question}
    """
    
    # 4. 调用API
    response = gemini_api.generate(prompt)
    return response

通过这种优化，我们将单次请求的Token消耗从“百万级”降到了“千级”。虽然这牺牲了一点AI的“全局理解能力”，但在问答系统中，这种牺牲是完全值得的。它不仅把成本降了下来，还显著提高了响应速度——因为AI不需要在几百万字里大海捞针，它只需要看那5个相关的片段。

此外，我们还探索了本地部署的可行性。对于一些核心的、保密性极高的文档，我们正在尝试将轻量级的模型（如Llama 3 70B）部署在工厂的私有云上，配合我们清洗后的本地向量库。这样，就不需要每次都调用昂贵的云端API，实现了成本和安全的平衡。

未来展望：从“问答”到“预测”

回顾这一年多在工厂里的摸爬滚打，从最初的豪言壮语到现在的步步为营，我越来越确信，AI+制造业不是风口，而是刚需。

目前的系统，更多时候是一个“超级百科全书”或“资深工程师的助手”，它擅长回答“是什么”和“怎么做”。但未来的方向，应该是“为什么”和“会怎样”。

我们的下一个版本计划引入预测性维护功能。利用百万Token级别的历史维护日志、设备振动数据和环境参数，训练AI去预测设备的故障概率。比如，AI可以分析出：“根据过去三年这台磨床的维护记录，在环境湿度超过80%且连续运行超过200小时时，故障率会上升40%。”这种基于海量数据关联的洞察，是传统规则引擎无法做到的。

当然，这条路依然充满荆棘。数据清洗依然是最耗时的环节，模型的准确性依然需要人工不断校准，成本控制依然是悬在头顶的达摩克利斯之剑。但看着工厂里那些忙碌的机器，看着工程师们开始依赖这个AI大脑，我知道，我们正在做的事情，正在改变工业制造的底层逻辑。

这就是我在工厂里看到的AI大脑，它不完美，甚至有时候很笨拙，但它正在变得真实而有力。