核心用法
RAG Construction 是一个面向建筑行业的检索增强生成（RAG）系统实现，基于 Data-Driven Construction（DDC）方法论第2.3章。该系统提供完整的文档处理流水线：从建筑文档（规范、图纸、合同、RFI等）的加载，到多种策略的文本分块（固定大小、段落、章节、语义、句子），再到向量存储与相似度搜索，最终生成带引用来源的AI回答。
核心使用流程为：初始化 ConstructionRAG 实例，配置分块策略和大小；使用 add_document()() 或 add_documents()() 批量导入建筑文档；通过 search()() 进行语义检索，或调用 query()() 获取完整的RAG问答响应。系统内置 TextChunker 处理文档分块，，VectorStore 管理向量存储，，EmbeddingModel 生成文本嵌入（当前为基于哈希的模拟实现）。
显著优点
1. 零依赖设计：仅使用 Python 标准库（dataclasses、enum、typing、datetime、json、hashlib、re），完全避免第三方包带来的供应链安全风险。
2. 模块化架构：组件职责清晰（分块器、向量存储、嵌入模型、RAG主类），便于理解、测试和替换实现。
3. 灵活的分块策略：支持5种分块方式，特别针对建筑文档特点优化了章节分块（识别 SECTION/ARTICLE/PART 等标题模式）。
4. 完整的类型注解：全代码覆盖类型提示，配合 dataclass 定义，提升代码可读性和IDE支持。
5. 教育价值高：代码透明、逻辑简洁，是理解RAG系统工作原理的优质学习材料，配套有正式出版的技术书籍参考。
潜在缺点与局限性
1. 模拟实现限制：EmbeddingModel 使用 SHA256 哈希生成确定性伪嵌入，非真实语义向量，生产环境必须替换为 OpenAI、Sentence-Transformers 等实际模型。
2. 内存存储局限：VectorStore 为纯内存实现，无持久化能力，大规模知识库场景下内存消耗显著，且服务重启数据丢失。
3. 相似度计算效率：采用朴素的遍历计算余弦相似度，时间复杂度 O(N)，文档量增大后检索性能急剧下降，缺乏近似最近邻（ANN）索引优化。
4. 回答生成简化：_generate_answer()() 仅为模拟实现，直接拼接文本片段，未接入真实LLM，无法处理复杂推理和多步问答。
5. 缺乏高级功能：无重排序（reranking）、无查询扩展、无多路召回（向量+关键词混合搜索）、无访问控制等生产级特性。
适合的目标群体
- 建筑行业技术人员：希望理解如何将RAG技术应用于工程文档管理的工程师、项目经理
- AI/ML学习者：需要简洁、无依赖的RAG代码示例来理解核心机制的学习者
- 原型开发者：快速验证建筑知识库问答产品概念，后续再逐步替换为生产组件
- 教育机构：配合《Data-Driven Construction》书籍进行案例教学的师生
使用风险
1. 性能瓶颈风险：内存向量存储和线性扫描在大规模数据（>10万文档块）下响应延迟显著，需评估数据规模或提前规划迁移至 FAISS、Milvus 等专业向量数据库。
2. 嵌入质量风险：模拟嵌入无语义表达能力，若误用于生产将产生完全错误的检索结果，务必替换为经训练的嵌入模型。
3. 数据持久化风险：无自动保存机制，进程崩溃或重启导致知识库重建，需自行实现 export_knowledge_base()() 的定期调用和恢复逻辑。
4. 扩展性风险：当前架构为单线程同步设计，高并发场景下需引入异步处理或队列机制。
5. 幻觉传导风险：即使替换为真实LLM，RAG系统的回答质量仍受限于检索片段的相关性和完整性，建筑规范类严肃场景需人工复核关键决策信息。