LLMWare 架构解析Knowledge Ingestion 与 Model Prompting 双管线组件体系【免费下载链接】llmwareUnified framework for building enterprise RAG pipelines with small, specialized models项目地址: https://gitcode.com/GitHub_Trending/ll/llmwareLLMWare 是一个面向企业级 RAG 流水线构建的统一框架其架构由两条逻辑集成的数据管线构成**Knowledge Ingestion知识摄入**与Model Prompting模型提示。本文以官方组件文档docs/components/components.md为骨架结合llmware/目录下的真实源码逐层拆解这两条管线的核心类、关键方法签名、可配置的解析/嵌入/查询参数以及支撑管线运转的 resources、configs、model_configs、web_services 等底层模块帮助读者在无需阅读全部 4.7 万行源码的前提下建立起可直接落地复用的 LLMWare 心智模型。一、总体架构以“可替换端点组件”为目标的抽象层设计LLMWare 的设计出发点在官方文档中被明确陈述围绕构建基于 LLM 的工作流组织一组逻辑集成的数据管线每条管线提供高层接口其目的是在单个端点组件之上提供抽象层从而促进代码复用并允许以极少甚至零代码改动来交换不同的底层组件——例如更换解析后端、更换向量数据库、更换推理模型上层管线代码基本不变。从源码结构看这一设计落地的方式非常一致管线一知识摄入的公共入口是Library与Query两个高层类管线二模型提示的公共入口是ModelCatalog、Prompt与LLMfx底层端点组件各向量数据库适配器、各模型驱动类、各数据库读写器被注册在模块级的注册表中由高层类按名称动态装配。文档给出的大多数情况下只需用 Library 和 Query 就能完成目标这句话正是这套抽象层带来的直接收益解析、文本分块、索引等细节被封装在Library内部检索细节被封装在Query内部。二、管线一Knowledge Ingestioncreating Gen Ai Food官方文档将知识摄入管线拆为七个主要步骤这也是理解整条管线数据流的正确顺序提取与解析Extracting and Parsing文本分块Text Chunking索引、组织与存储Indexing, Organizing and Storing嵌入Embedding检索Retrieval内容的分析与复用Analytics and Reuse of Content与 SQL 表及其他结构化内容结合Combining with SQL Table and Other Structured Content2.1 核心类Library、Query、Parser、EmbeddingHandler、CustomTables文档列出的核心类为Library、Queryretrieval 模块、Parser、EmbeddingHandlerembeddings 模块、Graph、CustomTablesresources 模块与Datasetsdataset_tools 模块。在当前仓库源码中可以逐一确认的有类所在文件角色Libraryllmware/library.py第 38 行知识库的顶层组织单位创建/加载库、摄入文件、安装嵌入、导出LibraryCatalogllmware/library.py第 1286 行管理 Library Card库元信息独立于 Library 本体Queryllmware/retrieval.py第 43 行检索门面文本/语义查询、过滤、查询历史Parserllmware/parsers.py第 60 行解析门面按文件类型路由到 PDF/Office/文本/语音/对话/OCR 解析通道EmbeddingHandlerllmware/embeddings.py第 78 行嵌入门面跨向量数据库的统一 create/search/delete 接口CollectionRetrieval/CollectionWriter等llmware/resources.py文档所述抽象层底层数据库仓库之上的读写与状态管理需要如实说明的是当前仓库源码中未发现名为Graph或Datasets的类定义dataset_tools模块亦不存在于本仓库。文档将其列为核心类但从源码结构看二者应属于文档口径中的规划组件或独立分发组件本文不对其做实现层面的展开。2.2 摄入入口Library().add_files()及其可配置参数文档给出的摄入一切方法Library().add_files(input_folder_pathpath/to/docs)llmware/library.py 中add_files的完整签名揭示了这一一步到位背后可调节的全部参数def add_files(self, input_folder_pathNone, encodingutf-8, chunk_size400, get_imagesTrue, get_tablesTrue, smart_chunking1, max_chunk_size600, table_gridTrue, get_header_textTrue, table_strategy1, strip_headerFalse, verbose_level2, copy_files_to_libraryTrue, set_custom_logging-1, use_logging_fileFalse)这些参数覆盖了文档所列前两个步骤解析 文本分块的大部分决策点chunk_size400/max_chunk_size600分块的目标长度与硬上限字符对应 llmware/util.py 中TextChunker的分块与边缘平滑逻辑get_imagesTrue/get_tablesTrue解析时是否抽取内嵌图像与表格抽取出的图像保存至库目录的images子文件夹可在库中用Query.image_query检索table_gridTrue/table_strategy1表格以网格文本形式输出table_strategy控制表格解析策略get_header_textTrue/strip_headerFalse保留文档页眉文本或将其剥离copy_files_to_libraryTrue原始文件复制到库的 file_copy 目录用于后续的重复检测verbose_level2/set_custom_logging日志粒度控制配合 llmware/configs.py 中LLMWareConfig.set_logging_level使用。从源码结构看add_files内部委托给Parser.ingest而Parser的分发逻辑在 llmware/parsers.py 的_collator方法第 285 行起按扩展名将输入文件复制进六个独立的工作目录——office、pdf、text、ocr、voice、zip 通道每个通道对应一个专职解析方法parse_pdf、parse_office、parse_text、parse_voice、parse_dialog、parse_pdf_by_ocr_images等ingest第 382 行在dupe_checkTrue时通过与库内已有文件对比跳过重复文件。这也解释了为什么支持的文件类型是 Parser 的能力边界而非 Library 的边界。2.3 支持的文档文件类型官方文档列出的支持类型pdf, pptx, docx, xlsx, txt, csv, html, jsonl, json, tsv, jpg, jpeg, png, wav, zip, md, mp3, mp4, m4a。快速验证入口见 solutions/rag/example-1-create_first_library.pyfrom llmware.library import Library library Library().create_new_library(my_library) parsing_output library.add_files(ingestion_folder_path) updated_library_card library.get_library_card() print(updated_library_card[documents], updated_library_card[blocks])运行后get_library_card()返回的 library card 中的documents/blocks计数就是步骤 1-3解析、分块、入库完成度的量化指标。库目录结构中还会包含images子目录存放抽取出的图像。2.4 嵌入install_new_embedding()与向量数据库可替换性文档给出的嵌入方法Library().install_new_embedding(embedding_model_nameyour embedding model, vector_dbyour vector db)llmware/library.py 中的完整签名为def install_new_embedding(self, embedding_model_nameNone, vector_dbNone, from_hfFalse, from_sentence_transformerFalse, modelNone, tokenizerNone, model_api_keyNone, vector_db_api_keyNone, batch_size500, max_lenNone, use_gpuTrue)其组件可交换的实现依据在 llmware/embeddings.pyEmbeddingHandler之下并排定义了十余个向量数据库适配器类每一个都实现同一套三接口——create_new_embedding(doc_ids, batch_size)、search_index(query_vector, sample_count)、delete_index()。适配器的实例化注册由 llmware/configs.py 第 474 行的VectorDBRegistry完成其文档字符串明确写着 Registry of supported Vector DBs, and the class module used to interface with the DB并支持通过LLMWareConfig.add_vector_db(db_name, vector_db_class, modulellmware.embeddings)追加自定义数据库。因此文档中~15 个独立嵌入示例、~10 种向量数据库的说法与源码中的适配器数量一致而具体可用列表应以LLMWareConfig.get_vector_db_list()的运行时返回为准。索引命名同样被源码约束generate_index_name(account_name, library_name, model_name, max_component_length19)将账户、库、模型名各截断至 19 个字符拼接为索引名这解释了不同向量数据库对名称长度限制下的兼容性取舍。2.5 检索Query的完整查询能力面文档给出的查询方法Query(library).query(query, query_typesemantic, result_count20)llmware/retrieval.py 中Query.__init__的签名值得注意——它同时接受embedding_model、embedding_model_name、vector_db、query_mode等参数意味着检索时可以直接指定用哪套嵌入 哪个向量库与建库时的安装口径一致def __init__(self, library, embedding_modelNone, tokenizerNone, vector_db_api_keyNone, query_idNone, from_hfFalse, from_sentence_transformerFalse, embedding_model_nameNone, save_historyTrue, query_modeNone, vector_dbNone, model_api_keyNone)统一入口query(query, query_typetext, result_count20, results_onlyTrue)之外Query暴露的方法面覆盖了文档~10 个检索示例所声称的全部技术文本系text_query支持exact_mode精确匹配、text_query_with_document_filter、text_query_with_custom_filter、text_query_by_content_type、text_search_by_page、text_query_by_author_or_speaker作者/演讲者检索语义系semantic_query支持embedding_distance_threshold距离阈值、semantic_query_with_document_filter、similar_blocks_embedding相似块召回混合与进阶dual_pass_query双通道混合查询primarytext或semantic含safety_check兜底、augment_qr、apply_semantic_ranking语义重排序、block_similarity_retrieval_more_like_this过滤与导出document_filter、filter_by_key_value_range、filter_by_time_stamp、bibliography_builder_from_qr从查询结果生成参考文献、export_all_tables/export_one_table_to_csv、aggregate_text查询历史save_query_state/load_query_state/clear_query_state/dump_current_query_state底层由 llmware/resources.py 第 4911 行的QueryState持久化对应文档查询历史/Query State能力。一个最小的语义查询示例与 solutions/sources/semantic_retrieval.py 等示例同构from llmware.retrieval import Query query_obj Query(library, embedding_model_nameall-MiniLM-L6-v2, vector_dbmilvus_lite) results query_obj.semantic_query(contract termination clause, result_count20, embedding_distance_threshold250)向量库与嵌入模型需先通过install_new_embedding安装到该 Library 才能用于检索。三、管线二Model PromptingFun with LLMs官方文档将模型提示管线定义为发现、实例化并配置一个基于 LLM 的模型以执行推理的完整生命周期包含八个环节ModelCatalog发现/加载/管理配置、Inference、Function Calls、Prompts、Prompt with Sources、Fact Checking、Agent-based 多步流程、Prompt History。对应核心类为ModelCatalogmodels 模块、Prompt、LLMfxagents 模块。3.1 ModelCatalog统一发现与加载模型文档给出的关键方法ModelCatalog().list_all_models() # 发现模型 model ModelCatalog().load_model(model_name) # 加载模型 response model.inference(prompt, add_contextcontext) # 推理llmware/models.py第 512 行起全文约 1.6 万行中的ModelCatalog类印证了这三个入口并提供远比文档更多的能力发现list_all_models、list_open_source_models、list_embedding_models、list_generative_models、list_generative_local_models、list_models_by_type(model_family)、list_function_call_models、model_lookup注册register_hf_generative_model、register_sentence_transformer_model、register_gguf_model、register_open_chat_model、register_ollama_model、setup_custom_llmware_inference_server以及register_new_model_card/add_model_cards_from_file自定义 manifest 批量导入加载load_model(selected_model, api_keyNone, use_gpuTrue, sampleTrue, get_logitsFalse, max_output100, temperature-99, force_reloadFalse, api_endpointNone, **kwargs)参数中的temperature-99为哨兵值表示沿用模型卡上的默认温度注册表持久化save_model_registry/load_model_registry默认文件名llmware_model_catalog.json以及 prompt wrapper 与 tokenizer 配置的独立存取。从源码结构看模型注册表的默认内容来自 llmware/model_configs.py约 4600 行中的三个全局常量与文档逐一对应global_model_repo_catalog_list第 25 行模型目录主列表global_model_finetuning_prompt_wrappers_lookup第 3936 行微调模型的提示词包装器查找表global_default_prompt_catalog第 4102 行默认提示词目录。文档称models 模块中暴露了约 17 个独立模型类。从源码结构看models.py中确实并排定义了十余个模型驱动类覆盖 Hugging Face 生成/嵌入/重排模型、GGUF 本地模型、GGUF 视觉模型、ONNX 生成/分类/重排、OpenVINO 生成/视觉、OpenAI/Anthropic/Gemini/Google、OpenChat、Ollama、Foundry 本地服务等每个类统一实现inference、stream、function_call、token_counter等方法族。文档的核心建议是大多数场景通过 ModelCatalog 这一高层接口工作以获得代码复用与模型可替换性而在很多管线中连 ModelCatalog 都不需要直接调用因为Prompt知识检索工作流和LLMfxAgent 与函数调用本身就构建在 ModelCatalog 之上。3.2 Prompt 类Prompt with Sources 与 Prompt History文档描述Prompt对模型类做了一层包装提供便捷的来源/检索管理能力。llmware/prompts.py第 44 行的Prompt类完整落实了这一点其__init__即可同时绑定llm_name、library、prompt_idPrompt(llm_nameyour model, librarylibrary, prompt_idsession-1)来源管理方法族对应Prompt with Sources环节add_source_new_query(library, query, query_typesemantic, result_count10)——直接把一次检索结果挂为来源add_source_query_results、add_source_library、add_source_wikipedia、add_source_website、add_source_yahoo_finance、add_source_document、add_source_last_interaction_stepreview_sources_summary/verify_source_materials_attached来源审查。推理与事实核查方法族对应 Fact Checking methods 环节prompt_with_source、prompt_main、prompt_from_catalog、number_or_none、yes_or_no、multiple_choice、xsummary、summarize_document、evidence_check_numbers、evidence_check_sources、evidence_comparison_stats、classify_not_found_response以及 llmware/prompts.py 中的FactChecker辅助类fact_checker_numbers、source_reviewer、token_comparison。Prompt History 环节由两组机制支撑Prompt内部的register_llm_inference/get_current_history/clear_history每次推理的交互记录以及 llmware/resources.py 中PromptState的持久化initiate_new_state_session、register_interaction、full_history、save_custom_state、generate_interaction_report支持按prompt_id恢复、跨会话追溯交互历史。3.3 LLMfx面向函数调用 SLIM 模型的 Agent 引擎文档描述LLMfx对模型类做包装服务于function-calling SLIM 模型的 Agent 流程。llmware/agents.py第 43 行的LLMfx类证实了这一分工其能力面包括工具加载load_tool、load_tool_list、unload_tool——把多个小型 SLIM 函数调用模型同时装进一个 Agent 工具箱函数调用执行exec_function_call、exec_multitool_function_call多工具并行调用高频分析原语的语法糖sentiment、topics、ner/named_entity_extraction、ratings、emotions、intent、tags、category、extract、xsum/summarize、boolean、nli、q_gen、qa_gen、verify_llm_response结构化数据操作sql(query, table_schema)Text-to-SQL、sql_checker、query_custom_table、query_db工作队列与报告load_work、show_report、activity_summary、write_to_journal支撑多步 Agent 的迭代追踪。Agent 多步流程的完整示例可参考 solutions/slim_agents/ 目录如 agents-1-start_here.py、text2sql-end-to-end-2.py与 solutions/rag/example-8-agents.py。四、支撑模块两条管线之下的抽象层文档明确列出了支撑两套管线的使能类与方法。逐一对应到当前仓库源码4.1 resources 模块llmware/resources.py文档表述在底层数据库仓库之上提供抽象层并为主要类提供独立的状态机制。源码中的对应组件CollectionRetrieval / CollectionWriter按llmware/mongodb/postgres/qdrant/sqlite等数据库分别实现的读写器每个实现同一方法面lookup、basic_query、filter_by_key、text_search_with_key_value_range、get_whole_collection、update_block、add_new_embedding_flag等这正是更换存储端点而不动上层的抽象层实体PromptState / QueryState / ParserState分别位于第 4911、4911 附近与第 4421 行为 Prompt、Query、Parser 三大类提供独立状态持久化CustomTables / 自定义表加载器load_csv、load_json、validate_csv、validate_json、build_table、insert_rows服务于文档步骤 7与 SQL 表及结构化内容结合以及LLMfx.sql的 Text-to-SQL 场景。4.2 其他支撑模块模块源码文档描述与实现对应configsllmware/configs.pyLLMWareConfig统一管理路径get_library_path/get_model_repo_path等、活动数据库get_active_db/set_active_db、向量库/表库注册VectorDBRegistry、日志级别各存储端点配置类MilvusConfig、MongoConfig、PostgresConfig、QdrantConfig、RedisConfig、PineconeConfig、LanceDBConfig、SQLiteConfig、ChromaDBConfig等均在此定义gguf_configsllmware/gguf_configs.pyGGUFConfigsctypes 声明、采样参数、llama/whisper 日志回调支撑 GGUF 本地推理端点model_configsllmware/model_configs.py三个全局注册表常量见 3.1 节是 ModelCatalog 的默认数据来源utilllmware/util.pyUtilities与一批工具TextChunker分块、exact_search_dicts/token_search_dicts/fast_search_dicts词典级搜索、get_top_bigrams/trigrams内容分析、file_checksum/compare_hash文件完整性、SecureFileName等setupllmware/setup.pySetup类load_sample_files、load_voice_sample_files、load_selected_sample_files快速示例中的样本文件入口exceptions定义于 llmware/configs.py 第 1236 行起LLMWareException基类及DependencyNotInstalledException、ModelNotFoundException、ConfigKeyException、ModuleNotFoundException、GGUFLibNotLoadedExceptionweb_servicesllmware/web_services.pyWikipediaget_article/search_wikipedia、YFinanceget_company_summary/get_financial_summary/get_stock_summary、WebSite网页抓取与图片落盘、LLMWareAPI远程推理服务端点客户端值得强调的是文档提到的Prompt.add_source_wikipedia/add_source_yahoo_finance/add_source_website三个来源方法正是调用 web_services 模块这三个类的证据——两条管线在此交汇摄入管线产出的 Library 与外部结构化服务都被 Prompt 的高层接口统一纳管。五、端到端串联与示例索引文档以End-to-End Use Cases收尾。当前仓库中可直接运行的端到端串联示例快速上手三步solutions/rag/example-1-create_first_library.py解析建库→ example-2-build_embeddings.py建嵌入→ example-3-prompts_and_models.py提示与模型其后是 example-4-rag-text-query.py 至 example-9-function-calls-with-web-services.py 的检索、Agent 与 Web Service 函数调用示例摄入侧深度示例solutions/sources/解析、OCR、表格抽取、过滤、引用生成如 bibliography.py、parse_pdf_by_ocr.py嵌入侧深度示例solutions/embeddings/约 15 个向量数据库/嵌入模型组合示例如 using_milvus_lite.py、using_neo4j.py;模型侧深度示例solutions/models/ 与 solutions/gguf/Ollama、OpenChat、GGUF 本地模型、采样设置调整等Agent 侧深度示例solutions/slim_agents/多模型、多步 SLIM Agent 流程完整业务用例solutions/use_cases/发票处理、MSA 处理、合同分析等。六、小结一张表读懂 LLMWare 组件映射能力环节高层类底层实现文件关键方法解析 分块 入库Library/Parserllmware/parsers.pyadd_files→Parser.ingest→ 各parse_*通道嵌入安装Library/EmbeddingHandlerllmware/embeddings.pyinstall_new_embedding→ 向量库适配器create_new_embedding检索Queryllmware/retrieval.pyquery/text_query/semantic_query/dual_pass_query模型发现与加载ModelCatalogllmware/models.pylist_all_models/load_model/register_*提示与来源管理Promptllmware/prompts.pyadd_source_*/prompt_with_source/ 事实核查方法族Agent 函数调用LLMfxllmware/agents.pyload_tool/exec_function_call/sql/ 分析原语存储与状态抽象CollectionRetrieval/*Statellmware/resources.py统一读写方法面 独立状态持久化配置与端点注册LLMWareConfig/VectorDBRegistryllmware/configs.pyset_active_db/add_vector_db/ 端点配置类外部结构化来源Wikipedia/YFinance/WebSitellmware/web_services.pyget_article/get_company_summary/ 网页抓取这套高层门面 注册表端点的分层是 LLMWare 架构最核心的工程决策业务管线始终面向Library、Query、ModelCatalog、Prompt、LLMfx五个稳定接口编程而解析通道、向量数据库、模型驱动这些高替换频率的组件被隔离在注册表之下的实现层中——这既是文档minimal, if any, code change承诺的源码级依据也是读者评估扩展点自定义向量库、自定义模型卡、自定义表时的落点。【免费下载链接】llmwareUnified framework for building enterprise RAG pipelines with small, specialized models项目地址: https://gitcode.com/GitHub_Trending/ll/llmware创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LLMWare 架构解析：Knowledge Ingestion 与 Model Prompting 双管线组件体系
LLMWare 架构解析Knowledge Ingestion 与 Model Prompting 双管线组件体系【免费下载链接】llmwareUnified framework for building enterprise RAG pipelines with small, specialized models项目地址: https://gitcode.com/GitHub_Trending/ll/llmwareLLMWare 是一个面向企业级 RAG 流水线构建的统一框架其架构由两条逻辑集成的数据管线构成**Knowledge Ingestion知识摄入**与Model Prompting模型提示。本文以官方组件文档docs/components/components.md为骨架结合llmware/目录下的真实源码逐层拆解这两条管线的核心类、关键方法签名、可配置的解析/嵌入/查询参数以及支撑管线运转的 resources、configs、model_configs、web_services 等底层模块帮助读者在无需阅读全部 4.7 万行源码的前提下建立起可直接落地复用的 LLMWare 心智模型。一、总体架构以“可替换端点组件”为目标的抽象层设计LLMWare 的设计出发点在官方文档中被明确陈述围绕构建基于 LLM 的工作流组织一组逻辑集成的数据管线每条管线提供高层接口其目的是在单个端点组件之上提供抽象层从而促进代码复用并允许以极少甚至零代码改动来交换不同的底层组件——例如更换解析后端、更换向量数据库、更换推理模型上层管线代码基本不变。从源码结构看这一设计落地的方式非常一致管线一知识摄入的公共入口是Library与Query两个高层类管线二模型提示的公共入口是ModelCatalog、Prompt与LLMfx底层端点组件各向量数据库适配器、各模型驱动类、各数据库读写器被注册在模块级的注册表中由高层类按名称动态装配。文档给出的大多数情况下只需用 Library 和 Query 就能完成目标这句话正是这套抽象层带来的直接收益解析、文本分块、索引等细节被封装在Library内部检索细节被封装在Query内部。二、管线一Knowledge Ingestioncreating Gen Ai Food官方文档将知识摄入管线拆为七个主要步骤这也是理解整条管线数据流的正确顺序提取与解析Extracting and Parsing文本分块Text Chunking索引、组织与存储Indexing, Organizing and Storing嵌入Embedding检索Retrieval内容的分析与复用Analytics and Reuse of Content与 SQL 表及其他结构化内容结合Combining with SQL Table and Other Structured Content2.1 核心类Library、Query、Parser、EmbeddingHandler、CustomTables文档列出的核心类为Library、Queryretrieval 模块、Parser、EmbeddingHandlerembeddings 模块、Graph、CustomTablesresources 模块与Datasetsdataset_tools 模块。在当前仓库源码中可以逐一确认的有类所在文件角色Libraryllmware/library.py第 38 行知识库的顶层组织单位创建/加载库、摄入文件、安装嵌入、导出LibraryCatalogllmware/library.py第 1286 行管理 Library Card库元信息独立于 Library 本体Queryllmware/retrieval.py第 43 行检索门面文本/语义查询、过滤、查询历史Parserllmware/parsers.py第 60 行解析门面按文件类型路由到 PDF/Office/文本/语音/对话/OCR 解析通道EmbeddingHandlerllmware/embeddings.py第 78 行嵌入门面跨向量数据库的统一 create/search/delete 接口CollectionRetrieval/CollectionWriter等llmware/resources.py文档所述抽象层底层数据库仓库之上的读写与状态管理需要如实说明的是当前仓库源码中未发现名为Graph或Datasets的类定义dataset_tools模块亦不存在于本仓库。文档将其列为核心类但从源码结构看二者应属于文档口径中的规划组件或独立分发组件本文不对其做实现层面的展开。2.2 摄入入口Library().add_files()及其可配置参数文档给出的摄入一切方法Library().add_files(input_folder_pathpath/to/docs)llmware/library.py 中add_files的完整签名揭示了这一一步到位背后可调节的全部参数def add_files(self, input_folder_pathNone, encodingutf-8, chunk_size400, get_imagesTrue, get_tablesTrue, smart_chunking1, max_chunk_size600, table_gridTrue, get_header_textTrue, table_strategy1, strip_headerFalse, verbose_level2, copy_files_to_libraryTrue, set_custom_logging-1, use_logging_fileFalse)这些参数覆盖了文档所列前两个步骤解析 文本分块的大部分决策点chunk_size400/max_chunk_size600分块的目标长度与硬上限字符对应 llmware/util.py 中TextChunker的分块与边缘平滑逻辑get_imagesTrue/get_tablesTrue解析时是否抽取内嵌图像与表格抽取出的图像保存至库目录的images子文件夹可在库中用Query.image_query检索table_gridTrue/table_strategy1表格以网格文本形式输出table_strategy控制表格解析策略get_header_textTrue/strip_headerFalse保留文档页眉文本或将其剥离copy_files_to_libraryTrue原始文件复制到库的 file_copy 目录用于后续的重复检测verbose_level2/set_custom_logging日志粒度控制配合 llmware/configs.py 中LLMWareConfig.set_logging_level使用。从源码结构看add_files内部委托给Parser.ingest而Parser的分发逻辑在 llmware/parsers.py 的_collator方法第 285 行起按扩展名将输入文件复制进六个独立的工作目录——office、pdf、text、ocr、voice、zip 通道每个通道对应一个专职解析方法parse_pdf、parse_office、parse_text、parse_voice、parse_dialog、parse_pdf_by_ocr_images等ingest第 382 行在dupe_checkTrue时通过与库内已有文件对比跳过重复文件。这也解释了为什么支持的文件类型是 Parser 的能力边界而非 Library 的边界。2.3 支持的文档文件类型官方文档列出的支持类型pdf, pptx, docx, xlsx, txt, csv, html, jsonl, json, tsv, jpg, jpeg, png, wav, zip, md, mp3, mp4, m4a。快速验证入口见 solutions/rag/example-1-create_first_library.pyfrom llmware.library import Library library Library().create_new_library(my_library) parsing_output library.add_files(ingestion_folder_path) updated_library_card library.get_library_card() print(updated_library_card[documents], updated_library_card[blocks])运行后get_library_card()返回的 library card 中的documents/blocks计数就是步骤 1-3解析、分块、入库完成度的量化指标。库目录结构中还会包含images子目录存放抽取出的图像。2.4 嵌入install_new_embedding()与向量数据库可替换性文档给出的嵌入方法Library().install_new_embedding(embedding_model_nameyour embedding model, vector_dbyour vector db)llmware/library.py 中的完整签名为def install_new_embedding(self, embedding_model_nameNone, vector_dbNone, from_hfFalse, from_sentence_transformerFalse, modelNone, tokenizerNone, model_api_keyNone, vector_db_api_keyNone, batch_size500, max_lenNone, use_gpuTrue)其组件可交换的实现依据在 llmware/embeddings.pyEmbeddingHandler之下并排定义了十余个向量数据库适配器类每一个都实现同一套三接口——create_new_embedding(doc_ids, batch_size)、search_index(query_vector, sample_count)、delete_index()。适配器的实例化注册由 llmware/configs.py 第 474 行的VectorDBRegistry完成其文档字符串明确写着 Registry of supported Vector DBs, and the class module used to interface with the DB并支持通过LLMWareConfig.add_vector_db(db_name, vector_db_class, modulellmware.embeddings)追加自定义数据库。因此文档中~15 个独立嵌入示例、~10 种向量数据库的说法与源码中的适配器数量一致而具体可用列表应以LLMWareConfig.get_vector_db_list()的运行时返回为准。索引命名同样被源码约束generate_index_name(account_name, library_name, model_name, max_component_length19)将账户、库、模型名各截断至 19 个字符拼接为索引名这解释了不同向量数据库对名称长度限制下的兼容性取舍。2.5 检索Query的完整查询能力面文档给出的查询方法Query(library).query(query, query_typesemantic, result_count20)llmware/retrieval.py 中Query.__init__的签名值得注意——它同时接受embedding_model、embedding_model_name、vector_db、query_mode等参数意味着检索时可以直接指定用哪套嵌入 哪个向量库与建库时的安装口径一致def __init__(self, library, embedding_modelNone, tokenizerNone, vector_db_api_keyNone, query_idNone, from_hfFalse, from_sentence_transformerFalse, embedding_model_nameNone, save_historyTrue, query_modeNone, vector_dbNone, model_api_keyNone)统一入口query(query, query_typetext, result_count20, results_onlyTrue)之外Query暴露的方法面覆盖了文档~10 个检索示例所声称的全部技术文本系text_query支持exact_mode精确匹配、text_query_with_document_filter、text_query_with_custom_filter、text_query_by_content_type、text_search_by_page、text_query_by_author_or_speaker作者/演讲者检索语义系semantic_query支持embedding_distance_threshold距离阈值、semantic_query_with_document_filter、similar_blocks_embedding相似块召回混合与进阶dual_pass_query双通道混合查询primarytext或semantic含safety_check兜底、augment_qr、apply_semantic_ranking语义重排序、block_similarity_retrieval_more_like_this过滤与导出document_filter、filter_by_key_value_range、filter_by_time_stamp、bibliography_builder_from_qr从查询结果生成参考文献、export_all_tables/export_one_table_to_csv、aggregate_text查询历史save_query_state/load_query_state/clear_query_state/dump_current_query_state底层由 llmware/resources.py 第 4911 行的QueryState持久化对应文档查询历史/Query State能力。一个最小的语义查询示例与 solutions/sources/semantic_retrieval.py 等示例同构from llmware.retrieval import Query query_obj Query(library, embedding_model_nameall-MiniLM-L6-v2, vector_dbmilvus_lite) results query_obj.semantic_query(contract termination clause, result_count20, embedding_distance_threshold250)向量库与嵌入模型需先通过install_new_embedding安装到该 Library 才能用于检索。三、管线二Model PromptingFun with LLMs官方文档将模型提示管线定义为发现、实例化并配置一个基于 LLM 的模型以执行推理的完整生命周期包含八个环节ModelCatalog发现/加载/管理配置、Inference、Function Calls、Prompts、Prompt with Sources、Fact Checking、Agent-based 多步流程、Prompt History。对应核心类为ModelCatalogmodels 模块、Prompt、LLMfxagents 模块。3.1 ModelCatalog统一发现与加载模型文档给出的关键方法ModelCatalog().list_all_models() # 发现模型 model ModelCatalog().load_model(model_name) # 加载模型 response model.inference(prompt, add_contextcontext) # 推理llmware/models.py第 512 行起全文约 1.6 万行中的ModelCatalog类印证了这三个入口并提供远比文档更多的能力发现list_all_models、list_open_source_models、list_embedding_models、list_generative_models、list_generative_local_models、list_models_by_type(model_family)、list_function_call_models、model_lookup注册register_hf_generative_model、register_sentence_transformer_model、register_gguf_model、register_open_chat_model、register_ollama_model、setup_custom_llmware_inference_server以及register_new_model_card/add_model_cards_from_file自定义 manifest 批量导入加载load_model(selected_model, api_keyNone, use_gpuTrue, sampleTrue, get_logitsFalse, max_output100, temperature-99, force_reloadFalse, api_endpointNone, **kwargs)参数中的temperature-99为哨兵值表示沿用模型卡上的默认温度注册表持久化save_model_registry/load_model_registry默认文件名llmware_model_catalog.json以及 prompt wrapper 与 tokenizer 配置的独立存取。从源码结构看模型注册表的默认内容来自 llmware/model_configs.py约 4600 行中的三个全局常量与文档逐一对应global_model_repo_catalog_list第 25 行模型目录主列表global_model_finetuning_prompt_wrappers_lookup第 3936 行微调模型的提示词包装器查找表global_default_prompt_catalog第 4102 行默认提示词目录。文档称models 模块中暴露了约 17 个独立模型类。从源码结构看models.py中确实并排定义了十余个模型驱动类覆盖 Hugging Face 生成/嵌入/重排模型、GGUF 本地模型、GGUF 视觉模型、ONNX 生成/分类/重排、OpenVINO 生成/视觉、OpenAI/Anthropic/Gemini/Google、OpenChat、Ollama、Foundry 本地服务等每个类统一实现inference、stream、function_call、token_counter等方法族。文档的核心建议是大多数场景通过 ModelCatalog 这一高层接口工作以获得代码复用与模型可替换性而在很多管线中连 ModelCatalog 都不需要直接调用因为Prompt知识检索工作流和LLMfxAgent 与函数调用本身就构建在 ModelCatalog 之上。3.2 Prompt 类Prompt with Sources 与 Prompt History文档描述Prompt对模型类做了一层包装提供便捷的来源/检索管理能力。llmware/prompts.py第 44 行的Prompt类完整落实了这一点其__init__即可同时绑定llm_name、library、prompt_idPrompt(llm_nameyour model, librarylibrary, prompt_idsession-1)来源管理方法族对应Prompt with Sources环节add_source_new_query(library, query, query_typesemantic, result_count10)——直接把一次检索结果挂为来源add_source_query_results、add_source_library、add_source_wikipedia、add_source_website、add_source_yahoo_finance、add_source_document、add_source_last_interaction_stepreview_sources_summary/verify_source_materials_attached来源审查。推理与事实核查方法族对应 Fact Checking methods 环节prompt_with_source、prompt_main、prompt_from_catalog、number_or_none、yes_or_no、multiple_choice、xsummary、summarize_document、evidence_check_numbers、evidence_check_sources、evidence_comparison_stats、classify_not_found_response以及 llmware/prompts.py 中的FactChecker辅助类fact_checker_numbers、source_reviewer、token_comparison。Prompt History 环节由两组机制支撑Prompt内部的register_llm_inference/get_current_history/clear_history每次推理的交互记录以及 llmware/resources.py 中PromptState的持久化initiate_new_state_session、register_interaction、full_history、save_custom_state、generate_interaction_report支持按prompt_id恢复、跨会话追溯交互历史。3.3 LLMfx面向函数调用 SLIM 模型的 Agent 引擎文档描述LLMfx对模型类做包装服务于function-calling SLIM 模型的 Agent 流程。llmware/agents.py第 43 行的LLMfx类证实了这一分工其能力面包括工具加载load_tool、load_tool_list、unload_tool——把多个小型 SLIM 函数调用模型同时装进一个 Agent 工具箱函数调用执行exec_function_call、exec_multitool_function_call多工具并行调用高频分析原语的语法糖sentiment、topics、ner/named_entity_extraction、ratings、emotions、intent、tags、category、extract、xsum/summarize、boolean、nli、q_gen、qa_gen、verify_llm_response结构化数据操作sql(query, table_schema)Text-to-SQL、sql_checker、query_custom_table、query_db工作队列与报告load_work、show_report、activity_summary、write_to_journal支撑多步 Agent 的迭代追踪。Agent 多步流程的完整示例可参考 solutions/slim_agents/ 目录如 agents-1-start_here.py、text2sql-end-to-end-2.py与 solutions/rag/example-8-agents.py。四、支撑模块两条管线之下的抽象层文档明确列出了支撑两套管线的使能类与方法。逐一对应到当前仓库源码4.1 resources 模块llmware/resources.py文档表述在底层数据库仓库之上提供抽象层并为主要类提供独立的状态机制。源码中的对应组件CollectionRetrieval / CollectionWriter按llmware/mongodb/postgres/qdrant/sqlite等数据库分别实现的读写器每个实现同一方法面lookup、basic_query、filter_by_key、text_search_with_key_value_range、get_whole_collection、update_block、add_new_embedding_flag等这正是更换存储端点而不动上层的抽象层实体PromptState / QueryState / ParserState分别位于第 4911、4911 附近与第 4421 行为 Prompt、Query、Parser 三大类提供独立状态持久化CustomTables / 自定义表加载器load_csv、load_json、validate_csv、validate_json、build_table、insert_rows服务于文档步骤 7与 SQL 表及结构化内容结合以及LLMfx.sql的 Text-to-SQL 场景。4.2 其他支撑模块模块源码文档描述与实现对应configsllmware/configs.pyLLMWareConfig统一管理路径get_library_path/get_model_repo_path等、活动数据库get_active_db/set_active_db、向量库/表库注册VectorDBRegistry、日志级别各存储端点配置类MilvusConfig、MongoConfig、PostgresConfig、QdrantConfig、RedisConfig、PineconeConfig、LanceDBConfig、SQLiteConfig、ChromaDBConfig等均在此定义gguf_configsllmware/gguf_configs.pyGGUFConfigsctypes 声明、采样参数、llama/whisper 日志回调支撑 GGUF 本地推理端点model_configsllmware/model_configs.py三个全局注册表常量见 3.1 节是 ModelCatalog 的默认数据来源utilllmware/util.pyUtilities与一批工具TextChunker分块、exact_search_dicts/token_search_dicts/fast_search_dicts词典级搜索、get_top_bigrams/trigrams内容分析、file_checksum/compare_hash文件完整性、SecureFileName等setupllmware/setup.pySetup类load_sample_files、load_voice_sample_files、load_selected_sample_files快速示例中的样本文件入口exceptions定义于 llmware/configs.py 第 1236 行起LLMWareException基类及DependencyNotInstalledException、ModelNotFoundException、ConfigKeyException、ModuleNotFoundException、GGUFLibNotLoadedExceptionweb_servicesllmware/web_services.pyWikipediaget_article/search_wikipedia、YFinanceget_company_summary/get_financial_summary/get_stock_summary、WebSite网页抓取与图片落盘、LLMWareAPI远程推理服务端点客户端值得强调的是文档提到的Prompt.add_source_wikipedia/add_source_yahoo_finance/add_source_website三个来源方法正是调用 web_services 模块这三个类的证据——两条管线在此交汇摄入管线产出的 Library 与外部结构化服务都被 Prompt 的高层接口统一纳管。五、端到端串联与示例索引文档以End-to-End Use Cases收尾。当前仓库中可直接运行的端到端串联示例快速上手三步solutions/rag/example-1-create_first_library.py解析建库→ example-2-build_embeddings.py建嵌入→ example-3-prompts_and_models.py提示与模型其后是 example-4-rag-text-query.py 至 example-9-function-calls-with-web-services.py 的检索、Agent 与 Web Service 函数调用示例摄入侧深度示例solutions/sources/解析、OCR、表格抽取、过滤、引用生成如 bibliography.py、parse_pdf_by_ocr.py嵌入侧深度示例solutions/embeddings/约 15 个向量数据库/嵌入模型组合示例如 using_milvus_lite.py、using_neo4j.py;模型侧深度示例solutions/models/ 与 solutions/gguf/Ollama、OpenChat、GGUF 本地模型、采样设置调整等Agent 侧深度示例solutions/slim_agents/多模型、多步 SLIM Agent 流程完整业务用例solutions/use_cases/发票处理、MSA 处理、合同分析等。六、小结一张表读懂 LLMWare 组件映射能力环节高层类底层实现文件关键方法解析 分块 入库Library/Parserllmware/parsers.pyadd_files→Parser.ingest→ 各parse_*通道嵌入安装Library/EmbeddingHandlerllmware/embeddings.pyinstall_new_embedding→ 向量库适配器create_new_embedding检索Queryllmware/retrieval.pyquery/text_query/semantic_query/dual_pass_query模型发现与加载ModelCatalogllmware/models.pylist_all_models/load_model/register_*提示与来源管理Promptllmware/prompts.pyadd_source_*/prompt_with_source/ 事实核查方法族Agent 函数调用LLMfxllmware/agents.pyload_tool/exec_function_call/sql/ 分析原语存储与状态抽象CollectionRetrieval/*Statellmware/resources.py统一读写方法面 独立状态持久化配置与端点注册LLMWareConfig/VectorDBRegistryllmware/configs.pyset_active_db/add_vector_db/ 端点配置类外部结构化来源Wikipedia/YFinance/WebSitellmware/web_services.pyget_article/get_company_summary/ 网页抓取这套高层门面 注册表端点的分层是 LLMWare 架构最核心的工程决策业务管线始终面向Library、Query、ModelCatalog、Prompt、LLMfx五个稳定接口编程而解析通道、向量数据库、模型驱动这些高替换频率的组件被隔离在注册表之下的实现层中——这既是文档minimal, if any, code change承诺的源码级依据也是读者评估扩展点自定义向量库、自定义模型卡、自定义表时的落点。【免费下载链接】llmwareUnified framework for building enterprise RAG pipelines with small, specialized models项目地址: https://gitcode.com/GitHub_Trending/ll/llmware创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
