技术探索与实践：在创业公司里别瞎折腾，但也别躺平
上周五晚上十一点半，我坐在深圳南山科技园某栋写字楼的工位上，盯着屏幕上一个诡异的 Embedding 向量服务返回的 502 错误，心里五味杂陈。产品经理前天刚说“这个功能下周上线”，测试同学今天下午又提了三个边缘 case，而我自己，还在为要不要把线上那个用了三年的 Flask 单体架构拆成微服务而纠结。
这就是我在这家 30 人不到的创业公司的日常——全栈开发，什么都干，从写前端组件到部署 K8s 集群，从设计数据库表结构到给新来的实习生出面试题。虽然名义上是“工程师”，但实际干的是“技术+运维+产品助理+客服”的活儿。好在我重度依赖 ChatGPT 和 Claude，不然早就被需求淹死了。
但最近有个问题一直困扰我：在资源有限、人手紧张、老板催命的创业环境下，到底该怎么搞技术探索？是闭眼冲最新框架，还是死守老技术稳如狗？
这篇文章，就是我这一年多来踩坑、翻车、偶尔灵光一现后的一些总结。不讲大道理，只聊实操。
别为了“新技术”而新技术
去年 Q3，我们团队决定引入向量搜索做智能推荐。产品经理画了个大饼：“用户搜‘适合夏天穿的连衣裙’，我们要能理解语义，而不是关键词匹配。”听起来很酷，技术上也很前沿——用 Embedding 模型把文本转成向量，再用 FAISS 或 Milvus 做近似最近邻搜索。
我当时热血沸腾，立马跑去 Hugging Face 找 SOTA 模型，还顺手用 LangChain 搭了个原型。结果呢？本地跑得飞快，一上测试环境就崩：内存爆了、GPU 费用超标、API 延迟飙到 2s+。更惨的是，我们的业务数据量其实不大——日活才几万，商品库不到十万条。用最朴素的 TF-IDF + 关键词扩展就能覆盖 90% 的场景。
教训：技术选型不是炫技，而是解决问题。
后来我们改用开源的 text-embedding-ada-002（通过 OpenAI API），配合 PostgreSQL 的 pgvector 插件，成本降了 80%，延迟压到 200ms 以内。虽然不是自研模型，但稳定、便宜、维护简单——这才是创业公司的最优解。
安全提示：别在生产环境直接调用外部 Embedding API 而不做缓存和限流！我们有一次因为用户高频搜索，OpenAI 账单差点爆掉，还好加了 Redis 缓存层才救回来。
面试题里藏着最佳实践
作为团队里唯一会出后端面试题的人，我有个习惯：把真实项目中的坑，变成面试题。
比如有次线上服务突然慢了，查了半天发现是某个 SQL 没加索引，而这个字段恰恰是 Embedding 向量计算后的聚类标签。于是我就出了这么一道题：
“假设你有一个商品表，每条记录包含一个 768 维的 embedding 向量。现在要支持‘找相似商品’功能，你会如何设计存储和查询方案？请考虑性能、成本和可维护性。”
候选人答得五花八门：有的说全放内存，有的说用 Redis Sorted Set，还有的直接上 Elasticsearch。但真正加分的回答，是那些能权衡业务规模、数据更新频率、查询 QPS 的人。
这反过来也提醒我：技术决策必须考虑上下文。如果你的产品还在 PMF（Product-Market Fit）阶段，别急着搞分布式向量数据库；如果日活百万，那可能真得上 Milvus。
教程≠照搬，得“本地化”
网上关于 Embedding 的教程太多了，但大多数都是 Jupyter Notebook 里的理想场景：干净的数据、无限的算力、没有并发压力。
我在尝试复现某篇“用 Sentence-BERT 实现语义搜索”的教程时，就吃了大亏。教程里用 sentence-transformers 库加载模型，一行代码搞定：
from sentence_transformers import SentenceTransformer
model = SentenceTransformer('all-MiniLM-L6-v2')
看起来很简单对吧？但放到我们 Flask 服务里，每次请求都加载模型？那服务器早就 OOM 了。后来改成全局单例 + 异步队列处理，才稳住。
更坑的是，教程完全没提输入清洗。用户搜“连衣裙 夏天 清凉 仙女风！！！”这种带感叹号、空格混乱的 query，直接喂给模型效果很差。我们加了一层正则清洗 + 分词归一化，准确率才上来。
所以我的建议是：看教程时，永远问一句——这在我的产品里怎么落地？
产品思维比技术更重要
作为全栈，我经常被拉去参加产品评审会。一开始我很抵触：“我又不是产品经理，聊这些干嘛？”但后来发现，懂产品，才能做对技术决策。
举个例子：我们有个“智能客服”功能，最初想用大模型做意图识别 + 知识库问答。技术上可行，但老板问了一个灵魂问题：“用户真的需要 AI 客服吗？还是他们只想快速找到退货入口？”
调研后发现，80% 的咨询都是“怎么退货”“物流到哪了”。于是我们砍掉了 fancy 的对话系统，改用规则引擎 + FAQ 匹配，结合简单的 Embedding 相似度兜底。上线后，解决率反而更高，因为路径更短、响应更快。
技术是手段，不是目的。产品目标才是北极星。
安全意识：别让探索变成事故
说到安全，我必须吐槽一次血泪教训。
有次为了快速验证 Embedding 在用户行为分析中的效果，我把用户 ID、设备信息、点击序列一股脑喂给模型训练。本地跑完觉得效果不错，正准备推测试环境，被安全同事拦住了：“你这数据脱敏了吗？GDPR 看过没？”
当场冷汗直流。赶紧回滚，重新设计 pipeline：只传匿名化的 session ID，原始行为日志走内部加密通道，模型训练在隔离 VPC 里跑。
从此以后，我给自己立了三条铁律：
- 任何涉及用户数据的实验，必须先过隐私评审
- 外部 API 调用必须加熔断 + 配额限制
- 模型输出不能直接展示给用户，必须经过业务逻辑过滤
技术探索可以激进，但安全底线不能破。
创业公司的“最佳实践”长什么样？
说了这么多，到底什么才是适合我们的“最佳实践”？我总结了几个原则：
| 原则 | 说明 | 反面案例 |
|---|---|---|
| 小步快跑，快速验证 | 先用最小成本跑通 MVP，再迭代 | 一上来就搭完整 MLOps 平台 |
| 能用开源就别造轮子 | 优先选成熟、社区活跃的方案 | 自研向量数据库，结果半年没上线 |
| 监控先行 | 任何新功能必须带 metrics + 日志 | 功能上线三天后才发现延迟高 |
| 文档即代码 | 设计文档、接口定义随代码提交 | 口头交接，新人一脸懵 |
| 技术债要记账 | 明确记录哪些是临时方案 | “先这样吧，后面再改” → 永远不改 |
我们现在的 Embedding 服务架构就很“务实”：
- 模型：OpenAI text-embedding-ada-002（够用、稳定）
- 存储：PostgreSQL + pgvector（无需新组件）
- 缓存：Redis（避免重复计算）
- 限流：Nginx + Lua 脚本（防刷）
- 监控：Prometheus + Grafana（延迟、错误率、QPS）
没有 fancy 的架构图，但扛住了双 11 流量，运维成本低，新人三天就能上手。
最后：别怕“不会”，但要会“学”
说实话，一年前我连 Embedding 是啥都不知道。但因为产品需要，硬着头皮啃论文、跑 demo、问 ChatGPT（是的，我让它帮我解释 Cosine Similarity 的数学原理），慢慢就搞明白了。
在深圳这片腾讯、字节、华为扎堆的地方，焦虑是常态。但创业公司的好处是：你可以快速试错，快速成长。没人要求你精通所有，但你要有“把事情搞定”的能力。
所以，别被“最佳实践”吓住。所谓最佳，不过是“在当前约束下，最不坏的选择”。
下次当你面对一个新技术、一个模糊需求、一个临近的 deadline 时，记住：
- 先问产品目标是什么
- 再评估资源和风险
- 用最小闭环验证
- 加上安全护栏
- 然后，动手干
搞定了，你就又多了一个可以写进简历的故事——或者，出一道新的面试题 😏
P.S. 上周五那个 502 错误，最后发现是 Nginx 的 proxy_buffer_size 设置太小，Embedding 返回的 JSON 体太大被截断了。改完配置，服务恢复正常。凌晨一点，我关掉电脑，走出大厦，深圳的夜风有点热，但心里踏实。
评论 0