Go 中无现成RAG框架，需自行搭建管道，关键在Embedding tokenizer、向量库索引与LLM上下文窗口的协同调优。
Go 里没有现成的 RAG 框架，得自己搭管道
Go 语言生态中目前没有像 Python 的 llama-index 或 langchain 那样开箱即用的 RAG 全栈框架。这意味着你无法通过 go get github.com/xxx/rag 一键集成检索+重排序+LLM 调用+提示工程整条链路。所有模块都得选型、粘合、容错——尤其是向量检索和 LLM 接口这两块，最容易卡住。
常见错误现象：panic: unsupported vector dimension（向量维度和模型不匹配）、context deadline exceeded（Embedding 请求超时未设 timeout）、422 Unprocessable Entity（LLM API 输入格式错，比如把 messages 写成 prompt）。
实操建议：
- Embedding 优先用开源模型 + 本地推理：比如
bert-base-zh用gomlx或调onnxruntime-go加载 ONNX 模型；避免直接调 HuggingFace Inference API（延迟高、配额紧、中文支持弱） - 向量库选
qdrant-go或milvus-sdk-go，别用纯内存的go-knn——它不支持增量插入、无索引优化、维数稍高就慢 - LLM 接口统一抽象为
type LLMClient interface { Generate(ctx context.Context, prompt string, opts ...LLMOption) (string, error) }，方便后续切换 OpenAI / Ollama / vLLM / 本地 GGUF
Embedding 向量化必须对齐模型 tokenizer 和 truncation 行为
中文 RAG 效果差，八成出在 Embedding 阶段——不是向量不准，而是切分和截断逻辑和原始模型训练时不一致。比如你用 sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 的 ONNX 版本，但 Go 侧 tokenizer 用的是空格分词或正则切句，没走模型配套的 WordPiece 流程，向量就废了。
使用场景：文档 chunk 是“《三体》中‘宇宙社会学’包含两个公理”，而 embedding 模型实际看到的是“《三体》中‘宇宙社会学’包含两个公理[SEP]”，漏掉 [SEP] token 就可能让语义偏移。
实操建议：
- 不要自己写中文分词做 chunking；用模型发布方提供的 tokenizer JSON 和 vocab.txt，用
transformers-go或手写tokenize()函数复现其逻辑（注意 lower/strip/cls/sep/pad/id mapping） - chunk 长度严格按模型 max_length - 2（预留 CLS+SEP）；例如 max_length=512 → chunk 最长 510 字符，且必须按 token 数截，不是 rune 数
- 调试时打印前 3 个 token 的
id和对应文本，和 Python 端对比是否一致；不一致立刻停，别往下走
检索后必须做 cross-encoder 重排序，不能只靠向量相似度
单纯用 cosine similarity 排 top-k，对中文长尾 query（如“如何理解降维打击在黑暗森林理论中的作用”）效果极差——向量空间里“降维打击”和“维度”“打击”各自靠近，但语义相关性低。必须引入轻量级 cross-encoder 做 query-doc pair 打分。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
性能影响明显：cross-encoder 是交互式编码，10 个 chunk 就要跑 10 次前向；若用 full BERT，Go 侧 ONNX 推理单次 >300ms，不可接受。
实操建议：
- 选
cross-encoder/ms-marco-MiniLM-L-6-v2这类蒸馏模型（ONNX 小于 80MB），用onnxruntime-go跑，实测单次 ~45ms（i7-11800H） - 重排序只对向量检索返回的 top-20 chunk 做，别全量；且提前过滤掉长度 80% 的 chunk
- 打分不用 softmax，直接取
logits[0][1]（二分类中“相关”类 logits），省去后处理；阈值设 4.2 可平衡召回与精度
LLM 提示模板要硬编码 system message + context 插槽 + 显式 stop token
Go 调 LLM API 时最常犯的错：把 context 拼进字符串就发出去，没控制长度、没防注入、没设 stop。结果是模型续写停不下来，或者把参考文献编号当答案输出（如“根据[3]……”），或者被用户输入里的 ``` 搞乱结构。
参数差异关键点：temperature=0.1（RAG 要确定性）、max_tokens=512（防无限生成）、stop=["\n\n", "参考资料：", "```"]（多 stop 更稳）。
实操建议：
- 模板用
text/template预编译，而非fmt.Sprintf：防止 context 里有{{导致 panic；模板内用{{.Context | printf "%.2000s"}}截断，再 trimSpace - system message 必须声明角色和约束：“你是一个严谨的学术助手，仅基于以下参考内容回答问题。若内容未提及，回答‘未在提供的资料中找到依据’。”
- 每次请求前校验 context 总 token 数（用同款 tokenizer 统计），超
model_ctx_len * 0.6就丢弃最旧 chunk——别指望 LLM 自己 trunc
真正难的不是某一行代码，而是 embedding tokenizer、向量库索引参数、LLM 上下文窗口这三者的隐式耦合。改一个就要同步调另外两个，否则白天测得好好的，晚上加一批新文档就全崩。上线前至少拿 5 个真实用户 query 走通 end-to-end，并人工核对每步中间输出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
