上一篇使用 FAISS 完成了本地向量检索。FAISS 主要管理向量和位置编号，原始文本、业务 ID 与 Metadata 通常需要由应用额外维护。 这一篇改用 Chroma 原生 API。Chroma 可以在一个 Collection 中

上一篇比较了 FAISS、Chroma 和 Milvus。这一篇先使用最轻量的 FAISS，不启动数据库服务，并通过 LangChain 的 FAISS 封装管理向量、原文和元数据。 我们会让本地 Qwen3-Embedding-0.6B

上一篇使用 CSV 保存了 100 条评论及其 Embedding，然后在查询时逐行读取向量、计算余弦相似度并排序。这个方法容易理解，也能帮助我们验证语义搜索的完整过程，但数据量继续增加后会遇到几个问题： 每次查询都要扫描全部向量。 向量

上一篇已经完成 Qwen3-Embedding-0.6B 的本地部署，也分别使用了 LangChain 的 embed_documents() 和 embed_query()。前文只比较了几句话，这一篇把这些知识放进一个更接近真实使用场景的

本文开始使用真正的 Embedding 模型。我们会下载 Qwen/Qwen3-Embedding-0.6B，使用 SentenceTransformer 生成 1024 维向量，比较几句话的语义相似度，最后通过 LangChai

RAG 的第一步不是直接搭建知识库，而是先理解文本怎样变成可以检索和比较的向量。 本文讨论的是文本 Embedding 模型。它对外的使用方式与聊天模型不同：输入仍然是文字，但输出不再是回答，而是一串浮点数： 输入：苹果是一种常见的水果。