资深 AI 售前解决方案工程师 · AI 技术理解与实践作品集

作者壹生有多逺

资深 AI 售前解决方案工程师 · AI 技术理解与实践作品集

这份文档用于个人技术作品集展示，从资深售前解决方案工程师（AI / 云计算方向）视角，系统梳理大模型时代的核心技术体系、工程实践与岗位方法论。
文中所有项目均做脱敏处理，企业名称以行业标签替代；能力数据截至 2026 年中，模型参数与榜单会随版本迭代变化，读者请以各厂商官网实时信息为准。

导读

这份手册不是论文综述，而是我在客户会议室里经常用到的”技术底稿”。每节大致按”它是什么 → 原理 → 对客户有什么用 → 我做过哪些项目”展开，目标是把每个技术点都讲成客户能听懂、能算账的东西。你可以先从第二部分的岗位思考读起，建立判断框架；也可以直接跳到对应技术主题，拿去支撑具体方案。

AI 技术栈全景（文字图）

大模型应用的技术栈可自上而下理解为五层，售前方案设计本质上是为客户选对每一层：

┌────────────────────────────────────────────┐
│ 应用层：对话 / 问答 / 写作 / 多智能体业务流   │
├────────────────────────────────────────────┤
│ 编排层：Agent Harness / Workflow / Loop    │
├────────────────────────────────────────────┤
│ 增强层：RAG / 知识图谱 / GraphRAG / 上下文工程 │
├────────────────────────────────────────────┤
│ 模型层：预训练基座 / 微调(LoRA) / 推理优化    │
├────────────────────────────────────────────┤
│ 底座层：算力(GPU/NPU) / 数据治理 / 安全合规   │
└─────────────────────────────────────────┘
  • 底座层决定”能不能跑、合不合规”——算力与数据安全是政企项目的门槛；
  • 模型层决定”聪明不聪明”——选对基座、用对微调；
  • 增强层决定”懂不懂你的业务”——RAG 与图谱让通用模型接上私有知识；
  • 编排层决定”能不能办事”——Agent 与 Workflow 把能力串成流程；
  • 应用层决定”客户感知到什么价值”——最终落在业务指标上。

理解这五层，售前就有了和客户从 CTO 聊架构、和 CFO 聊 TCO、和业务主管聊指标的统一语言。

目录

第一部分：技术主题

1. Transformer 架构

核心概念阐述

Transformer 是 2017 年 Google 在《Attention Is All You Need》中提出的序列建模架构，彻底摒弃了 RNN / CNN 的递归与卷积结构，完全基于自注意力（Self-Attention）机制并行处理序列。它是当今几乎所有大语言模型（GPT、Claude、Gemini、Qwen、DeepSeek 等）的共同基石。理解 Transformer，是理解”为什么现代 AI 能读懂上下文、记住前文、做长文档摘要”的总钥匙。

技术原理

Transformer 由编码器（Encoder）与解码器（Decoder）堆叠而成。编码器擅长”理解”（如分类、抽取），解码器擅长”生成”（如对话、写作）。GPT 系列只用解码器，BERT 只用编码器，T5 用完整结构。

其核心是缩放点积注意力（Scaled Dot-Product Attention）：

$$ \text{Attention}(Q,K,V) = \text{softmax}\left( \frac{QK^T}{\sqrt{d_k}} \right) V $$

其中 $Q$（Query）、$K$（Key）、$V$（Value）由输入向量经线性变换得到，$d_k$ 为 Key 的维度。除以 $\sqrt{d_k}$ 是为了防止点积结果随维度增大而过大，导致 softmax 梯度消失、训练不稳定。

多头注意力（Multi-Head Attention）将注意力并行分为 $h$ 个头，让模型在不同子空间同时关注不同类型的关系（语法、指代、长距离依赖）：

$$ \text{MultiHead}(Q,K,V) = \text{Concat}(\text{head}_1, \dots, \text{head}_h) W^O $$

$$ \text{head}_i = \text{Attention}(QW_i^Q, KW_i^K, VW_i^V) $$

位置编码（Positional Encoding）弥补了注意力本身对词序不敏感的缺陷。原始论文使用正弦 / 余弦函数；现代大模型多采用旋转位置编码（RoPE），它把位置信息编码进 Query 与 Key 的旋转中，明显增强长上下文外推能力。前馈网络（FFN）则在每个位置独立做非线性变换，是模型”存储知识”的主要参数所在。

注意力的直觉理解

注意力可以理解为”加权抄写”：对每个输出位置，模型计算它与所有输入位置的关联强度（softmax 后的权重），再按权重把对应位置的 Value 加权求和。关联越强，抄得越多。这带来一个直观结论——模型回答某个词时，”看”了哪些上下文，是可以被可视化的。这种可解释性在售前很有用：当客户质疑”AI 凭什么这么判断”，我们可以把注意力热力图摆出来，证明它的判断建立在相关上下文而非随机生成上。这在运维、风控等可靠证据要求的场景，是建立信任的利器。

为什么它是现代 LLM 的基石

  1. 并行性：抛弃时序递归，训练可大规模并行，使”在万亿 token 上预训练”成为可能；
  2. 长程依赖：注意力直接连接任意两个位置，解决了 RNN 的梯度消失与信息遗忘；
  3. 统一框架：文本、图像（ViT）、语音、视频均可映射为 token 序列进入同一架构，催生多模态大模型；
  4. 可扩展：参数量与数据量可随算力线性放大，符合”规模即能力”的缩放律。

售前场景中的价值定位

对客户而言，Transformer 不是技术名词，而是三件事的答案：“为什么你的 AI 能理解上下文””为什么它能记住前文””为什么多模态能统一”。在方案沟通中，我用它解释：
– 并行训练 → 大规模语料可行 → 这是模型”知识广”的来源；
– 注意力机制 → 长依赖建模 → 解释合同、论文、代码跨文件引用的理解能力；
– 架构统一 → 多模态收敛 → 降低客户未来集成不同 AI 能力的复杂度。

售前常见误区

  • 误区：”Transformer 越深越好。”——实际深度需与数据、算力匹配，过深易训练不稳定。
  • 误区：”注意力就是全部。”——FFN 才是参数与知识的主要载体，二者缺一不可。

项目经验（脱敏）

在某智慧园区的视频监控智能运维项目中，我们需要将海量视频转码告警日志与工单文本做关联分析。客户最初质疑”传统规则引擎能否替代”。我以 Transformer 的注意力可解释性为切入点，演示模型如何自动聚焦于”同一视频 + 同一时段 + 相似告警码”的上下文模式，最终支撑 LLM + LoRA 方案上线，使平均故障修复时间（MTTR）下降约 70%。这里 Transformer 是让”非结构化运维文本”变得可被模型理解的前提，也是后续一切智能运维能力的底座。

2. RAG 检索增强生成

核心概念阐述

RAG（Retrieval-Augmented Generation）将”检索”与”生成”结合：先根据用户问题从知识库检索相关片段，再将其作为上下文喂给大模型生成答案。它的核心价值是用外部知识弥补模型参数知识的时效性、私有性与准确性短板，是企业在”不想重训模型”前提下上线大模型的最主流路径，也是我经手项目中使用频率最高的技术。

技术原理

典型 RAG 流水线包含离线索引与在线查询两个阶段：

  • 离线索引：文档切分（Chunking）→ 向量化（Embedding）→ 写入向量库（如 Milvus、pgvector、Elasticsearch）。
  • 在线查询：问题向量化 → 相似度检索（top_k）→ 重排（Re-rank）→ 拼接 Prompt → 大模型生成。

检索阶段常用余弦相似度衡量语义接近度：

$$ \text{sim}(a,b) = \frac{a \cdot b}{|a| |b|} = \frac{\sum_i a_i b_i}{\sqrt{\sum_i a_i^2} \sqrt{\sum_i b_i^2}} $$

进阶架构还会引入混合检索（向量 + 关键词 BM25）、父子分块（parent-child chunking）、查询改写（Query Rewriting）与重排模型（Cross-Encoder），层层提升召回质量。

售前场景中的价值定位

RAG 是售前沟通的”第一张王牌”——它直接回应客户最关心的三个问题：“怎么用上我们自己的数据？””怎么保证不乱编？””成本可控吗？” 相比微调，RAG 无需 GPU 训练集群、知识更新只需改文档、答案可溯源，是企业级 AI 上线门槛最低的方案。

适用场景与局限性

维度 适用场景 局限性
知识时效 政策、产品手册、内部制度频繁更新 检索质量很依赖切分与 Embedding 质量
可溯源性 金融 / 政务 / 医疗等强合规行业 多跳推理、跨文档综合容易丢信息
成本 中小知识规模、预算有限 超长上下文下检索噪声会被放大
实时性 接数据库 / API 的动态问答 需保证检索链路低延迟

客户常问与应答

  • Q：”RAG会不会还是乱编？”A：”检索到的片段会作为证据注入Prompt，并配合忠实度评测；但仍需设置’无证据则拒答’的护栏。”
  • Q：”文档更新麻烦吗？”A：”增量索引即可，无需重训，这是RAG相对微调最大的运维优势。”

项目经验（脱敏）

在某新能源储能平台企业的智能问答项目中，我们面对 12+ 类文档格式（PDF、Word、Excel、扫描件、网页），构建RAG知识库。关键工程决策是内容感知分块（parent-child chunking）——父块保语义完整、子块保检索精度，配合 MD5 增量索引避免重复解析。最终自动应答覆盖率达70%+，把人工客服从重复咨询中解放出来。这一项目成为我向政务客户讲解”RAG 不是玩具，是生产系统”的标杆案例，也验证了”检索质量决定天花板”这一铁律。

3. 知识图谱

核心概念阐述

知识图谱（Knowledge Graph, KG）以”实体—关系—实体“三元组（Subject-Predicate-Object）结构化表达领域知识，本质是把人类专家的认知网络显式沉淀为机器可查询的图。与大模型的隐式参数知识互补：图谱强在精确关系与可推理，模型强在泛化与语言生成。

技术原理与架构模式

  • 构建：实体抽取（NER）→ 关系抽取（RE）→ 图谱存储（Neo4j、NebulaGraph 等图数据库）。
  • 查询：图查询语言（Cypher / Gremlin）或图遍历算法（PageRank、社区发现、最短路径）。
  • 与大模型结合：图谱作为结构化记忆，模型负责从自然语言到图谱查询的映射（Text2Cypher），再把图查询结果自然语言化呈现。

典型架构模式有三种：
1. KG 作为检索源：替代 / 补充向量库做准确关系召回；
2. KG 辅助推理：多跳查询回答”有哪些 Supplier 同时服务 A 和 B”；
3. KG 增强生成（GraphRAG）：见第 15 节。

售前场景中的价值定位

当客户说”我们的数据太乱、查关系很慢”时，知识图谱是答案。它的售前卖点在于确定性与可解释性——金融反欺诈、供应链溯源、设备拓扑、权限治理这类”关系即价值”的场景，图谱比纯向量检索更可靠，也更容易通过审计。

适用场景与局限性

  • 适用：密切关系、严格约束、需可追溯推理（如”谁为什么能访问什么资源”）。
  • 局限：构建成本高（需领域专家标注或高质量抽取模型）、schema 变更不灵活、对非结构化自由文本覆盖弱。

与大模型结合的工程范式：Text2Cypher

将自然语言转为图查询是图谱上线大模型的关键一环，典型流程：

用户问："张三是哪个组的，能访问哪些系统？"
   ↓ 大模型翻译
CYPHER: MATCH (p:Person {name:'张三'})-[:BELONG_TO]->(g:Group)
        MATCH (g)-[:CAN_ACCESS]->(s:System) RETURN g, s
   ↓ 图数据库执行
返回：张三 → 运维组 → [工单系统, 监控平台]
   ↓ 大模型自然语言化
"张三是运维组成员，可访问工单系统与监控平台。"

这套”自然语言 → 图查询 → 自然语言”的循环，让不懂图语言的业务人员也能直接问关系问题。售前在权限治理、合规审计类项目中演示这一段，往往能让非技术决策者瞬间理解图谱的价值——因为它把”技术能力”翻译成了”我明天就能问的一句话”。

4. LLM Wiki

核心概念阐述

“LLM Wiki”指以大模型为中枢、自动构建与维护的企业级动态知识中枢——它持续从文档、对话、系统中抽取知识，组织成可检索、可追问、可演进的”活百科”。区别于静态 Wiki（如 Confluence），LLM Wiki 强调知识的自动生成、关联与更新，解决”知识写完就死、找的时候找不到”的普遍问题。

技术原理与架构模式

常见架构是”RAG + 抽取 + 摘要”的循环：
1. 新文档进入 → 抽取关键事实与实体；
2. 与既有知识去重、合并、冲突检测；
3. 生成可读性摘要与关联链接；
4. 用户以自然语言提问，系统路由到对应知识节点并组织答案。

可视为 RAG 与知识图谱的工程化融合：向量库负责”模糊召回”，图谱负责”精确关联”，LLM 负责”语言呈现”。模式上可分轻量版（仅 RAG + 摘要）与完整版（RAG + KG + 持续抽取）。

售前场景中的价值定位

LLM Wiki 解决”知识孤岛”问题：企业文档散落在邮件、网盘、IM 里，员工找信息平均耗时高。售前话术是——“不要让知识死在文件夹里，让它在被问到的那一刻自己走出来。” 它特别适合知识密集型组织（咨询、研发、客服、运维）以及并购后的知识整合。

适用场景与局限性

  • 适用：知识密集型组织、并购后整合、跨部门知识复用。
  • 局限：需要稳定的文档治理流程作支撑；自动抽取的准确性需人工校验循环；初期冷启动需批量导入。

与 RAG、知识图谱的关系（对比图）

三者不是替代，而是递进互补，可用一张层次图理解：

RAG      → 解决"找得到"（基于向量的模糊召回）
知识图谱  → 解决"关系清"（基于图结构的精确关联）
LLM Wiki → 解决"用得上"（把前两者组织成持续演进的知识中枢）

RAG 是单点问答，图谱补关系推理，LLM Wiki 再把二者沉淀为组织资产。售前选型时我常画这张图告诉客户：不要一上来就建图谱（重），也不要止步于 RAG（浅）——按”RAG 打底 → 图谱补强 → Wiki 沉淀”的节奏分阶段投入，风险与成本都更可控。

5. 预训练

核心概念阐述

预训练（Pre-training）是在海量无标注语料上以自监督方式训练基座模型的过程，目标是让模型习得通用语言理解与世界知识。它是”大模型能力天花板”的决定性阶段，也是算力与资金消耗的最大头。

技术原理

主流目标是下一词预测（Next Token Prediction），损失函数为交叉熵：

$$ \mathcal{L} = -\sum_{t=1}^{T} \log P(x_t \mid x_{<t}; \theta) $$

训练算力需求近似公式（Kaplan 等提出的缩放律，Scaling Law）：

$$ C \approx 6 \times N \times D $$

其中 $N$ 为模型参数量，$D$ 为训练 token 数，$C$ 为训练总浮点运算次数（FLOPs）。这意味着 100B 参数模型训练 1T token 约需 $6 \times 10^{23}$ FLOPs，对应数千张高端 GPU 训练数月。

数据规模与成本构成

  • 数据规模：旗舰模型训练语料普遍在数万亿（Trillion）token 级，需多语言、多领域、严格去重与质量过滤。
  • 成本构成：GPU / 集群租赁（占比最大）、数据存储与清洗、失败重试、工程人力。一次旗舰级预训练动辄数百万至数千万美元。

数据质量决定了预训练上限，主流清洗管线包含：语言识别与过滤、去重（精确 + 语义）、质量打分（如基于分类器筛除低质网页）、隐私脱敏（去除个人信息）、毒性过滤。这一步往往消耗与训练本身相当的工程投入，却最容易被外部观察者忽略。售前在给客户科普”为什么好模型贵”时，数据治理成本是最有说服力的注脚——模型的能力，一半在算法，一半在数据。

预训练的稳定性也是工程难点：大规模分布式训练易出现 loss 突刺（loss spike）、硬件故障，需要 checkpoint 容错与平滑技术。因此对绝大多数企业，自建预训练不是”要不要”的问题，而是”值不值”的问题。

主流路线对比

路线 代表 特点 售前含义
稠密模型（Dense） 早期 GPT、BERT 全参数激活，简单稳定 适合中小规模私有化
混合专家（MoE） DeepSeek V3、Qwen3、Mixtral 每 token 仅激活部分专家，性价比高 单位算力智能更高，推荐企业选型
开源 vs 闭源 Llama / Qwen / DeepSeek vs GPT / Claude 开源可私有化，闭源能力强 合规与能力权衡

售前价值定位

对客户，预训练阶段通常”不用自己做”——除非是超大集团要练自有基座。我的沟通原则是：绝大多数企业应在”选模型+微调/RAG”层发力，而非重走预训练。这能帮客户省下 99% 的无效投入，也是售前专业度的体现。我会用一句话收尾：“把预训练留给巨头，把上线留给自己。”

6. 微调

核心概念阐述

微调（Fine-tuning）是在预训练基座上，用特定领域 / 任务数据继续训练，使模型适配下游需求。它是”通用模型变专业模型”的关键手段，也是我在多个行业项目里上线”专业度”的切入点。

方法对比

方法 全称 核心思想 数据需求 难点
SFT 监督微调 用”指令—回答”对直接训练 中等（千~万级） 数据质量与多样性
RLHF 人类反馈强化学习 训练奖励模型 + PPO 优化 偏好标注（贵） 训练不稳定、成本高
DPO 直接偏好优化 用偏好对直接优化，跳过奖励模型 偏好对 需高质量正负样本

LoRA（低秩适配）是微调的工程加速器：冻结原权重，仅训练低秩分解矩阵

$$ W = W_0 + \Delta W = W_0 + BA $$

其中 $B \in \mathbb{R}^{d \times r}, A \in \mathbb{R}^{r \times k}, r \ll d$。它将可训练参数量降至原模型的 0.1%~1%，显存与成本大幅下降，且多个 LoRA 适配器可热插拔切换，非常适合”一个基座、多业务线”的企业。

数据准备要点

  • 质量 > 数量：去重、去噪、去污染；
  • 覆盖边界 case：典型样本之外，必须有”拒答””异常处理”样本；
  • 格式统一：指令、上下文、输出字段结构化；
  • 防灾难性遗忘：控制好学习率与训练轮次，避免忘记通用能力。

何时微调 vs 何时 RAG

需要"学会新知识 / 新风格 / 新格式"  →  微调（尤其 LoRA）
需要"查最新事实 / 私有文档 / 可溯源"  →  RAG
两者可叠加：RAG 提供事实，微调提供风格与结构

经验法则：事实类用 RAG，能力类用微调。二者不是二选一，而是分层互补。

进阶实践：QLoRA 与多适配器

  • QLoRA：在 LoRA 基础上进一步把基座量化为 4-bit（NF4 格式），使在单张消费级显卡上微调百亿级模型成为可能，把微调门槛从”集群”降到”单卡”，对预算有限的客户很吸引人。
  • 多适配器路由：为不同业务线训练独立 LoRA 适配器，推理时按用户身份动态加载，实现”一个基座、千面模型”，明显节约显存与运维。这正是我在多分支组织（如跨厂区、跨部门）项目里推荐的模式。

需提醒客户：微调不是”越多数据越好”，低质量数据会污染模型；且微调后务必用独立测试集评估，防止”在训练集上漂亮、在业务上翻车”。评测循环（第 10、17 节）在微调场景同样必要。

项目经验（脱敏）

在某新能源企业智能运维场景，我们采用 LLM + LoRA 路线：用历史工单与处置手册微调轻量适配层，让模型”说运维的行话、按标准流程给建议”。相比纯提示词，LoRA 使专业术语准确率与处置建议合规性明显提升，是 MTTR 下降 70% 的关键一环。这里微调解决”风格与专业度”，RAG 解决”实时知识”——二者分工清晰，也是我向客户讲清”为什么既要 RAG 又要微调”的最佳素材。

7. 推理优化

核心概念阐述

推理（Inference）是模型部署后对外提供预测服务的过程。推理优化目标是在有限算力下，同时压低延迟（Latency）、抬高吞吐（Throughput）、降低单 token 成本——这三者往往相互制衡，是 POC 能否进生产的核心经济账。

核心技术

  • 量化（Quantization）：将 fp16 / bf16 权重降到 int8 / int4，显存与带宽压力骤减。代价是精度损失，需校准（Calibration）。
  • KV Cache：缓存每层的 Key / Value 避免重复计算。其显存占用：

$$ M_{kv} = 2 \times L \times n_{layers} \times d_{model} \times B \times s_{prec} $$

其中 $L$ 为序列长度、$B$ 为批大小、$s_{prec}$ 为每元素字节数。长上下文下 KV Cache 是显存大户。
– 投机采样（Speculative Decoding）：用小模型先”草稿”、大模型并行验证，加速自回归生成。
– 批处理（Continuous Batching）：动态拼批提升 GPU 利用率，避免请求互相等待。
– 算子融合 / FlashAttention：减少显存读写，加速注意力计算。

对这些技术的直觉理解：自回归生成每出一个 token 都要重算大量中间结果，量化与 KV Cache 直击”显存带宽”瓶颈，投机采样直击”串行等待”瓶颈，批处理直击”GPU 闲置”瓶颈。三者叠加，常见的端到端加速可达 3~8 倍。售前在给客户做容量规划时，应基于”目标 QPS × 平均输出长度”反推所需卡数，而非拍脑袋——这正是把技术翻译成采购清单的关键一步。

延迟与吞吐的权衡

高并发在线服务：优先吞吐（大 batch）→ 单请求延迟上升
低延迟交互（如对话）：优先延迟（小 batch / 流式）→ 吞吐下降

吞吐量定义：

$$ \text{Throughput} = \frac{B \times L}{\text{Latency}} \quad (\text{token/s}) $$

流式输出（Token Streaming）则把”首字延迟（TTFT）”与”逐字延迟（TPOT）”分开优化，是交互体验的关键。

售前价值定位

推理优化直接决定”这套方案跑起来贵不贵”。我常给客户算一笔账：同样的业务量，量化 + 投机采样可将推理成本降到原来的 1/3~1/5。在多个政企项目报价中，我把”推理优化带来的成本下降”写进 ROI 测算，往往是决策层拍板的关键变量。

8. Agent 智能体

核心概念阐述

Agent 是以 LLM 为”大脑”，能感知环境、调用工具、做规划、记忆历史、自主执行多步任务的系统。它把”问答”升级为”办事”，是 AI 从”信息工具”走向”执行主体”的跨越。

架构设计

  • 规划（Planning）：任务分解（如 ReAct、Plan-and-Execute、Tree of Thoughts）；
  • 工具调用（Tool Use / Function Calling）：模型输出结构化调用请求，运行时执行并回传结果；
  • 记忆（Memory）：短期（上下文窗口内）+ 长期（向量库 / 数据库）；
  • 多 Agent 协作：多个角色 Agent（如”研究员 + 评审 + 执行”）通过消息总线协同，各自专精。

一种典型的多智能体协作拓扑（文字图）：

        ┌─────────────┐
        │  总控 Agent  │  负责任务分发与结果汇总
        └──────┬──────┘
     ┌─────────┼─────────┐
     ▼         ▼         ▼
 研究员Agent  执行Agent  评审Agent
 (检索/分析) (调工具办事) (校验/风控)
     └─────────┼─────────┘
        ┌──────┴──────┐
        │  共享记忆总线 │  长期记忆 / 状态
        └─────────────┘
  • 规划机制：ReAct 让模型”边想边干”（Thought → Action → Observation 循环）；Plan-and-Execute 先生成完整计划再逐步执行，更适合长任务；
  • 记忆机制：短期记忆放上下文，长期记忆落向量库或数据库，并通过”记忆检索”在需要时召回。避免把一切塞进窗口，这正是上下文工程（第 12 节）的用武之地。

售前场景价值定位

Agent 是售前从”展示能力”走向”展示业务结果”的跃迁点。客户不再问”模型多聪明”，而是问”能替我跑完这个流程吗”。Agent 最能讲清”AI 怎么上线到具体岗位”，也最容易在演示中制造”顿悟时刻”——让系统现场办成一件客户平时要花半天的事。

客户常问与应答

  • Q：”Agent 会不会乱调工具？” A：”通过权限白名单、参数校验、Human-in-the-loop 关键节点确认来约束。”
  • Q：”失败了怎么办？” A：”Loop Engineering（第 14 节）提供重试与自我纠错，并设最大轮次护栏。”

项目经验（脱敏）

在某 To B 销售场景，我们用 LangGraph 编排多智能体：一个 Agent 负责客户画像与商机挖掘，一个负责方案草案生成，一个负责合规与话术校验。售前演示中，我让系统现场”从一份客户资料自动产出定制化方案初稿”，评审 Agent 同时标出风险点——这一”端到端办事”的演示，比任何参数对比都更有说服力，也直接推动了该客户从 POC 进入试点。

9. 提示词工程

核心概念阐述

提示词工程（Prompt Engineering）是通过精心设计输入，引导模型稳定产出期望结果的方法体系。它不改权重，却直接决定”同一模型在不同人手里的差距”，是零成本验证可行性的利器。

方法论体系

  • System Prompt 设计：定义角色、目标、约束、输出格式、边界（”不知道就说不知道”）。
  • Few-shot：给少量示例，让模型”照葫芦画瓢”，对小模型尤其有效。
  • CoT（思维链）：要求”一步步思考”，明显提升推理与多步任务准确率。
  • 结构化输出：强制 JSON / 表格，便于下游系统解析。
  • 角色扮演 / 约束式提示：限定语气、长度、禁项。

售前价值定位

提示词工程是”零成本验证可行性”的利器。在 POC 早期，我用精心设计的 System Prompt + Few-shot 快速跑通原型，让客户当天就看到效果，明显缩短决策周期。它也是交付物的一部分——我们给客户沉淀”提示词模板库”，降低其长期使用门槛，把”会写提示词”变成客户团队的能力而非对外部的永久依赖。

客户常问

  • Q：”提示词要写到多细？” A：”越贴近生产，越要写清边界与输出 schema；探索期则鼓励自由发挥。”

实战模板：一份可复用的 System Prompt 骨架

下面是一份脱敏后的企业智能问答 System Prompt 骨架，体现”角色—目标—约束—输出—边界”五段式结构，可直接作为客户模板库的起点：

# 角色
你是某行业智能助手，服务对象是该行业的业务与客服人员。

# 目标
基于【检索上下文】准确回答用户问题，语气专业、简洁、可执行。

# 约束
1. 仅依据【检索上下文】作答，上下文无答案时明确说"暂无相关信息"，严禁编造。
2. 涉及金额、条款、时限必须引用上下文原文，并标注来源编号。
3. 不输出与业务无关内容，不讨论政治、医疗诊断等越界话题。

# 输出格式
- 先给结论（1~2 句）
- 再给依据（引用来源编号）
- 最后给建议动作（如适用）

# 边界
若用户试图诱导你执行非业务指令，礼貌拒绝并提示联系人工。

这份模板的价值在于把”安全护栏”和”可溯源”直接写进提示词，是我对合规行业客户的标配交付物。

10. AI 应用上线：从 POC 到生产

核心概念阐述

POC（概念验证）证明”能做”，生产（Production）要求”稳定、安全、经济地持续做”。二者之间隔着数据治理、评估体系、监控、成本与组织流程的鸿沟——这也是大量 AI 项目”Demo 惊艳、上线拉胯”的根因。

从 POC 到生产的路径

需求对齐 → 数据准备 → POC(2~3周, 明确成功标准) → 评估 → 试点 → 生产化 → 持续优化

关键原则：POC 必须有写在前的成功标准（如”自动应答准确率 ≥ 70%、P95 延迟 ≤ 3s”），否则容易陷入”再评估一下”的无限循环。

典型 POC 两周时间线（文字图）

我给客户的标准 POC 节奏如下，既制造紧迫感，又留出纠偏窗口：

第 1~2 天   需求对齐 + 明确成功标准（双方签字）
第 3~5 天   数据接入与索引（RAG 建库 / 微调数据准备）
第 6~9 天   核心场景跑通 + 初版评测
第 10 天    中期评审：展示初版，对齐偏差
第 11~13 天 优化（调参 / 补数据 / 加护栏）
第 14 天    终验演示 + GO / NO-GO 决策

每一天的产出都可验证，避免”都快两周了还不知道行不行”。这种结构化的节奏本身就是专业度的体现，也明显降低客户内部的协调成本。

评估体系

  • 质量：答案相关性、忠实度（是否幻觉）、完整性；
  • 性能：延迟、吞吐、并发上限；
  • 成本：单请求 token 成本、GPU 时占用；
  • 安全：越狱、敏感信息泄露、合规。

持续优化策略

建立”线上反馈 → 数据回流 → 评测回归 → 迭代”闭环。监控生产中的 bad case，定期用新数据补充 RAG 或微调。我常对客户说：”上线不是终点，是数据循环的起点。”

项目经验（脱敏）

我把上述框架用于多个项目：先以 2 周 POC 锁定”自动应答覆盖率 70%”这一硬指标，达标后进入试点扩容。其中零信任类项目更强调安全评估（权限最小化、审计），而知识问答类更强调准确率与溯源——评估维度随场景而变，这正是售前要把控的”项目节奏”。我坚持”先小范围证明、再规模化复制”，既控制客户风险，也给我们留出优化窗口。

11. AI 算力

核心概念阐述

算力是 AI 的物理底座。选型本质是在性能、成本、合规之间找平衡点，是售前方案中技术含量最高、也最易被忽视的商务变量。

硬件选型逻辑

芯片类型 代表 特点 适用
GPU NVIDIA H 系列、A 系列 生态成熟、通用性强 训练 + 高性能推理
NPU / ASIC 华为昇腾、寒武纪 国产合规、推理能效高 信创 / 政务私有化
推理卡 各类国产推理加速卡 成本低、专用于推理 大规模在线推理

性能需求估算公式

  • 权重视存：M_weights = N × b，其中 b 为每参数字节数（fp16 取 2，int4 取 0.5）。
  • 推理显存总需求 ≈ 权重视存 + KV Cache + 激活 + 框架开销。经验上，7B 模型 fp16 推理约需 14~16GB，加上 KV Cache 与并发需更高。
  • 训练算力：C ≈ 6 × N × D（见第 5 节）。

TCO 分析框架

$$ \text{TCO} = \text{Capex} + \sum_{t} \text{Opex}_t $$
– Capex：服务器、网卡、存储采购；
– Opex：电费、机房、运维人力、软件授权、模型 API 费。

售前价值定位

我常给客户做”自研集群 vs 调用 API”的拐点分析：当月调用量低于某阈值时，API 更省；超过阈值后，自建推理集群摊薄成本更优。这一框架帮助多个客户避免”为低频场景囤 GPU”的浪费，也把”算力选型”从技术话题变成 CFO 能参与的商务决策。

12. 上下文工程

核心概念阐述

上下文工程（Context Engineering）是研究”如何组织、调度、压缩喂给模型的上下文”的学科——比提示词工程更系统，关注长窗口下的信息供给质量。一句话：提示词工程决定”怎么问”，上下文工程决定”给模型看什么”。

核心策略

  • 上下文窗口利用：把最关键指令放首尾（模型对首尾注意力更强）；
  • 长文本处理：分段摘要、Map-Reduce、递归检索；
  • 上下文压缩：用小型模型对历史对话做摘要，保留要点；
  • 上下文缓存（Context Caching）：对不变前缀（如系统提示、长文档）做 KV 缓存复用，降本提速。

缓存命中可明显降低成本：

$$ \text{Cost}{cached} \ll \text{Cost} $$

长文本处理的三种范式（对比图）

范式 做法 优点 缺点 适用
全量塞入 整篇直接进上下文 简单、保真 贵、易超窗、噪声大 短文档
分段摘要（Map-Reduce） 各段摘要后汇总 可处理超长 中间信息可能丢失 长报告 / 论文
递归检索 先检索相关片段再生成 准确、省 token 依赖检索质量 知识库问答

选型本质是”保真度 vs 成本”的权衡。我在政务长文档场景多用”分段摘要 + 关键段全量”的混合策略，兼顾完整性与成本。

客户常问与应答

  • Q：”上下文越长越好吗？” A：”不是。长窗口带来更高成本与注意力稀释，应只放必要信息，其余靠检索与缓存。”
  • Q：”多轮对话会变慢吗？” A：”靠上下文压缩与缓存，历史可摘要化，避免窗口无限膨胀。”

售前价值定位

当客户业务涉及”超长合同 / 论文 / 代码库”时，上下文工程决定体验与账单。我用一个对比图说明：无缓存 = 每次都重算长文档（贵且慢）；有缓存 = 长文档只算一次（便宜且快）——这是长上下文场景商务报价的关键变量，也是我向客户解释”为什么长文档问答单价可以更优”的技术依据。

13. Agent Harness

核心概念阐述

Agent Harness（智能体编排框架）是承载 Agent 运行的”操作系统”——负责任务调度、工具注册、状态管理、记忆读写、错误恢复与可观测性。LangChain、LangGraph、LlamaIndex、AutoGen、CrewAI 皆属此类。

设计理念与工程实践

  • 声明式 vs 编程式：LangGraph 用”图（节点 + 边）”显式编排，可控性强、易调试；
  • 状态管理：用 TypedState 维护跨步骤共享状态；
  • 人机协同（Human-in-the-loop）：关键节点挂起等待人工确认；
  • 可观测性：每步输入 / 输出 / 工具调用可追溯，便于定位坏点。

主流框架对比（售前选型参考）

框架 范式 强项 适用
LangChain 链式组合 组件丰富、生态大 快速原型、简单链
LangGraph 图编排 状态可控、易调试、支持循环与分支 生产级多步 / 多 Agent
LlamaIndex 数据为中心 RAG / 索引能力强 知识库问答为主
AutoGen 对话式多 Agent 多 Agent 对话协作成熟 研究型多 Agent
CrewAI 角色化团队 角色分工直观、上手快 轻量多 Agent 业务流

我的经验法则：原型用 LangChain 跑通，生产用 LangGraph 兜底。前者胜在快，后者胜在稳——状态图让每一步可观测、可回放、可干预，这正是政企客户对”可控性”的硬性要求。

售前价值定位

Harness 选型影响”方案能否生产化”。我向技术买家强调：Demo 用提示词能跑通，生产必须用 Harness——它提供错误处理、重试、审计，是把”玩具”变”系统”的骨架。在前面提到的多智能体销售项目中，正是 LangGraph 的状态图与条件分支，让”评审 Agent 拦截风险”成为可上线机制而非演示噱头。售前在 Harness 上的专业判断，往往决定了客户技术团队对我们的信任度。

14. Loop Engineering

核心概念阐述

Loop Engineering（循环工程）指 Agent 在执行中通过迭代循环自我纠错、逐步收敛的控制方法论。典型如 ReAct（推理—行动循环）、自我反思（Self-Reflection）、多轮校验。它是 Agent “越用越聪明、错了能改”的工程保障。

迭代循环控制

观察(Observe) → 思考(Think) → 行动(Act) → 观察结果 → 修正 → ... → 满足终止条件
  • 自我纠错：模型检查自身输出（如”答案是否回答了问题？工具调用是否报错？”），不达标则重试；
  • 收敛策略：设置最大轮次（max_iter）、置信度阈值、早停（early stop），防止无限循环与成本失控。

公式化表达

设第 $i$ 轮输出 $o_i$，评估函数 $f(o_i)$ 表示质量，终止条件：

$$ \text{stop when } f(o_i) \ge \tau \text{ or } i \ge i_{max} $$

售前价值定位

Loop Engineering 让客户理解”AI 不是一次就成，而是会自己改到自己合格”——这既提升了任务成功率，也需要明确”上限与成本护栏”。我在方案中都会写明最大循环次数与超时，让客户对”最坏情况成本”有预期，这也是规避”Agent 跑飞烧钱”风险的必备设计。

15. Graph Engineering

核心概念阐述

Graph Engineering 是将图结构（知识图谱、关系网络）系统性引入 LLM 工程的方法论，代表范式是 GraphRAG——用图检索增强生成，弥补传统向量 RAG 在”全局性、多跳、社区性问题”上的不足。

知识图谱与 LLM 的结合

  • 索引阶段：文档抽取实体 / 关系建图，并做社区检测（Leiden 算法）生成社区摘要；
  • 查询阶段：
  • 局部查询：定位相关子图 → 召回邻居 → 生成；
  • 全局查询：利用社区摘要做”地图Reducer”式汇总，回答”整体趋势 / 主题”类问题。

GraphRAG 前沿范式

范式 解决问题 代价
向量 RAG 点状事实检索 全局 / 多跳弱
GraphRAG 关系推理、全局摘要 建图成本高、需图存储
Hybrid 向量 + 图融合 工程复杂度高

社区摘要（Community Summary）是 GraphRAG 的关键创新：建图后用 Leiden 算法把图划分为若干社区（主题簇），对每个社区生成自然语言摘要。全局查询时，逐层汇总社区摘要，相当于让模型先”读目录”再”读全书”，从而回答”整体趋势 / 主题分布”这类向量 RAG 几乎无法处理的问题。代价是建图与摘要的离线成本高，因此更适合”知识相对稳定、但查询偏全局”的场景（如制度库、风险库），而非高频更新的实时数据。

售前价值定位

当客户问”能不能让我问’我们公司今年所有供应商的风险分布’”这种全局性问题时，传统 RAG 力不从心，GraphRAG 才是答案。我用对比图展示：向量检索像”找最像的几段文字”，图检索像”顺藤摸瓜摸清整张关系网”——前者快但浅，后者慢但深。在金融风控、供应链溯源类客户中，这一对比往往能直接打开 GraphRAG 的预算窗口。

16. 主流大模型对比

核心概念阐述

截至 2026 年中，大模型格局呈”国际前沿 + 国产开源崛起”双轨。选型应基于任务匹配、成本、上下文、部署合规四维，而非单一榜单排名。榜单第一 ≠ 你的业务第一。

各厂商代表模型与能力边界对比表

注：模型版本迭代极快，下表中的”代表模型”以 2026 年中公开信息为参考，具体版本、上下文长度、价格请以各厂商官网实时数据为准。售前做选型时，与其背版本号，不如记住每个阵营的能力边界。

厂商 / 阵营 代表模型（示例） 上下文 定位 / 强项 能力边界 部署
OpenAI GPT-5.x / o 系列推理模型 数十万 ~ 百万级 token 综合能力前沿、生态全、Agent 工具链成熟 闭源、合规出境受限、价格高 API / Azure
Anthropic Claude Opus / Sonnet 系列 约百万级 token 长文档、编码、深度分析、低幻觉口碑好 闭源、需合规评估、贵 API
Google Gemini 3.x 系列 百万 ~ 数百万级 token 原生多模态、超长上下文、高吞吐 中文细微表达略弱 API / GCP
Meta Llama 4 系列 数十万 ~ 百万级 token 开源可私有化、生态广 顶尖推理通常弱于前沿闭源 开源 / 自托管
xAI Grok 系列 数十万级 token 实时资讯、风格直接 企业集成生态较弱 API
DeepSeek V 系列 / R 系列 128K ~ 百万级 token 开源、性价比高、推理强 多模态相对弱、超长上下文能力需实测 开源 / API
阿里 Qwen3 系列 百万级 token 开源生态丰富、多模态全、中文强 极致推理略逊国际前沿 开源 / 阿里云
智谱 GLM 系列 百万级 token 开源、学术背景、能力均衡 海外生态较弱 开源 / API
月之暗面 Kimi K 系列 百万级 token 超长文档、”大海捞针”能力强 写作风格偏平 API
字节 豆包 / Seed 系列 128K ~ 百万级 token 中文创作、语音自然、视频生成 深度推理一般 API
百度 文心 ERNIE 系列 128K+ 中文创作、百度生态 开源弱 API / 千帆
腾讯 混元 Hunyuan 128K+ 腾讯生态、视频生成强 通用推理中等 API / 云
百川 / 讯飞 Baichuan / 星火系列 128K+ 中文、行业方案 前沿性中等 API

选型建议（售前口径）

  • 要最强综合能力 + 不差钱：OpenAI GPT 最新系列 / Anthropic Claude 最新系列；
  • 要超长文档 + 高吞吐 + 性价比：Google Gemini 最新系列；
  • 要私有化 + 低成本 + 可控：Qwen / DeepSeek / GLM 等开源权重；
  • 要中文创作 + 国内合规：文心 / 豆包 / 通义；
  • 要长合同 / 论文分析：Kimi 等长上下文模型。

选型决策树（文字图）

售前现场可用这张决策树快速收敛到候选模型：

是否数据不出域 / 需私有化？
├─ 是 → 选开源权重（Qwen / DeepSeek / GLM）→ 本地或信创部署
└─ 否 → 是否追求极致效果且预算充足？
        ├─ 是 → OpenAI GPT 最新系列 / Anthropic Claude 最新系列
        └─ 否 → 是否长文档 / 高并发？
                ├─ 是 → Google Gemini 最新系列
                └─ 否 → 是否重中文创作？ → 文心 / 豆包 / 通义

决策树的价值在于把”选模型”从玄学变成可拆解的流程，也方便客户参与决策、减少后期扯皮。

17. 其他关键概念

Function Call（函数调用 / 工具调用）

模型输出结构化调用请求（JSON），由运行时执行对应函数（查数据库、调 API、算公式）并返回结果。它是 Agent 与外界交互的”手”。售前需强调：Function Call 让”会聊天的模型”变成”能干活的系统”。上线中要约束可调用函数白名单，防止越权。

工作流（Workflow）

在 Agent 之上的确定性流程编排——把多步骤任务固化为有向图，部分节点用 AI、部分用规则。与纯 Agent 的区别：Workflow 更可控、可审计，适合严格流程行业（金融审批、工单流转）。售前建议：能 workflow 就别全 agent，可控性即生产可用性。

top_k / top_p

解码采样参数：
– top_k：只从概率最高的 k 个词中采样；
– top_p（核采样）：从累计概率达 p 的最小词集中采样。
二者控制输出多样性与稳定性。售前交付中，我把”严谨任务（如合规审查）”设为低 top_p（更确定），”创意任务（如文案）”设为高 top_p（更多样）。

问题（Problem / 失配）

指模型与业务之间的”鸿沟”：幻觉、知识陈旧、格式错乱、越权。售前的核心工作之一就是把客户的”问题”翻译成技术解法（RAG 治陈旧、微调治风格、评测治质量、权限治越权）。

模型评测（Model Evaluation）

维度：MMLU（通识）、GPQA（推理）、HumanEval / SWE-bench（代码）、LongBench（长文本）、中文 C-Eval / CMMLU。售前用法：带客户用其真实任务做侧边对比，比公开榜单更有说服力——因为”你的业务”才是唯一重要的榜单。

RAG 评测（RAG Evaluation）

关键指标：
– 忠实度（Faithfulness）：答案是否完全来自检索内容（衡量幻觉）；
– 答案相关性（Answer Relevancy）：是否切题；
– 上下文召回率（Context Recall / Precision）：检索是否找对了。
常用框架：Ragas、TruLens、DeepEval。我在 RAG 项目中以 Ragas 做回归测试，把”70% 自动应答覆盖率”拆成可量化、可追踪的指标，让客户对质量有客观预期，也把”效果”从主观感受变成了可管理的数字。

模型评测与 RAG 评测的关系

二者常被混淆，其实层次不同：模型评测回答”这个基座够不够聪明”，RAG 评测回答”这套系统答得准不准、有没有乱编”。售前在向客户汇报时，应把两者分开呈现——先证明”选的模型在通用榜能打”，再证明”我们的 RAG 链路在你家数据上忠实不幻觉”。只谈模型榜单选不出 RAG 项目的成败，只谈 RAG 又掩盖了基座上限，二者结合才是完整的可信叙事。

第二部分：岗位思考

售前在 AI 时代的角色演变

传统售前是”产品功能的翻译官”，AI 时代则演变为”业务问题的 AI 解法架构师“。变化在于：
– 从”讲功能清单”到”讲业务结果”（MTTR 降 70%、客服工时降 X%）；
– 从”一次性演示”到”陪客户跑通 POC”；
– 从”卖软件”到”卖能力 + 陪跑上线”。
售前的专业护城河，不再是背参数，而是把模糊需求拆成可验证的技术路径。在 AI 项目里，客户往往自己也说不清要什么，售前要用技术语言把”想要个智能客服”翻译成”RAG + 工单库 + 流式响应 + 评测循环”，这正是价值所在。

这种角色演变背后，是对”不确定性”的耐受力。传统软件需求明确、交付可预期；AI 项目则充满”试了才知道”的不确定性。售前要从”承诺确定”转向”管理预期”——向客户讲清哪些能 100% 保证（如私有化部署、权限隔离），哪些需要 POC 验证（如准确率上限、长尾覆盖）。诚实标注不确定性，反而比打包票更能建立长期信任。这也是我骨子里认同的工作方式：不夸大、不躲闪，用工程化方法把不确定变成可度量。

构建技术与商业的桥梁

售前是唯一同时被技术与商务双方需要的角色。我的桥梁方法论：
1. 向上翻译：把客户的业务问题（”客服太慢”）翻成技术命题（”RAG + 工单知识库 + 流式响应”）；
2. 向下翻译：把技术限制（”长上下文贵”）翻成商业取舍（”先上高频短问答，长文档走异步摘要”）；
3. 用经济账说话：TCO、单请求成本、ROI 回收周期，是说服决策层的通用语言。
实践里，我会为每类客户准备”技术版”与”商务版”两套材料：技术版给架构师看架构与集成，商务版给总监看 ROI 与风险。同一套方案，两种语言，这是售前的基本功。

需求挖掘与方案匹配方法论

我采用”三层挖掘法“：
– 表层需求（客户说的）：如”要个智能客服”；
– 真实需求（客户痛的）：如”夜间无人值守、合规留痕”；
– 潜在需求（客户没想到的）：如”把客服数据回流训练，越用越聪明”。

匹配时画一张”需求—技术矩阵”：横轴是需求类型（知识 / 推理 / 流程 / 生成），纵轴是技术选项（RAG / 微调 / Agent / Workflow），每个格子标注适用度与成本。这张矩阵是我每次方案设计的底稿，也常用于售前内部评审，避免”为了用 Agent 而用 Agent”的技术自嗨。

此外还有”预埋问题（Landmine Questions）“技巧：在发现阶段问一些看似常规、实则暴露竞争短板的问题，例如”你们跨部门的数据权限怎么打通的？””长文档的审计留痕现在怎么做？”——这类问题既能完善方案设计，又能自然凸显我们的差异化能力。

需求发现阶段的标准问题库

我通常会按四个维度准备问题，确保不漏关键约束：

维度 典型问题
业务目标 “这个项目成功了，哪个指标会动？””现在靠人怎么解决，成本多少？”
数据现状 “数据在哪、什么格式、多久更新一次？””有无标注历史？”
合规约束 “数据能出域吗？””需要哪些审计与留痕？””有无信创要求？”
上线环境 “峰值并发多少？””可接受的首响延迟？””现有什么系统要对接？”

这份问题库让发现会不只是”听客户讲”，而是”带着框架挖”。同样一小时，专业售前挖出的约束能直接决定方案能不能上线——这是经验最值钱的地方。

典型行业 AI 上线差异分析

行业 核心诉求 技术偏好 上线难点 我的打法
金融 合规、风控、低幻觉 私有化 + RAG + 严格评测 数据不出域、审计 开源私有化 + 双栈 + 严格评测
制造 设备运维、质检、知识沉淀 LLM+LoRA + 图谱 + 边缘推理 工业数据杂、实时性 运维知识库 + 边缘推理卡
政务 安全、可追溯、国产化 信创 NPU + 零信任 + RAG 信创适配、流程长 零信任 + 知识中枢 + 合规评估
能源 智能问数、智能运维 多分支组网 + Agent 运维 跨地域、异构设备 全球组网 + LLM 运维循环
医疗 诊断辅助、文献 专业微调 + 多模态 责任边界、数据敏感 辅助定位 + 人工终审

实战案例映射：技术 → 业务结果

售前最有力的语言，是把技术翻译成客户能懂、能算账的业务结果。以下为脱敏后的案例映射，可用于方案汇报的”价值证明”页：

行业（脱敏） 业务问题 采用技术 可量化结果
智慧园区视频监控运维 运维告警分散、处置靠老师傅经验 Transformer + LLM + LoRA + RAG 平均故障修复时间（MTTR）下降约 70%，新人上手周期缩短
v 咨询重复、人工客服压力大 RAG 知识库（12+ 文档格式）+ 零信任 自动应答覆盖率 70%+，人工咨询量明显下降
To B 销售团队 方案撰写耗时长、话术不统一 LangGraph 多智能体（挖掘 + 生成 + 合规评审） 方案初稿产出从”天级”降到”分钟级”，风险点自动标注

这张表的底层逻辑是：每项技术都不是目的，而是某个业务指标改善的手段。我在售前汇报中习惯用”问题 → 技术 → 指标”三段式讲故事，比罗列架构图更能打动决策层。它也是我在 POC 阶段就与客户对齐”成功标准”的依据——指标先行，技术随后。

18. AI 安全、合规与可信（延伸主题）

核心概念阐述

AI 系统并非”部署即安全”。它面临提示注入（Prompt Injection）、越狱（Jailbreak）、数据泄露、幻觉误导、偏见放大等多重风险。对政企客户而言，安全合规是 AI 上线的门票，而非可选项——没有合规，再强的效果也无法上线。

技术原理

  • 提示注入：攻击者在外源内容（网页、邮件、文档）中夹带恶意指令，诱导模型执行非预期操作。防御靠指令与数据隔离、输出校验。
  • 越狱：通过角色扮演、编码绕过等手段突破安全护栏。防御靠系统级拒绝规则 + 输入过滤 + 行为监控。
  • 成员推断 / 数据提取：试图反推训练数据中的个人隐私。防御靠差分隐私（Differential Privacy）、数据脱敏。
  • 对齐（Alignment）：通过 RLHF / DPO 让模型行为符合人类价值观与规则。
  • 可解释与审计：关键决策留痕、可回溯，满足监管。

售前价值定位

安全合规是我对金融、政务、能源客户开口必讲的话题。我的话术是：“效果决定你愿不愿意用，安全决定你能不能用。” 在方案里我会主动列明越狱防护、访问审计、数据不出域三项承诺，往往比堆参数更能赢得 CISO 的信任。

项目经验（脱敏）

在零信任类政企项目中，我把”模型访问需经权限网关””所有问答留审计日志””敏感字段自动脱敏”写入架构底线。某省级公共资源交易机构的项目里，正是这套安全设计让合规团队在评审中一次通过，避免了后期返工。这也印证了我的判断：在 regulated 行业，安全不是成本中心，而是成交的加速器。

售前能力模型（T 型）

AI 售前的能力结构应是”T 型”：
– 纵向（技术深度）：Transformer、RAG、微调、Agent、推理优化、算力估算——能和客户架构师对等对话；
– 横向（广度）：行业知识（金融 / 制造 / 政务 / 能源）、商业语言（ROI / TCO）、沟通与演示、项目管理。

我常画一张”能力雷达图”自评，也用于招聘或带教新人：技术深度决定你”说得对”，横向广度决定你”说得动”。只懂技术不懂业务的售前，方案很准但卖不出去；只懂业务不懂技术的售前，故事好听但上线翻车。二者缺一不可。

AI 项目常见失败模式与应对

基于多个项目的复盘，我把政企 AI 项目的高频失败模式归纳为五类，并配套应对：

失败模式 典型表现 应对（售前动作）
POC 无成功标准 “再评估一下”无限循环 写前定标，量化通过 / 不通过
忽视评估体系 上线后质量失控、客诉 引入 Ragas / 人工抽检回归
过度 Agent 化 流程不可控、易跑飞 能 workflow 就别全 agent
数据治理缺失 RAG 检索噪声大、效果差 先理数据再上模型
成本失控 推理账单爆炸、项目停摆 做 TCO 拐点，量化 + 优化前置

这套”失败模式清单”我在每个项目启动会上都会和客户对齐，既展现专业度，也提前管理预期、降低双方风险。

附录 A：技术选型速查卡

这张速查卡是前面所有技术主题的”压缩版”，适合在客户会议室快速定位方向。用法建议：先从左列锁定客户最痛的业务诉求，再沿中列找到首选技术，最后用右列”关键注意点”在方案里提前规避坑。它不替代深度分析，但是售前脑海中应有的”第一反应表”——熟记之后，客户随便抛一个诉求，你都能在三秒内给出技术方向，这种反应速度本身就是专业度的外显。

业务诉求 首选技术 关键注意点
用自有文档问答 RAG 切分策略、Embedding 质量、重排
私有化 + 低成本 开源模型 + LoRA 显存、量化校准
长合同 / 论文分析 长上下文 + 缓存 KV Cache 成本、检索准确
全局关系 / 风险分布 GraphRAG 建图成本、图存储
多步自动办事 Agent + Harness 权限白名单、Human-in-the-loop
严格流程审批 Workflow 可控性、可审计
低延迟高并发 推理优化（量化 / 投机采样） 延迟—吞吐权衡
合规不出域 私有化 + 安全护栏 越狱防护、审计留痕

附录 B：核心术语表

  • LLM：大语言模型（Large Language Model），以 Transformer 为底座的通用语言模型。
  • Embedding：将文本映射为向量的表示，用于语义检索。
  • MoE：混合专家（Mixture of Experts），每 token 仅激活部分参数，提升性价比。
  • LoRA：低秩适配，轻量微调方法，参数量降至原模型 1% 以内。
  • RAG：检索增强生成，用外部知识弥补模型参数知识。
  • Agent：以 LLM 为大脑、能调用工具自主执行任务的系统。
  • Function Call：模型输出结构化调用请求以使用外部工具。
  • top_k / top_p：解码采样参数，控制输出多样性。
  • KV Cache：推理时缓存 Key/Value 以加速自回归生成。
  • TCO：总体拥有成本（Total Cost of Ownership），含采购与运维。
  • GraphRAG：结合知识图谱的检索增强生成范式。
  • ReAct：推理—行动循环，Agent 经典执行范式。
  • POC：概念验证（Proof of Concept），证明可行性。
  • 零信任：默认不信任、持续验证的访问控制架构。
  • Agent Harness：智能体编排框架，负责任务调度、状态管理与可观测性。
  • Loop Engineering：循环工程，Agent 通过迭代自我纠错的control方法论。
  • Context Engineering：上下文工程，研究如何组织与压缩喂给模型的上下文。
  • Quantization（量化）：降低权重精度（如 fp16→int4）以省显存与带宽。
  • Speculative Decoding（投机采样）：小模型草稿、大模型验证的加速技术。
  • MoE（混合专家）：每 token 仅激活部分专家子网络，提升性价比。
  • Text2Cypher：将自然语言转为图查询语言，连接大模型与知识图谱。
  • Faithfulness（忠实度）：RAG 答案是否完全来自检索内容，衡量幻觉程度。

结语

大模型不是魔法，而是一套可拆解、可评估、可工程化的技术体系。作为 AI 售前，我的价值不在复述论文，而在帮客户在合适的场景，用合适的技术，花合理的成本，拿到能验证的业务结果。这份文档里的 18 个技术主题和岗位思考，就是这套打法的主干。

回顾经手的项目——智慧园区视频监控运维（MTTR 降约 70%）、新能源储能平台的 RAG 知识中枢（12+ 种文档格式、自动应答覆盖 70%+）、省级公共资源交易机构的智能咨询——主线一直没变：技术是手段，业务结果才是目的。售前最有成就感的时刻，不是合同签字，而是客户试点上线后说”这东西真替我省了时间”。

三点个人体会：
1. 先问业务，再选技术：别被新概念牵着走，从客户指标倒推方案；
2. 用数字说话：POC 成功标准、ROI、TCO，把”感觉不错”变成”测得出来”；
3. 底层逻辑比版本号值钱：模型更新很快，但注意力机制、检索质量、评测循环这些底层判断长期有效。

AI 浪潮不会等人，但盲目追风的人容易扑空。我希望自己永远是那个”既懂模型、又懂生意”的售前。也期待在真实项目里，和你一起把这些方法变成可跑的系统。

这份文档是基于AI全栈知识的学习并结合个人工作实践经验沉淀，厂商模型能力基于公开平台获取，且基于26年中的一些大模型信息，整篇文档供学习交流参考。

类似文章