不靠炒作的人工智能：工程师实战指南

网上大多数人工智能内容分为两个阵营：一种夸大通用人工智能的危险，另一种声称聊天机器人会在周二取代你的工作。两者都帮不了你交付任何东西。本指南避开这两个极端，讲解如何在真实项目中实际使用当代人工智能工具，同时明确说明其局限。

LLM 实际上做什么

GPT-4 或 Llama 3 这样的大语言模型在海量文本上训练，用来预测序列中的下一个 token。仅此而已。它没有内部的事实核查机制，会话之间没有持久记忆（除非你自己构建），也不存在人类那样的理解。当你问它问题时，它在生成对你的提示在统计上最可能的延续。

这在实践中很重要：模型会自信地生成调用一个并不存在的库方法的 Python 函数，因为那个方法听起来像是这个库会有的东西。总是要运行代码。总是查阅 API 参考。把模型输出看作来自一个快速、博览群书的实习生的初稿，只不过这个实习生有时会无意中撒谎。

真实工作流：用 LLM 写代码

这是一个行之有效的模式，而不是仅仅问 ChatGPT "给我构建一个应用"：

1. 自己写函数签名和文档字符串，指定类型和边界情况。
2. 要求模型根据那个确切的规范实现它。
3. 自己分别写测试——不要让模型为它刚写的代码写测试，它倾向于写能平凡通过的测试。
4. 运行测试。把失败作为新的提示反馈回去，而不是含糊其辞地说 "它不工作"。

def parse_duration(text: str) -> int:
    """
    Parse strings like '1h30m', '45s', '2d' into total seconds.
    Raise ValueError on invalid input.
    """

给模型这个确切的约定比含糊的描述能产生好得多的输出，而且给了你一个具体的测试对象。

检索增强生成，说白了

RAG 被当作时髦词四处乱用，但机制很简单：不是靠模型在训练期间记住的东西，而是在查询时获取相关文档并把它们塞进提示里。

基本设置：

1. 将你的文档分块（500-1000 token 是常见的起点）。
2. 用 text-embedding-3-small 之类的模型或像 bge-small-en 这样的开源模型为每个分块生成向量。
3. 把向量存在带 pgvector 的 Postgres 里，或者像 Qdrant 这样的专用存储中。
4. 在查询时，对用户问题生成向量，运行相似性搜索（余弦距离是标准的），并把最相关的 k 个分块连同问题一起拉入提示。

SELECT content FROM docs
ORDER BY embedding <=> '[0.012, -0.045, ...]'
LIMIT 5;

这就是为什么用截止日期前的数据训练的聊天机器人仍然能回答关于你上周内部 wiki 的问题。它不是在推理你的公司——它在读你的文档并总结它们。

经典机器学习仍然更胜一筹的地方

不是每个问题都需要 transformer。如果你在从结构化表格数据预测流失——账户年龄、使用频率、支持工单——像 XGBoost 或 LightGBM 这样的梯度提升树模型通常会胜过基于 LLM 的方法，训练耗时分钟而非小时，运行成本也只是零头。在触及 API 调用之前先考虑 scikit-learn 的 RandomForestClassifier 或 XGBoost，尤其是当你的数据能装进电子表格且目标变量是清晰的数字或类别时。

成本和延迟是设计约束，不是事后的想法

GPT-4 级别的调用按 token 计费且返回需要真实的秒数。如果你构建的功能在每个用户的每次页面加载时运行，费用会迅速累积，延迟会显而易见。积极缓存，对任何不需要一流推理的东西使用像 GPT-4o-mini 这样的小型模型或本地的 Llama 3 8B，把昂贵的模型调用留给你的管道中质量真正重要的部分。

没人会警告你的失效模式

当你要求模型做略微超出其训练分布范围的东西时——晦涩的库版本、内部公司术语、最近的 CVE 编号——它们倾向于产生更多幻觉。如果答案需要完全正确（安全建议、法律引文、医学剂量），不要只靠生成来信任。每次都根据主要来源验证，把那个验证步骤构建进你的管道中，而不是事后依赖人工审查。

一旦你停止期望 AI 工具思考，转而把它当作一个你必须检查的快速模式匹配器来对待，它就变得真正有用。从第一天就构建验证步骤，你就会从中获得真实价值，而不是源源不断的自信谬误。

如果你想深入学习，可以查看 Korra Studio 的 Python 和数据科学课程，学习那些使得与这些工具协作真正高效的基础知识。