加载文档

挤时间搞技术探索与AI辅助编程的性能优化实践

晚上十点半，卧室里终于传来了俩娃均匀的呼吸声。我长舒一口气，轻手轻脚地带上房门，坐回书房。戴上降噪耳机，切到网易云的Lo-Fi Hip Hop歌单，属于我的“第二人生”才算真正开始。坐标北京，每天地铁通勤来回两小时，我基本都在闭目养神或者听技术播客。真正能静下心来敲代码、搞技术探索的，也就只有这深夜的几个小时了。

最近公司大环境你们懂的，“降本增效”喊得震天响。我们云原生团队负责维护的K8s集群规模翻了一倍，各种CRD和Helm Chart多得让人头皮发麻。上周五下午，产品经理又跑来找我，说线上有个核心业务的Pod频繁OOM重启，让我赶紧排查。我翻了几十个G的日志和YAML，眼睛都花了，当时真的想砸键盘。

为了不被这堆破事耗死，也为了晚上能早点搞完去陪娃，我决定在研发工具链上搞点技术探索，顺便给手头的AI辅助工具做一波深度的性能优化。

我首先盯上了IDE里的AI助手Continue。说实话，刚装上Continue的时候，体验挺惊艳的。但在我们这种动辄几十万行Go代码和海量YAML的项目里，它的上下文加载和代码补全速度简直慢得像树懒。有次我让它帮我写个K8s Admission Webhook，它转着圈卡了足足半分钟没反应，差点让我把鼠标甩出去。

这不行啊，时间就是生命，奶爸的时间更是按秒计算的。我开始死磕Continue的性能优化。核心思路就是“减负”。我仔细扒了它的配置，发现它默认会索引太多没用的文件，导致每次请求都带着巨大的上下文。

我重写了项目根目录下的.continue/config.json，除了常规的vendor、node_modules、.git，我还把那些几百KB的静态CRD定义文件、测试用的巨型Mock JSON以及历史归档日志全排除了。同时，调整了上下文窗口的Token限制，避免每次补全都把整个项目的摘要塞进去。

{
  "models": [
    {
      "title": "DeepSeek Coder",
      "provider": "openai",
      "model": "deepseek-coder",
      "apiBase": "http://localhost:11434/v1"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Starcoder",
    "provider": "ollama",
    "model": "starcoder2:3b"
  },
  "contextProviders": [
    { "name": "code" },
    { "name": "docs" }
  ],
  "customCommands": [],
  "experimental": {
    "contextMenu": true
  },
  "disableIndexing": false,
  "ignorePaths": [
    "vendor/**",
    "**/*.test.go",
    "deploy/crds/**", 
    "logs/**"
  ]
}

优化完配置后，我明显感觉Continue的补全延迟从之前的2秒多降到了500毫秒以内，丝滑了很多，写Go代码终于不用等得喝口水了。

搞定了IDE里的补全，我又把目光转向了团队内部的故障排查知识库。之前运维兄弟用LlamaIndex搭了个简单的RAG系统，把历史故障文档喂进去。但实际用起来，检索延迟高达3秒以上，而且经常答非所问，把A业务的报错张冠李戴给B业务。

我接手后，发现原来的实现太“naive”了。LlamaIndex默认的分块策略和纯向量检索，在面对我们这种包含大量报错堆栈和命令行输出的技术文档时，效果很差。我决定从LlamaIndex的底层查询引擎开刀，做一套针对技术文档的性能与准确率优化。

第一步，优化Chunking。把固定的512 token切分，改成了基于Markdown标题的语义切分，保证一个报错堆栈不会被拦腰截断。第二步，引入混合检索（Hybrid Search）。单纯靠向量相似度找关键字太弱了，我加上了BM25关键词检索，并用RRF做结果融合。

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.core.retrievers import RouterQueryEngine
from llama_index.core.tools import QueryEngineTool
from llama_index.retrievers.bm25 import BM25Retriever
from llama_index.core.query_engine import RetrieverQueryEngine
import Stemmer

documents = SimpleDirectoryReader("./k8s_troubleshooting_docs").load_data()

# 1. 语义向量检索 (处理模糊概念和自然语言提问)
vector_index = VectorStoreIndex.from_documents(documents)
vector_retriever = vector_index.as_retriever(similarity_top_k=5)

# 2. BM25 关键词检索 (处理具体的报错码、Pod名称等精确匹配)
bm25_retriever = BM25Retriever.from_defaults(
    docstore=vector_index.docstore, 
    similarity_top_k=5,
    stemmer=Stemmer.Stemmer("english"),
    language="english"
)

# 3. 构建混合查询引擎
# 这里为了性能，没有用复杂的LLM路由，而是直接做结果融合
from llama_index.core.postprocessor import SentenceTransformerRerank

# 引入Rerank模型进一步提升最终排序的准确率，虽然增加了一点计算开销，但减少了LLM的Token消耗
reranker = SentenceTransformerRerank(
    model="cross-encoder/ms-marco-MiniLM-L-2-v2", top_n=3
)

# 组合Retriever
from llama_index.core.retrievers import QueryFusionRetriever

fusion_retriever = QueryFusionRetriever(
    [vector_retriever, bm25_retriever],
    similarity_top_k=5,
    num_queries=1,  # 单查询模式，降低延迟
    mode="reciprocal_rerank",
    use_async=True, # 开启异步，提升并发检索性能
)

query_engine = RetrieverQueryEngine.from_args(
    fusion_retriever,
    node_postprocessors=[reranker]
)

# 测试查询
response = query_engine.query("Pod状态为CrashLoopBackOff且日志提示OOMKilled怎么排查？")
print(response)

这套组合拳打下来，效果立竿见影。为了让大家看得更直观，我跑了个压测，对比了一下优化前后的数据：

指标	优化前 (Naive RAG)	优化后 (Hybrid + Rerank)	提升效果
平均检索延迟	3.2s	0.8s	提速 300%
Top-3 命中率	65%	92%	准确率大幅提升
单次查询 Token 消耗	~1200	~600	成本减半

看着监控面板上降下来的延迟曲线，我长舒了一口气，终于搞定了，开心！

其实回过头来看，技术探索这事儿，真不能脱离实际业务去盲目追新。一开始我也想搞什么大模型微调，但算了一下算力成本和落地周期，果断放弃。对于咱们这种背负着业务deadline的打工人来说，用最小的成本解决最痛的痛点，才是最优解。性能优化也是同理，不是无脑堆硬件，而是要在架构和配置上抠细节。

现在，这套优化后的工具链已经在我们云原生团队内部推开了。运维兄弟再也不用翻半天文档找历史故障了，我写K8s YAML的速度也飞起。

看了一眼时间，快十二点了。合上电脑，明天还得早起挤地铁去公司跟产品经理对线呢。虽然每天带娃、通勤、加班连轴转挺累的，但能在这些细碎的时间里，用技术解决点实际问题，看着系统跑得越来越快，这大概就是咱们程序员独有的浪漫吧。不说了，睡觉去，明早还得给俩娃做早饭呢。