1. 项目概述：为代码库构建专属的“谷歌地图”

你有没有过这样的经历？面对一个庞大、陌生的代码仓库，就像被扔进了一座没有地图的迷宫。你想找一个处理用户认证的函数，或者想了解某个核心模块的调用链路，只能靠 grep 全局搜索关键词，然后在几十个结果里一个个点开查看，效率低下且容易遗漏上下文。又或者，新加入一个团队，面对数十万行代码，如何快速建立整体认知，理解业务逻辑的脉络？传统的IDE搜索和文档（如果存在的话）在这种场景下显得力不从心。

这个项目，就是要为你自己的代码库打造一个类似“谷歌地图”的智能导航系统。它不再是简单的字符串匹配，而是能理解代码语义的搜索引擎。你可以用自然语言提问，比如：“我们系统里是怎么处理支付失败重试的？”、“把用户订单数据导出为Excel的功能在哪？”、“找出所有调用了Redis缓存但没设置过期时间的代码片段”。系统不仅能精准定位到相关文件，还能高亮出具体代码段，并解释其上下文关系。

其核心在于，利用现代大语言模型（LLM）与向量数据库技术，将代码库转化为一个可语义查询的知识图谱。我通过结合LangChain和ChromaDB，搭建了一套轻量、可私有化部署的解决方案。LangChain负责编排整个处理流程，从代码解析、文本分割到调用LLM生成嵌入；ChromaDB则作为高效的向量存储与检索引擎。这套方案特别适合开发团队、开源项目维护者以及任何需要深度探索和理解复杂代码结构的工程师。

2. 核心架构与工具选型解析

2.1 为什么是“语义搜索”而非“文本匹配”？

传统 grep 或IDE搜索基于关键词的精确或模糊匹配，这存在明显局限。首先，它无法处理语义相似但表述不同的查询。例如，代码中写的是 handlePaymentFallback ，而开发者可能搜索“支付失败处理逻辑”。其次，它缺乏对代码结构和上下文的理解。一个名为 save 的函数可能出现在用户、订单、日志等不同模块中，关键词搜索会返回大量无关结果。

语义搜索通过“向量化”解决了这个问题。其核心思想是将代码片段（或自然语言问题）转换为数学上的高维向量（即嵌入向量）。这个向量就像是代码语义在数字空间中的一个“坐标点”。语义相似的代码，其向量在空间中的距离（通常用余弦相似度衡量）也会很近。当我们用自然语言提问时，问题也会被转换成向量，系统只需在向量空间中寻找与问题向量最接近的那些代码向量即可。

注意 ：这里的“语义”主要指通过模型学习到的统计语义关联，并非真正的程序逻辑理解。但对于代码检索、归类、问答等场景，其效果已远超传统方法。

2.2 技术栈深度剖析：LangChain + ChromaDB

1. LangChain： 智能化的流程编排框架 LangChain并非一个具体的模型，而是一个用于开发由LLM驱动的应用程序的框架。在这个项目中，我们主要利用其两大核心价值：

• 标准化组件（Components） ：它提供了加载器（Document Loaders）、文本分割器（Text Splitters）、向量化接口（Embeddings Models）、链（Chains）等标准化模块。例如，我们可以直接使用 TextLoader 来加载源代码文件，用 RecursiveCharacterTextSplitter 来按字符递归分割代码文本，保持函数、类的基本完整性。
• 流程编排（Orchestration） ：LangChain将“加载代码 -> 分割文本 -> 向量化 -> 存储 -> 检索 -> 生成答案”这一复杂流程标准化、模块化。我们可以像搭积木一样构建整个应用，无需关心各模块间繁琐的对接逻辑。特别是其 RetrievalQA 链，能轻松将检索器（从向量库查到的相关代码）与LLM（如GPT-4、ChatGLM等）组合起来，实现“检索增强生成”（RAG），直接给出答案而非仅仅返回代码片段。

2. ChromaDB： 轻量高效的嵌入式向量数据库 我们需要一个地方来存储所有代码片段转换成的向量，并支持快速的相似性检索。ChromaDB是当前开源领域的热门选择，原因如下：

• 嵌入式与易用性 ：它可以作为一个Python库直接安装使用（ pip install chromadb ），数据可以保存在本地磁盘，无需部署复杂的数据库服务（如Pinecone、Weaviate等云服务），极大简化了部署和运维成本。
• 性能与精度 ：底层使用高效的相似性搜索库（如HNSW算法），在千万级向量规模下也能保持毫秒级的检索速度。它直接支持余弦相似度、欧氏距离等常用度量方式。
• 与LangChain无缝集成 ：LangChain官方提供了 Chroma 集成类，只需几行代码即可完成向量库的创建、持久化和查询。

3. 嵌入模型（Embedding Model）的选择 这是决定语义搜索质量的核心。我们需要一个模型将文本（代码）转换为向量。

• 开源模型 ：如 all-MiniLM-L6-v2 （Sentence-Transformers库）。它体积小（约80MB），速度快，在通用文本语义相似度任务上表现良好，对代码也有一定的理解能力。适合本地化、对成本敏感的场景。

  # 安装依赖
  pip install sentence-transformers
  

• 专用代码模型 ：如OpenAI的 text-embedding-3-small 或 text-embedding-3-large ，以及专门针对代码训练的模型如 CodeBERT 。它们对代码语法、结构有更深的理解，生成的向量在代码检索任务上表现更优，但可能需要调用API（产生费用）或更高的本地计算资源。
• 选型心得 ：对于企业内部代码库，出于数据安全和成本考虑，我通常优先尝试开源模型。 all-MiniLM-L6-v2 是一个优秀的起点。如果效果不理想，再考虑调用专用的代码嵌入API或微调开源模型。本项目为演示通用性，将使用 sentence-transformers 的开源模型。

3. 实战构建：从零搭建代码语义搜索引擎

3.1 环境准备与项目初始化

首先，创建一个新的项目目录并安装核心依赖。

mkdir code-semantic-search && cd code-semantic-search
python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate

# 安装核心库
pip install langchain langchain-community sentence-transformers chromadb pydantic
# 可选：如果需要解析特定格式（如.ipynb, .pdf），安装更多加载器
# pip install jupyter pypdf

这里解释一下关键依赖：

• langchain ： 核心框架。
• langchain-community ： 包含社区维护的第三方集成，如一些文档加载器。
• sentence-transformers ： 提供开源的嵌入模型。
• chromadb ： 向量数据库。
• pydantic ： LangChain中用于数据验证。

接下来，我们规划一下项目结构。一个清晰的结构有助于后续维护和扩展。

code-semantic-search/
├── src/
│   ├── __init__.py
│   ├── document_loader.py    # 代码加载与分割逻辑
│   ├── vector_store.py       # 向量库构建与持久化
│   └── query_engine.py       # 查询与问答逻辑
├── data/
│   └── source_code/          # 存放待索引的源代码
├── chroma_db/                # ChromaDB持久化数据目录（自动生成）
├── requirements.txt
└── main.py                   # 主程序入口

3.2 代码加载与智能文本分割

这是构建知识库的第一步，目标是将源代码文件转化为一段段适合向量化的“文档”。

1. 实现文档加载器 ( src/document_loader.py ) 我们首先需要读取源代码文件。LangChain提供了多种 DocumentLoader ，对于纯文本代码文件，使用 TextLoader 即可。我们需要递归遍历目标目录，加载所有指定后缀的文件。

# src/document_loader.py
import os
from pathlib import Path
from typing import List
from langchain_community.document_loaders import TextLoader
from langchain.schema import Document
from langchain.text_splitter import RecursiveCharacterTextSplitter

def load_code_files(source_dir: str, suffixes: List[str] = ['.py', '.js', '.java', '.go', '.rs']) -> List[Document]:
    """
    递归加载指定目录下所有特定后缀的源代码文件。
    
    参数:
        source_dir: 源代码根目录路径。
        suffixes: 需要处理的文件后缀名列表。
    
    返回:
        包含所有文件内容的Document对象列表。
    """
    docs = []
    source_path = Path(source_dir)
    
    # 递归遍历目录
    for suffix in suffixes:
        for file_path in source_path.rglob(f'*{suffix}'):
            if file_path.is_file():
                try:
                    # 使用TextLoader加载文件，指定编码
                    loader = TextLoader(str(file_path), encoding='utf-8')
                    loaded_docs = loader.load()
                    # 为每个文档添加源文件路径作为元数据，便于后续定位
                    for doc in loaded_docs:
                        doc.metadata['source'] = str(file_path.relative_to(source_path))
                    docs.extend(loaded_docs)
                    print(f"已加载: {file_path.relative_to(source_path)}")
                except Exception as e:
                    print(f"加载文件 {file_path} 时出错: {e}")
    return docs

2. 实现代码分割器 代码文件可能很长，直接对整个文件进行向量化会丢失细节，且检索精度低。我们需要将其分割成更小的片段（块）。但简单按字符数分割会切断函数、类等逻辑单元。 RecursiveCharacterTextSplitter 可以优先按换行符、分号等代码中常见的分隔符进行分割，尽量保持逻辑块的完整性。

# 续上 document_loader.py
def split_documents(documents: List[Document]) -> List[Document]:
    """
    使用递归字符分割器将文档分割成更小的块。
    
    参数:
        documents: 原始的Document列表。
    
    返回:
        分割后的Document列表。
    """
    # 初始化分割器
    text_splitter = RecursiveCharacterTextSplitter(
        chunk_size=1000,      # 每个块的最大字符数
        chunk_overlap=200,    # 块之间的重叠字符数，保持上下文连贯
        separators=["\n\n", "\n", ";", "}", "{", " ", ""] # 代码优先分割符
    )
    
    split_docs = text_splitter.split_documents(documents)
    print(f"原始文档数: {len(documents)}， 分割后块数: {len(split_docs)}")
    return split_docs

实操心得： chunk_size 和 chunk_overlap 是关键参数。 对于代码， chunk_size=1000 是一个不错的起点，它能容纳一个中等长度函数或几个短函数。 chunk_overlap=200 能确保函数边界处的信息不会完全丢失。对于注释较多的代码，可以适当增大 chunk_size 。最佳参数需要根据你的代码风格进行微调。

3.3 构建与持久化向量数据库

加载并分割好文档后，下一步就是将其向量化并存入ChromaDB。

实现向量库模块 ( src/vector_store.py ) 这个模块负责初始化嵌入模型、创建向量库、添加文档以及持久化到磁盘。

# src/vector_store.py
import os
from langchain.schema import Document
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Chroma
from typing import List

class CodeVectorStore:
    def __init__(self, persist_directory: str = "./chroma_db"):
        """
        初始化向量存储。
        
        参数:
            persist_directory: ChromaDB数据持久化的目录。
        """
        self.persist_directory = persist_directory
        # 初始化开源嵌入模型
        self.embeddings = HuggingFaceEmbeddings(
            model_name="all-MiniLM-L6-v2", # 使用轻量级Sentence Transformer模型
            model_kwargs={'device': 'cpu'}, # 指定设备，'cuda' for GPU
            encode_kwargs={'normalize_embeddings': True} # 归一化向量，便于余弦相似度计算
        )
        self.vector_store = None

    def create_from_documents(self, documents: List[Document]):
        """
        从文档列表创建向量存储并持久化。
        
        参数:
            documents: 分割后的Document列表。
        """
        print("正在创建向量存储...")
        # 使用Chroma.from_documents，它会自动调用嵌入模型将文档向量化并存储
        self.vector_store = Chroma.from_documents(
            documents=documents,
            embedding=self.embeddings,
            persist_directory=self.persist_directory
        )
        # 显式持久化到磁盘
        self.vector_store.persist()
        print(f"向量存储已创建并保存至 {self.persist_directory}")

    def load_existing(self):
        """加载已存在的持久化向量存储。"""
        if os.path.exists(self.persist_directory):
            print("正在加载已有向量存储...")
            self.vector_store = Chroma(
                persist_directory=self.persist_directory,
                embedding_function=self.embeddings
            )
            return True
        else:
            print("未找到已存在的向量存储目录。")
            return False

    def get_retriever(self, search_kwargs: dict = {"k": 5}):
        """
        获取检索器，用于执行相似性搜索。
        
        参数:
            search_kwargs: 搜索参数，例如返回的最相似结果数量(k)。
        
        返回:
            一个检索器对象。
        """
        if self.vector_store is None:
            raise ValueError("向量存储未初始化，请先创建或加载。")
        # as_retriever将向量库转换为检索器接口
        return self.vector_store.as_retriever(search_kwargs=search_kwargs)

关键点解析：

1. 嵌入模型初始化 ： HuggingFaceEmbeddings 封装了Sentence-Transformers模型。 normalize_embeddings=True 至关重要，它确保所有向量被归一化为单位长度，此时余弦相似度等价于点积，计算更高效。
2. 持久化 ： Chroma.from_documents 在内存中创建索引后，调用 persist() 方法会将其写入 persist_directory 。下次启动时，通过 Chroma(persist_directory=..., embedding_function=...) 即可加载，无需重新向量化，极大节省时间。
3. 检索器（Retriever） ： as_retriever() 方法返回一个标准接口，它封装了相似性搜索的逻辑。 search_kwargs={"k": 5} 表示每次检索返回最相似的5个代码块。

3.4 实现自然语言查询与问答链

向量库准备好后，我们就可以接受自然语言查询了。这里我们实现两种模式：1) 简单检索模式：返回最相关的代码片段及其出处；2) 问答模式：利用LLM对检索到的代码进行总结和解释。

实现查询引擎 ( src/query_engine.py )

# src/query_engine.py
from langchain.chains import RetrievalQA
from langchain_community.llms import Ollama  # 示例使用本地Ollama，可替换为其他LLM
from langchain.prompts import PromptTemplate
from typing import List, Dict, Any

class CodeQueryEngine:
    def __init__(self, retriever):
        """
        初始化查询引擎。
        
        参数:
            retriever: 向量库检索器。
        """
        self.retriever = retriever
        # 初始化一个本地LLM，这里以Ollama运行的Llama2为例
        # 你需要确保已安装Ollama并拉取了相应模型，例如：ollama pull llama2
        self.llm = Ollama(model="llama2", temperature=0.1) # temperature调低，使回答更确定
        # 也可以使用OpenAI API，替换为：from langchain_openai import ChatOpenAI
        # self.llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)

    def simple_search(self, query: str) -> List[Dict[str, Any]]:
        """
        执行简单语义搜索，返回相关代码片段。
        
        参数:
            query: 自然语言查询语句。
        
        返回:
            包含相关文档内容和元数据的字典列表。
        """
        relevant_docs = self.retriever.get_relevant_documents(query)
        results = []
        for doc in relevant_docs:
            results.append({
                "content": doc.page_content[:500] + "...",  # 预览部分内容
                "source": doc.metadata.get("source", "unknown"),
                # 可以添加相似度分数：doc.metadata.get('_score', 'N/A')
            })
        return results

    def answer_with_llm(self, query: str) -> Dict[str, Any]:
        """
        利用LLM进行检索增强生成（RAG），给出直接答案。
        
        参数:
            query: 自然语言问题。
        
        返回:
            包含答案和参考来源的字典。
        """
        # 自定义提示模板，引导LLM基于代码上下文回答
        prompt_template = """请基于以下代码上下文来回答问题。如果你不知道答案，请直接说不知道，不要编造信息。

        上下文：
        {context}

        问题：{question}
        请给出清晰、准确的答案，并指出答案主要基于哪个文件。"""
        
        PROMPT = PromptTemplate(
            template=prompt_template, input_variables=["context", "question"]
        )
        
        # 创建RetrievalQA链
        qa_chain = RetrievalQA.from_chain_type(
            llm=self.llm,
            chain_type="stuff",  # “stuff”将检索到的所有文档内容塞入上下文，适合中等长度
            retriever=self.retriever,
            chain_type_kwargs={"prompt": PROMPT},
            return_source_documents=True  # 返回参考的源文档
        )
        
        result = qa_chain({"query": query})
        return {
            "answer": result["result"],
            "sources": [doc.metadata.get("source", "unknown") for doc in result["source_documents"]]
        }

模式选择建议：

• 简单检索模式 ( simple_search ) ：速度快，直接返回原始代码片段。适合开发者想要自行阅读和分析代码上下文的场景。结果更“原始”，没有幻觉风险。
• 问答模式 ( answer_with_llm ) ：体验更友好，LLM会总结和解释。适合快速获取概述或理解复杂逻辑。但依赖于LLM的能力，可能存在解释不准确或“幻觉”的风险。 务必要求LLM指出参考来源 ，以便人工核对。

3.5 主程序串联与运行

最后，我们创建一个主程序 ( main.py ) 来串联所有步骤，并提供交互式命令行界面。

# main.py
import sys
from pathlib import Path
sys.path.append(str(Path(__file__).parent))

from src.document_loader import load_code_files, split_documents
from src.vector_store import CodeVectorStore
from src.query_engine import CodeQueryEngine

def main():
    data_dir = "./data/source_code"  # 你的源代码存放目录
    persist_dir = "./chroma_db"
    
    # 1. 初始化向量存储
    vector_store = CodeVectorStore(persist_directory=persist_dir)
    
    # 2. 检查是否已有持久化的向量库
    if not vector_store.load_existing():
        print("未找到现有索引，开始构建新的代码向量库...")
        # 2.1 加载源代码文档
        raw_docs = load_code_files(data_dir, suffixes=['.py', '.js', '.ts', '.java', '.go'])
        if not raw_docs:
            print(f"在 {data_dir} 中未找到指定后缀的源代码文件。")
            return
        # 2.2 分割文档
        split_docs = split_documents(raw_docs)
        # 2.3 创建并持久化向量存储
        vector_store.create_from_documents(split_docs)
    
    # 3. 获取检索器
    retriever = vector_store.get_retriever(search_kwargs={"k": 4})
    
    # 4. 初始化查询引擎
    query_engine = CodeQueryEngine(retriever)
    
    # 5. 交互式查询循环
    print("\n===== 代码语义搜索引擎已就绪 =====")
    print("输入你的问题（例如：'用户登录的函数在哪里？'），输入 'quit' 或 'exit' 退出。")
    while True:
        try:
            user_query = input("\n> 问: ").strip()
            if user_query.lower() in ['quit', 'exit', 'q']:
                print("再见！")
                break
            if not user_query:
                continue
                
            print("\n--- 模式选择 ---")
            print("1. 简单检索（返回相关代码片段）")
            print("2. 智能问答（由LLM解释答案）")
            mode = input("请选择模式 (1 或 2， 默认 1): ").strip()
            
            if mode == '2':
                print("\n[智能问答模式] 思考中...")
                answer_result = query_engine.answer_with_llm(user_query)
                print(f"\n答: {answer_result['answer']}")
                if answer_result['sources']:
                    print(f"参考来源: {', '.join(answer_result['sources'])}")
            else:
                print("\n[简单检索模式] 搜索中...")
                search_results = query_engine.simple_search(user_query)
                if search_results:
                    for i, res in enumerate(search_results, 1):
                        print(f"\n[{i}] 文件: {res['source']}")
                        print(f"代码预览:\n{res['content']}")
                        print("-" * 40)
                else:
                    print("未找到高度相关的代码片段。")
                    
        except KeyboardInterrupt:
            print("\n\n程序被中断。")
            break
        except Exception as e:
            print(f"查询过程中发生错误: {e}")

if __name__ == "__main__":
    main()

4. 部署优化与高级技巧

4.1 性能优化与大规模代码库处理

当代码库达到GB级别或文件数超过十万时，基础方案可能遇到性能和内存挑战。

1. 增量索引与更新 ：ChromaDB支持增量添加文档。你可以定期（如每天）扫描代码库变更，只对新文件或修改过的文件进行加载、分割、向量化，然后调用 vector_store.add_documents(split_new_docs) 添加到已有集合中。关键是要维护一个记录文件哈希值或最后修改时间的清单，用于比对变化。
2. 批处理与异步 ：在构建初始索引时，使用批处理来嵌入文本可以显著提升速度。 HuggingFaceEmbeddings 本身支持批量编码。你可以修改 vector_store.py ，在 from_documents 之前，先将文档内容批量转换为向量，但LangChain的Chroma集成内部已做优化。对于超大规模数据，考虑使用异步IO来并行加载文件。
3. 元数据过滤 ：ChromaDB支持基于元数据的过滤检索。在加载文档时，可以添加丰富的元数据，如 file_type （.py）、 module （user.auth）、 last_modified 等。查询时，可以指定过滤器，例如“只在 .py 文件中搜索关于‘缓存’的代码”，这能大幅提升检索精度和速度。

   # 添加元数据示例
   doc.metadata.update({"file_type": suffix, "module": str(file_path.parent)})
   
   # 带过滤器的检索
   retriever = vector_store.as_retriever(
       search_kwargs={"k": 5, "filter": {"file_type": ".py"}}
   )
   

4. 分集合（Collection）存储 ：对于超大型、模块清晰的代码库，可以按项目、模块或服务创建不同的ChromaDB集合（Collection）。查询时，可以并行搜索多个集合或根据问题路由到特定集合。

4.2 提升搜索准确性的策略

1. 代码清洗与增强 ：在向量化之前，可以对代码文本进行预处理。
   • 保留关键结构 ：不要过度清洗。函数名、类名、变量名、关键API调用包含丰富的语义。
   • 添加注释和文档字符串 ：这些是理解代码意图的宝贵信息，务必保留。
   • 结构化信息 ：可以尝试用AST（抽象语法树）解析器提取函数/类签名、调用关系，并将这些信息作为附加文本与原始代码一起嵌入，能极大提升对“查找调用某函数的代码”这类查询的准确性。
2. 混合搜索（Hybrid Search） ：结合语义搜索和传统关键词搜索（如BM25）。可以先进行关键词搜索快速筛选出候选文档，再对候选文档进行语义相似度重排序。LangChain社区有 ChromaDB 与 BM25 结合的方案，或使用支持混合搜索的向量数据库（如Weaviate, Qdrant）。
3. 重排序（Re-ranking） ：语义搜索返回的Top-K个结果，可以使用一个更精细但较慢的“重排序模型”进行二次评分，重新排列结果顺序，将最相关的结果提到最前面。这常用于追求极致精度的场景。
4. 查询扩展（Query Expansion） ：在将用户查询转换为向量前，先用LLM对查询进行改写或扩展。例如，将“怎么存用户数据？”扩展为“如何存储用户数据到数据库？插入用户记录的代码在哪里？Save user function”。这能帮助匹配更多相关表述。

4.3 集成到开发工作流

让工具用起来，才能产生价值。

1. 命令行工具（CLI） ：将 main.py 封装成命令行工具，如 code-search --query “支付接口” ，方便在终端快速使用。
2. IDE插件 ：开发VSCode或JetBrains IDE的插件，在编辑器中直接唤起搜索框，查询结果可以直接跳转到对应文件行号。这需要将后端封装为HTTP服务，插件通过API调用。
3. CI/CD集成 ：在代码审查（Code Review）环节集成。当发起Pull Request时，自动对变更的代码文件生成摘要，或允许审查者针对PR内容进行语义查询（“这次PR改了哪些与日志相关的代码？”）。
4. 团队知识库门户 ：构建一个简单的Web界面，供整个团队使用。可以加入用户认证、搜索历史、结果收藏等功能。使用 FastAPI 或 Streamlit 可以快速搭建原型。

5. 常见问题与故障排除

在实际搭建和运行过程中，你可能会遇到以下问题：

问题现象	可能原因	解决方案
加载文件时编码错误	源代码文件包含非UTF-8编码（如GBK）。	在 TextLoader 中尝试指定正确的编码，或使用 chardet 库检测编码后加载。对于二进制文件，应跳过。
分割后代码块支离破碎	chunk_size 太小或 separators 设置不当。	增大 chunk_size （如1500）。调整 separators 顺序，将代码特有的分隔符（如 \n\n , ; , } ）放在前面。
语义搜索效果差，返回不相关结果	1. 嵌入模型不适合代码。 2. chunk_size 过大，单个块包含过多无关信息。 3. 查询语句太模糊。	1. 更换为代码专用的嵌入模型（如 microsoft/codebert-base ）。 2. 减小 chunk_size ，或尝试按函数/类分割（需AST解析）。 3. 引导用户提出更具体的问题，或在查询端进行查询扩展。
检索速度慢	1. 向量库数据量大。 2. ChromaDB索引未优化。	1. 确保使用了持久化，避免每次启动重建。 2. 检索时使用元数据过滤缩小范围。 3. 考虑升级硬件或使用支持GPU加速的嵌入模型。
LLM回答“不知道”或胡言乱语	1. 检索到的上下文不相关。 2. LLM自身能力或提示词问题。 3. 上下文长度超限。	1. 先检查 simple_search 的结果是否相关，优化检索环节。 2. 优化提示词（Prompt），明确指令“基于上下文回答”。 3. 对于长上下文，使用 chain_type="map_reduce" 或 "refine" ，而非 "stuff" 。
内存占用过高	1. 一次性加载所有文件到内存。 2. 嵌入模型加载占用大。	1. 实现流式或分批加载处理文件。 2. 使用更轻量的嵌入模型。对于超大库，考虑使用外存向量数据库。

一个典型的调试流程 ：当查询结果不理想时，首先运行 simple_search 模式，查看系统到底检索到了哪些原始代码片段。如果这些片段本身就不相关，那么问题出在 检索阶段 （嵌入模型、分割策略、向量库）。如果检索到的片段是相关的，但LLM给出的答案不好，那么问题出在 生成阶段 （提示词、LLM能力、上下文整合方式）。