1. 项目概述当Claude遇上向量数据库最近在折腾大模型应用开发的朋友估计都绕不开一个核心痛点如何让Claude这类大语言模型LLM处理超出其原生上下文窗口的长文档或海量私有数据直接硬塞进去Token费用吃不消模型性能也会断崖式下跌。这就是“zilliztech/claude-context”这个项目要解决的核心问题。简单来说这是一个专为Claude API设计的上下文增强工具包。它不修改模型本身而是通过一套工程化的“外挂”方案将你的长文本、知识库甚至是实时数据变成Claude可以高效、精准“查阅”的资料库。其核心原理是现在RAG检索增强生成架构的典型实践先将文档切片、向量化存入Milvus这类高性能向量数据库当用户提问时先从库中检索出最相关的片段再将片段和问题一起交给Claude生成答案。我花了些时间深度使用和拆解了这个项目它绝不仅仅是一个简单的示例脚本而是一个提供了生产级参考的脚手架。从文档加载、文本分割、向量化嵌入到检索、提示词工程和对话历史管理它把构建一个基于Claude的智能问答或文档分析应用的关键路径都跑通了。对于想快速验证想法、学习RAG全链路技术栈或者需要为一个垂直领域如客服、法律、金融分析搭建专属AI助手的开发者来说这个项目是一个极佳的起点。2. 核心架构与设计思路拆解2.1 为什么选择RAG而非微调面对大模型的“知识”局限业界主要有两条路微调Fine-tuning和检索增强生成RAG。这个项目选择了后者这是一个非常务实且主流的选择。微调相当于给模型“灌输”新知识让它成为某个领域的专家。但这需要高质量的标注数据、不菲的训练成本并且知识更新困难——每次有新文档都要重新训练。更重要的是微调后的模型可能会“遗忘”原有的一些通用能力或者产生“幻觉”将训练数据中的细节错误地泛化。而RAG走的是“即查即用”的路子。它把大模型看作一个推理能力超强但记忆力有限的大脑而向量数据库就是它的“外部超级记忆体”。当需要回答特定问题时先去记忆体里查找相关资料然后基于这些资料进行推理作答。这样做的好处显而易见成本低无需训练只需一次性的文档处理嵌入计算和存储。知识更新实时向数据库插入新文档向量知识立即生效。来源可追溯生成的答案可以关联到具体的源文档片段这对于法律、医疗等需要严谨出处的场景至关重要。避免幻觉强制模型在给定上下文中寻找答案减少了胡编乱造的可能。claude-context项目的设计正是基于RAG的最佳实践它清晰地分离了“检索”和“生成”两个阶段使得整个系统模块化易于理解和扩展。2.2 技术栈选型背后的考量项目的技术选型体现了现代AI应用开发的典型搭配Claude (Anthropic API): 作为生成核心。Claude系列模型如Claude 3 Opus, Sonnet, Haiku以强大的推理能力、良好的指令遵循和较低的无用输出率著称。相比其他模型它在处理复杂逻辑和长文档理解上表现突出非常适合作为RAG的“大脑”。Milvus / Zilliz Cloud: 作为向量存储与检索核心。这是Zilliz公司的开源向量数据库也是该项目开发者的背景所在。Milvus的优势在于能高效处理海量向量数据的近似最近邻搜索ANN支持动态schema、多种索引类型如IVF_FLAT, HNSW和标量过滤性能在生产环境中久经考验。项目直接使用其Python SDK进行交互。LangChain / LlamaIndex: 项目可能借鉴或使用了这类框架的思想。虽然代码中可能没有直接引入但其模块设计——文档加载器Document Loader、文本分割器Text Splitter、向量存储接口VectorStore——与这些流行框架的抽象层高度一致。这降低了开发者的理解成本也方便未来集成更丰富的工具链。Embedding 模型: 这是将文本转化为向量的关键。项目很可能默认使用了OpenAI的text-embedding-ada-002或其后续版本因为它与Claude API同属一个生态易于集成。当然也可以替换为开源模型如BGE、Sentence-Transformers等这需要在嵌入质量、速度和成本之间权衡。注意这个技术栈不是固定的。你可以根据需求将Claude替换为GPT-4、Gemini或本地部署的Llama 3将Milvus替换为Pinecone、Weaviate或PGVector。项目的价值在于提供了一个完整、可工作的范式而非绑定某个特定服务。2.3 核心工作流解析整个项目的工作流可以清晰地分为两个阶段索引构建和查询检索。索引构建阶段离线/预处理文档加载从本地文件PDF, Word, TXT、网页或数据库中读取原始文本。文本分割使用滑动窗口、按段落或按语义等方法将长文档切割成大小适中的“块”Chunks。块的大小和重叠度是影响检索精度的关键参数。向量化调用Embedding模型将每个文本块转换为一个高维向量例如1536维。这个向量在数学上代表了文本的语义。向量入库将文本块、对应的向量以及元数据如来源文件名、页码等一并存储到Milvus集合Collection中。Milvus会为这些向量建立索引以加速后续的检索。查询检索阶段在线问题向量化将用户提出的自然语言问题使用同样的Embedding模型转化为向量。语义检索在Milvus中执行向量相似度搜索如余弦相似度找出与问题向量最相似的K个文本块例如前5个。上下文组装将这K个文本块作为“参考上下文”与用户的原始问题一起按照特定的提示词模板进行组装构建出最终发送给Claude的完整提示Prompt。生成与返回Claude模型基于组装好的提示生成回答并将答案连同可选的引用来源来自哪个文本块返回给用户。这个工作流是项目的骨架理解了它你就掌握了绝大多数RAG应用的基本原理。3. 关键模块深度剖析与实操要点3.1 文档处理文本分割的艺术与陷阱文本分割是RAG流水线的第一个关键环节分割的好坏直接决定检索质量。claude-context项目里使用的分割策略值得仔细研究。常见的分割器类型固定长度分割最简单的按字符数切分。优点是简单可控缺点是可能粗暴地切断一个完整的句子或概念。递归字符分割按分隔符如“\n\n”, “.”, “,”优先级递归切割直到块大小符合要求。能更好地保持语义段落完整性。语义分割利用模型如BERT计算句子间的语义相似度在语义变化大的地方进行切割。效果最好但计算成本高。实操心得与参数调优 项目很可能采用了递归字符分割这是平衡效果与复杂度的常用选择。你需要关注两个核心参数chunk_size: 每个文本块的大小通常按Token数计如500-1000。太小会导致信息碎片化检索到的上下文不完整太大会引入噪声降低检索精度同时增加Claude处理长上下文的负担和成本。chunk_overlap: 块之间的重叠长度如100-200 Token。重叠是为了防止一个完整的语义单元如一个关键概念的解释被恰好切分在两个块的边界导致检索时丢失重要信息。踩坑记录在处理技术文档或合同等结构化文本时我曾机械使用固定分割结果经常把代码示例或一个完整的条款拦腰截断。后来改为优先按“\n\n”和标题分割并适当增加chunk_overlap检索的准确率立刻提升。对于中文文档还要注意按句号分割可能不如按逗号或语义分割有效因为中文句号使用不如英文严格。3.2 向量化Embedding模型的选择与影响文本变成向量的过程是语义搜索的基石。不同的Embedding模型在不同的领域和语言上表现差异巨大。模型选型考量维度与性能OpenAI的text-embedding-3-small/large维度可选较小的维度检索速度更快存储成本更低但可能损失一些细微语义区分度。需要根据数据量和精度要求权衡。上下文长度确保Embedding模型支持的上下文长度大于你的chunk_size。多语言支持如果你的文档包含多语言需要选择像text-embedding-3或开源模型BGE-M3这类在多语言评测中表现优异的模型。领域适配通用模型在特定领域如生物医学、法律可能表现不佳。可以考虑使用领域数据继续训练微调开源Embedding模型或用领域语料在检索时进行重排序Re-ranking。在项目中集成其他Embedding模型 项目的代码通常会将Embedding调用封装成一个函数或类。替换模型通常很简单以使用Hugging Face的sentence-transformers为例# 原版可能使用OpenAI from openai import OpenAI client OpenAI() def get_embedding(text, modeltext-embedding-3-small): response client.embeddings.create(inputtext, modelmodel) return response.data[0].embedding # 替换为Sentence Transformers from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 中文模型 def get_embedding_st(text): # 注意有些模型需要添加指令前缀 instruction 为这个句子生成表示以用于检索相关文章 embeddings model.encode([instruction text], normalize_embeddingsTrue) return embeddings[0].tolist() # 转换为列表替换后需要确保在索引构建和查询检索时使用同一模型否则向量空间不一致检索将失效。3.3 检索策略超越简单的相似度搜索项目默认使用向量相似度如余弦相似度进行检索这是基础。但在生产环境中仅有语义检索往往不够。混合搜索Hybrid Search 这是提升召回率的关键技术。它结合了稠密检索Dense Retrieval即向量相似度搜索擅长捕捉语义相关性。稀疏检索Sparse Retrieval如BM25基于关键词匹配擅长捕捉精确的词汇匹配。例如用户问“Python中如何读取CSV文件”向量搜索可能找到关于“数据处理”、“pandas库”的段落而BM25能精准锁定包含“read_csv”这个具体函数名的段落。Milvus支持在检索时同时执行两种搜索并按分数融合。多路召回与重排序Reranking多路召回使用不同的检索方式如不同Embedding模型、不同查询改写得到多组候选结果。重排序用一个更精细但更慢的交叉编码器模型Cross-Encoder对召回的候选片段和问题进行相关性打分重新排序。这能显著提升Top结果的精确度。虽然claude-context项目可能未直接实现这些高级策略但其架构是开放的。你可以在检索到初步结果后插入一个重排序步骤再将最相关的几个片段送给Claude。# 伪代码示例基础检索后增加重排序 from sentence_transformers import CrossEncoder reranker CrossEncoder(cross-encoder/ms-marco-MiniLM-L-6-v2) # 假设docs是从Milvus初步检索到的文本块列表query是用户问题 pairs [[query, doc.text] for doc in docs] rerank_scores reranker.predict(pairs) # 根据重排序分数对docs重新排序 ranked_docs [doc for _, doc in sorted(zip(rerank_scores, docs), reverseTrue)] top_k_reranked ranked_docs[:3] # 取重排序后的前3个4. 从零搭建与核心代码实现4.1 环境准备与依赖安装假设你已经拥有Anthropic和Zilliz Cloud或自建Milvus的API密钥。# 1. 克隆项目假设项目存在此处为示意 # git clone https://github.com/zilliztech/claude-context.git # cd claude-context # 2. 创建虚拟环境推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 3. 安装核心依赖 pip install anthropic pymilvus openai python-dotenv # 根据文档处理需求可能还需要 pip install pypdf langchain langchain-community tiktoken创建.env文件管理密钥ANTHROPIC_API_KEYyour_anthropic_key_here ZILLIZ_CLOUD_URIyour_zilliz_cloud_uri ZILLIZ_CLOUD_TOKENyour_zilliz_cloud_token OPENAI_API_KEYyour_openai_key_for_embedding # 如果使用OpenAI Embedding4.2 构建向量知识库一个完整的索引示例让我们实现一个完整的索引流程将一份PDF技术手册存入Milvus。import os from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType, utility from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from openai import OpenAI from dotenv import load_dotenv import time load_dotenv() # 1. 连接Milvus connections.connect( aliasdefault, urios.getenv(ZILLIZ_CLOUD_URI), tokenos.getenv(ZILLIZ_CLOUD_TOKEN) ) # 2. 定义集合Schema fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nametext, dtypeDataType.VARCHAR, max_length65535), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1536), # 适配你的Embedding维度 FieldSchema(namesource, dtypeDataType.VARCHAR, max_length255), FieldSchema(namepage, dtypeDataType.INT64) ] schema CollectionSchema(fields, descriptionClaude Context Knowledge Base) collection_name tech_docs # 删除已存在的集合如果是测试 if utility.has_collection(collection_name): utility.drop_collection(collection_name) # 创建集合 collection Collection(namecollection_name, schemaschema) # 3. 创建索引HNSW是常用高性能索引 index_params { index_type: HNSW, metric_type: COSINE, # 余弦相似度 params: {M: 16, efConstruction: 200} # HNSW参数M影响精度和内存efConstruction影响构建速度 } collection.create_index(field_nameembedding, index_paramsindex_params) collection.load() # 加载集合到内存以进行搜索 # 4. 加载并分割文档 loader PyPDFLoader(./your_technical_manual.pdf) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, length_functionlen, separators[\n\n, \n, 。, , , , , 、, , ] ) chunks text_splitter.split_documents(documents) print(f将文档切分为 {len(chunks)} 个块。) # 5. 生成嵌入并插入 openai_client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) data_to_insert [] for i, chunk in enumerate(chunks): text_content chunk.page_content # 生成嵌入向量 response openai_client.embeddings.create( inputtext_content, modeltext-embedding-3-small ) embedding response.data[0].embedding data_to_insert.append({ text: text_content, embedding: embedding, source: chunk.metadata.get(source, unknown), page: chunk.metadata.get(page, 0) }) # 分批插入避免单次请求过大 if len(data_to_insert) 100: collection.insert(data_to_insert) print(f已插入 {i1} 个块...) data_to_insert [] time.sleep(0.1) # 避免速率限制 # 插入剩余数据 if data_to_insert: collection.insert(data_to_insert) print(索引构建完成) collection.flush() # 确保数据持久化4.3 实现检索增强的问答链索引建好后实现问答的核心就是检索提示词组装。import anthropic from pymilvus import Collection def retrieve_and_answer(question, collection_nametech_docs, top_k5): # 1. 连接集合 collection Collection(collection_name) collection.load() # 2. 将问题向量化使用与索引时相同的模型和参数 response openai_client.embeddings.create( inputquestion, modeltext-embedding-3-small ) query_embedding response.data[0].embedding # 3. 在Milvus中执行向量搜索 search_params {metric_type: COSINE, params: {ef: 50}} # ef是HNSW搜索时的参数 results collection.search( data[query_embedding], anns_fieldembedding, paramsearch_params, limittop_k, output_fields[text, source, page] # 指定需要返回的字段 ) # 4. 组装上下文 context_parts [] source_metadata [] for hits in results: for hit in hits: context_parts.append(hit.entity.get(text)) source_metadata.append({ source: hit.entity.get(source), page: hit.entity.get(page), score: hit.score }) context \n\n---\n\n.join(context_parts) # 用分隔符清晰隔开不同片段 # 5. 构建Claude提示词 prompt_template f请基于以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题请直接说明“根据提供的资料无法回答此问题”不要编造信息。 上下文信息 {context} 问题{question} 请给出详细、准确的回答并在回答末尾注明所参考的上下文片段来源例如来自[文件名]第X页。 # 6. 调用Claude API client anthropic.Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) message client.messages.create( modelclaude-3-sonnet-20240229, # 可根据需求选择Haiku, Opus等 max_tokens1500, temperature0.2, # 较低的温度使输出更确定更适合事实性问答 messages[ {role: user, content: prompt_template} ] ) answer message.content[0].text return answer, source_metadata # 使用示例 question 在XX系统中如何进行安全配置审计 answer, sources retrieve_and_answer(question) print(问题, question) print(\n答案, answer) print(\n参考来源) for src in sources: print(f - 文件{src[source]}, 页码{src[page]}, 相关性得分{src[score]:.3f})这个流程清晰地展示了从问题到答案的完整链路。提示词模板的设计至关重要它明确指令模型基于上下文回答并要求注明来源这极大地提升了答案的可信度和可追溯性。5. 性能优化与生产级考量5.1 索引策略与查询参数调优要让RAG系统飞起来需要对Milvus的索引和搜索参数有深入理解。索引参数以HNSW为例M每个节点在图中连接的边数。值越大图越稠密精度越高但构建时间和内存占用也越大。通常设置在16-64之间。对于千万级以下的数据集24或32是个不错的起点。efConstruction构建索引时用于搜索的候选集大小。值越大构建的索引质量越高但构建越慢。通常设置为M的5-10倍。搜索参数ef搜索时遍历的候选集大小。这是在线查询时最重要的性能旋钮。ef越大搜索越精确但耗时越长。在保证召回率的前提下尽量使用较小的ef如32-128。可以通过在测试集上绘制“ef-召回率”曲线来找到平衡点。metric_type相似度度量标准。COSINE余弦相似度是最常用的对文本向量效果很好。IP内积在向量已归一化时与余弦等价。L2欧氏距离也可用但需注意其距离意义与余弦相反。实操建议在系统开发初期可以用一个小的验证集例如100个QA对进行自动化测试。固定其他参数调整ef观察召回率检索到的相关片段占所有相关片段的比例和查询延迟的变化选择一个满足业务要求的最优值。5.2 提示词工程引导Claude更好地利用上下文原始的上下文拼接可能不够Claude有时会“忽略”上下文中的细节。需要通过提示词进行强力引导。进阶提示词技巧指令明确化不仅仅是“基于上下文回答”可以更具体。不佳“请根据上下文回答。”更佳“你的回答必须严格且仅依据提供的上下文信息。对于上下文中明确提及的事实请直接引用。对于上下文中未提及的信息即使你知道也不要在答案中体现。”结构化输出要求模型按特定格式回答便于后续程序解析。请按以下格式回答 **答案摘要**[1-2句话总结] **详细步骤** 1. ... 2. ... **参考依据**来自文档《[文件名]》第X页内容“...”分步思考Chain-of-Thought对于复杂问题要求模型先分解。请按以下步骤思考并回答问题 1. 首先从上下文中找出与问题直接相关的所有信息。 2. 然后分析这些信息之间的逻辑关系。 3. 最后综合这些信息组织成连贯的答案。负面指令明确告诉模型不要做什么。不要对上下文信息进行总结以外的扩展。 不要使用上下文以外的知识。 如果上下文信息矛盾或不足请明确指出。在项目中应用你可以将prompt_template变量升级为一个更复杂的函数根据问题类型事实型、步骤型、分析型动态选择不同的模板。5.3 对话历史管理与上下文窗口的智能利用在多轮对话中如何管理历史记录和不断增长的上下文是一个挑战。简单地将所有历史对话都放入上下文会迅速耗尽Token限额。解决方案向量化历史对话将每一轮的用户问题和模型回答作为一个文本块存入另一个专门的“对话历史”向量集合。当进行新的一轮对话时不仅检索知识库也检索相关的历史对话片段。这相当于给了模型一个“短期记忆”。总结压缩在对话轮数达到一定长度后例如5轮调用Claude的“中间”能力对之前的对话历史进行摘要然后用摘要替换掉详细的历史记录再继续新的对话。这能有效控制上下文长度。选择性记忆不是所有历史对话都同等重要。可以设计规则只保留那些包含关键决策、用户偏好或重要事实的回合。# 伪代码简单的对话历史总结策略 def manage_conversation_history(full_history_messages, max_rounds5): full_history_messages: 列表包含所有轮次的 {role: user/assistant, content: ...} if len(full_history_messages) max_rounds * 2: # 每轮包含user和assistant两条消息 return full_history_messages # 需要总结 messages_to_summarize full_history_messages[:-max_rounds*2] # 取需要被总结的旧历史 recent_messages full_history_messages[-max_rounds*2:] # 保留最近的几轮 summary_prompt f请将以下对话历史浓缩成一个简洁的摘要保留核心事实、用户的主要需求和已做出的关键决定。 对话历史 {format_messages(messages_to_summarize)} 摘要 # 调用Claude生成摘要 summary call_claude(summary_prompt, modelclaude-3-haiku) # 用小模型以节省成本 # 构建新的历史摘要 近期对话 new_history [ {role: user, content: 以下是之前对话的摘要 summary}, {role: assistant, content: 好的我已了解之前的讨论背景。} ] recent_messages return new_history6. 常见问题、故障排查与进阶方向6.1 高频问题与解决方案速查表问题现象可能原因排查步骤与解决方案检索结果不相关1. Embedding模型不匹配索引和查询用的模型不同2. 文本分割不合理块太大或太小3. 搜索参数ef设置过小4. 查询问题表述模糊1.检查一致性确保索引和查询使用完全相同的Embedding模型和参数。2.调整分割尝试减小chunk_size如500或增加chunk_overlap如150。对于技术文档可尝试按章节/标题分割。3.调大ef逐步增加ef值如50-100-200观察召回率变化。4.查询改写尝试对用户问题进行同义改写或扩展后再进行向量化。Claude回答“未在上下文中找到”或胡编乱造1. 提示词指令不够强硬2. 检索到的上下文确实不包含答案3. 模型温度temperature参数过高1.强化提示词在提示词中使用更严厉的限制性语言如“必须”、“严格仅基于”。2.检查检索打印出检索到的上下文人工判断是否包含答案。如果不包含需优化检索见上一条。3.降低温度将temperature设为0.1-0.3减少随机性。插入或查询Milvus超时/报错1. 网络连接问题2. Milvus集合未加载load()3. 插入数据量单次过大4. Zilliz Cloud实例规格不足1.检查连接验证URI和Token测试网络连通性。2.确认状态查询前务必执行collection.load()。3.分批操作单次插入数据不要超过256MB可分批次插入并添加短暂延迟。4.升级资源检查云控制台确认CPU、内存和磁盘是否过载。处理长文档时程序内存溢出1. 一次性加载整个大文件到内存2. 生成的嵌入向量列表过大1.流式处理使用支持流式读取的文档加载器或手动分片读取文件。2.分批嵌入与插入如示例代码所示每处理100-200个块就插入一次数据库并清空临时列表。回答速度慢1. Embedding调用延迟高尤其是远程API2. Milvus搜索ef参数过高3. Claude模型响应慢如使用Opus1.缓存Embedding对不变的文档Embedding可以本地缓存避免重复计算。2.优化ef在可接受的精度损失下降低ef值。3.使用更快模型在非关键路径或用Haiku模型生成摘要用Sonnet/Opus做最终答案生成。6.2 效果评估如何知道你的RAG系统好不好搭建起来只是第一步评估和迭代才是持续改进的关键。不能只靠感觉需要量化指标。核心评估维度检索质量命中率Hit Rate对于一组测试问题至少有一个相关文档被检索到在top-k结果中的比例。平均精度均值Mean Average Precision, MAP考虑相关文档在检索结果中的排序位置更精细的指标。生成质量忠实度Faithfulness答案是否严格基于提供的上下文有无幻觉。可以通过让另一个LLM判断或基于规则匹配来评估。答案相关性Answer Relevance答案是否直接回答了问题。有用性Usefulness人工评估答案是否清晰、完整、有帮助。简易评估流程构建一个“黄金测试集”包含50-100个问题以及每个问题对应的标准答案和来自知识库的“标准相关文档片段”。自动化测试检索运行测试问题计算Hit RateKK通常取3或5。自动化测试生成用RAG系统回答测试问题并利用GPT-4或Claude本身作为“裁判”让它根据标准答案和上下文从“忠实度”、“相关性”等维度对生成的答案进行打分例如1-5分。分析短板如果检索分数低优化分割和检索策略如果生成分数低优化提示词和上下文组装方式。6.3 从Demo到生产下一步进阶方向当你用claude-context跑通流程后可以考虑以下方向将其打磨成一个真正的生产系统引入异步与流式处理文档索引可能是耗时操作使用asyncio或任务队列如Celery进行异步处理不阻塞主应用。对于Claude的回答可以使用流式APIstreamTrue实现打字机效果提升用户体验。构建Web应用与服务化使用FastAPI或Flask将核心功能封装成RESTful API方便前端如ChatUI调用。添加认证、限流、日志监控等生产级特性。实现更复杂的代理Agent逻辑不止于问答。让系统能根据问题判断是否需要检索、检索哪些集合、是否需要调用外部工具如计算器、搜索引擎、API甚至进行多步规划。这可以基于LangChain的Agent框架构建。持续学习与知识更新设计一个流程当用户反馈某个答案不好或提供了新文档时系统能自动触发相关片段的重新索引或提示词的优化。多模态扩展如果文档包含大量图片、表格可以考虑使用多模态Embedding模型如CLIP和Milvus对非文本内容进行索引实现“根据图片找文字”或“根据描述找图表”的增强检索。zilliztech/claude-context项目就像一副精良的骨架展示了RAG系统的核心构造。而真正的血肉——业务逻辑的深度、性能的优化、稳定性的保障、用户体验的打磨——则需要你基于这副骨架结合具体的业务场景去填充和创造。从这个项目出发你完全有能力构建出属于自己的、智能且可靠的第二代AI应用。