企业官网建设流程全解析

简介：这份57页PPT系统梳理了大模型在辅助检索、办公与创作等场景中的落地方法，面向希望借助AI工具提升日常效率的高校学生、职场人士与内容创作者。内容从联网搜索的集成原理讲起，对比大模型检索在语义理解、生成式总结、多轮对话与模糊查询上的优势，并列举文心一言、通义千问、Kimi、ChatGPT等平台的联网开关差异；办公部分覆盖Word、PDF、Excel、PPT等场景，结合秘塔写作猫、ChatPDF等工具演示摘要生成、大纲编辑与文档问答；创作与讨论章节则进一步延伸应用边界。资源包共1个pptx文件，约21.74MB，页面结构清晰、图文并茂，便于按章节快速查阅与课堂演示。目前已有128人学习，适合作为培训课件或自学参考，帮助读者建立大模型辅助工作的整体认知框架。

1. 大模型辅助工作：57 页 PPT 背后真正能落地的技术骨架

很多人第一次看到「大模型应用大模型辅助工作（57页PPT）」这类标题，第一反应是「这不就是一份汇报材料吗」。但如果你真在一线做过大模型落地，就会知道一份 57 页的 PPT 能撑起来，靠的绝不是排版，而是背后那套「把大模型塞进日常工作流」的技术骨架。它要解决的问题很具体：写周报、整理会议纪要、批量改文案、把散落的文档变成可检索的知识库、给非技术同事一个能直接用的入口。适合谁？适合那些已经会用 API、但还没把大模型真正嵌进业务流程的开发者，也适合想评估「这套东西值不值得投入」的技术负责人。

我见过太多团队卡在同一个地方：Demo 跑得通，一到真实工作场景就翻车。原因往往不是模型不行，而是没想清楚「辅助工作」这四个字到底落在哪个环节。57 页 PPT 如果只是罗列模型能力，那是科普；如果它讲的是怎么把模型接进文档、表格、会议、检索这些具体动作里，那它就有复现价值。这一篇就顺着这个思路，把「大模型辅助工作」从概念拆到能跑的命令、能调的参数、能避的坑。

2. 把「辅助工作」拆成可执行模块：从场景到技术选型

2.1 先分清三类工作场景，别一上来就堆模型

「辅助工作」是个很虚的词，落到代码里必须先分类。我一般把它拆成三类：生成类（写初稿、改语气、扩写缩写）、理解类（摘要、分类、抽取字段）、检索类（从一堆文档里找答案）。这三类对模型的要求完全不同。生成类看重输出流畅度和指令遵循，理解类看重稳定性和结构化输出，检索类则更依赖外部向量库和召回策略，模型本身反而可以小一点。

如果你拿一个通用对话模型去硬做检索，结果就是它开始编。反过来，拿一个只会做 embedding 的模型去写周报，输出会干巴巴。所以第一步不是选模型，而是把你要辅助的工作按上面三类归位。57 页 PPT 里如果有一页在讲「场景矩阵」，那它大概率就是在做这件事。

2.2 最小可跑通链路：文档进、答案出

先给一条能跑通的最小链路，不追求效果，只验证流程。假设你有一批 Markdown 格式的工作文档，想做一个「问它答」的辅助工具。核心就三步：切分、向量化、检索后拼 prompt。

# minimal_rag.py # 依赖：pip install openai numpy import os import numpy as np from openai import OpenAI client = OpenAI(api_key=os.getenv("API_KEY")) def split_text(text, chunk_size=300, overlap=50): """按字符切分，overlap 防止语义被切断""" chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) start = end - overlap # 回退 overlap 个字符 return chunks def embed(texts): """批量向量化，注意模型名要和你账号权限匹配""" resp = client.embeddings.create( model="text-embedding-3-small", input=texts ) return [d.embedding for d in resp.data] def retrieve(query, chunks, chunk_vecs, top_k=3): """余弦相似度召回，top_k 控制拼进 prompt 的上下文长度""" q_vec = embed([query])[0] scores = np.dot(chunk_vecs, q_vec) / ( np.linalg.norm(chunk_vecs, axis=1) * np.linalg.norm(q_vec) ) idx = np.argsort(scores)[::-1][:top_k] return [chunks[i] for i in idx] # 模拟一批工作文档 docs = ["周报模板：本周完成…", "会议纪要规范：参会人…", "项目排期说明：里程碑…"] all_chunks = [] for d in docs: all_chunks.extend(split_text(d)) chunk_vecs = np.array(embed(all_chunks)) context = retrieve("周报怎么写", all_chunks, chunk_vecs) print(context)

这段代码里，chunk_size和overlap是最容易拍脑袋设错的两个参数。切太大，召回不准；切太小，语义碎。我一般从 300 字、50 字重叠起步，再根据文档类型调。top_k也不是越大越好，拼太多上下文会让模型注意力分散，3 到 5 是常见区间。向量化那步要注意，不同 embedding 模型的维度不一样，换模型必须重新算所有向量，否则相似度计算就是错的。

2.3 选型理由：为什么不是直接微调

很多人一上来就想微调，觉得那样才「深度」。但在辅助工作这个场景里，微调往往是最后才考虑的手段。原因很现实：工作文档更新频繁，今天微调完，明天流程变了，模型就过时。而检索增强的方式，你只需要更新文档库，模型不用动。另外微调需要标注数据，而「辅助工作」的标注标准本身就很主观，你很难定义什么叫「好的周报」。

常见做法是：先用 prompt 加检索把效果压到可用，再针对那些反复出错的固定格式（比如固定字段抽取）做小样本微调。57 页 PPT 如果讲到落地路径，大概率也是这个顺序。别被「大模型」三个字吓住，辅助工作的核心工程量在数据管道和 prompt 管理上，不在训练。

3. 把辅助工作接进真实流程：接口、缓存与并发

3.1 封装成内部接口，别让同事直接调模型

Demo 阶段你可以写个脚本自己跑，但要真让团队用起来，必须封装成接口。原因有三个：统一管理 API Key、统一做日志和限流、统一控制 prompt 版本。我一般用 FastAPI 起一个薄薄的服务层，把模型调用藏在后面。

# service.py from fastapi import FastAPI from pydantic import BaseModel import hashlib, json, redis app = FastAPI() r = redis.Redis(host="localhost", port=6379, db=0) class AskReq(BaseModel): user_id: str query: str scene: str # weekly / meeting / search def cache_key(scene, query): """用场景加查询内容做缓存键，避免不同场景互相污染""" raw = f"{scene}:{query}" return "llm:" + hashlib.md5(raw.encode()).hexdigest() @app.post("/ask") def ask(req: AskReq): key = cache_key(req.scene, req.query) cached = r.get(key) if cached: return {"from_cache": True, "answer": cached.decode()} # 这里接上一节的 retrieve + 模型调用 answer = call_llm(req.scene, req.query) r.setex(key, 3600, answer) # 缓存 1 小时 return {"from_cache": False, "answer": answer}

缓存这层看着简单，但它是辅助工作能不能扛住多人用的关键。同一个问题同事问三遍，没必要调三次模型。setex的过期时间按场景定：会议纪要这种时效性强的，缓存 10 分钟就够；制度类问答可以缓存几小时。注意缓存键一定要带scene，否则「总结一下」这种通用 query 会把不同场景的答案串在一起，这是血泪经验。

3.2 并发与限流：别让一次批量任务打爆配额

辅助工作里经常有批量场景，比如一次把 50 篇文档全部摘要。如果你直接 for 循环同步调，速度慢还容易触发限流。常见做法是用并发加信号量控制。

import asyncio from asyncio import Semaphore sem = Semaphore(5) # 最多 5 个并发，按你的配额调 async def summarize_one(doc): async with sem: # 这里换成你的异步模型调用 await asyncio.sleep(0.5) return doc[:20] + "..." async def batch_summarize(docs): tasks = [summarize_one(d) for d in docs] return await asyncio.gather(*tasks)

Semaphore(5)这个数字不是随便写的。你要先看账号的 RPM（每分钟请求数）限制，再除以你预估的单次耗时，留出余量。设太大，触发 429；设太小，批量任务跑得让人想砸键盘。我一般从 3 到 5 起步，观察日志里有没有限流报错再往上加。另外批量任务一定要做断点续跑，别跑了一半失败全部重来，那是纯浪费。

3.3 prompt 版本管理：改坏了要能回滚

辅助工作里 prompt 就是业务逻辑。今天你觉得加一句「请用正式语气」效果更好，明天可能发现它把摘要也改得死板。所以 prompt 必须版本化，不能直接写死在代码里。

把 prompt 存在配置表或文件里，每次调用带上版本号，出问题能立刻切回上一版。这个习惯在多人协作时尤其重要，否则你永远不知道线上跑的是谁改的哪一版。

4. 避坑与排查：辅助工作落地时最容易翻车的五件事

4.1 现象：模型输出格式忽好忽坏，解析直接报错

原因通常是 prompt 里对输出格式的约束不够硬，模型在「自由发挥」和「遵守格式」之间摇摆。解决方式是给出明确的 JSON schema 示例，并在解析层做容错，比如用正则先提取 JSON 块，再尝试解析。别指望模型 100% 听话，解析代码必须假设它会出错。

4.2 现象：检索出来的内容答非所问

先查切分粒度。如果一段话被从中间切断，向量就会失真。再查 embedding 模型是否和文档语言匹配，用英文模型处理中文文档，召回率会明显下降。最后看top_k，太小漏召回，太大引入噪声。我一般会打印每次召回的原文，肉眼确认是不是真的相关，这一步比调参有用。

4.3 现象：批量任务跑到一半卡死

多半是并发设太高触发限流，或者某个请求超时没有设置。解决：给每个请求加超时，用asyncio.wait_for包一层；并发数从低往高试；记录失败任务单独重试。别让一个坏请求拖垮整批。

4.4 现象：同事反馈「答案和昨天不一样」

检查缓存是否过期、prompt 是否被改过、模型版本是否被服务方静默升级。这三个是常见变量。辅助工作要的是稳定预期，所以任何变更都要记录，最好在接口返回里带上版本信息，方便排查。

4.5 现象：成本比预期高很多

先看是不是缓存没生效，重复查询全打到模型。再看 prompt 是不是太长，把整篇文档都塞进去。检索增强的意义就是只拼相关片段，不是拼全文。最后看模型选型，简单分类任务用大模型是浪费，换小模型能省一大截。

5. 进阶技巧：用评测集把「感觉还行」变成「有数」

辅助工作最怕的就是「感觉还行」。要让它真正可信，得建一个小评测集。不用多，20 到 50 条就够，覆盖你最常见的场景。每条包含输入和期望输出的关键点，然后写个脚本自动跑分。

# eval.py cases = [ {"scene": "weekly", "input": "本周修了三个 bug", "must_contain": ["bug", "本周"]}, {"scene": "meeting", "input": "讨论了排期", "must_contain": ["排期"]}, ] def score(answer, must_contain): """命中关键点得分，简单但够用""" hit = sum(1 for k in must_contain if k in answer) return hit / len(must_contain) total = 0 for c in cases: ans = call_llm(c["scene"], c["input"]) s = score(ans, c["must_contain"]) total += s print(c["scene"], s) print("平均分", total / len(cases))

这个评测很粗糙，但它能帮你回答一个关键问题：改了 prompt 之后，效果是变好还是变坏。没有这个数，你就是在凭感觉调，迟早翻车。我一般会在每次 prompt 变更后跑一遍，分数掉了就回滚。另外评测集要定期补充那些线上出过错的 case，让它越来越贴近真实。

最后一个习惯：任何辅助工作的输出，都要保留「人工确认」这一步。大模型是辅助，不是替代。把它的输出当成初稿，而不是终稿，这样即使它偶尔犯错，也不会造成实际损失。希望帮到你。

本文还有配套的精品资源，点击获取