File size: 7,307 Bytes
69124d3 72ff992 e1cc40c 69124d3 bf642f0 69124d3 72ff992 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 |
---
library_name: peft
base_model: Locutusque/TinyMistral-248M-Instruct
datasets:
- Locutusque/InstructMix
language:
- en
pipeline_tag: text-generation
widget:
- text: >-
<|ASSISTANT|> Here is a possible solution to transform high haircare styling and trimming based on decision making for professionals incorporating `if`/`else` statements to handle different consent scenarios: 1. Define nodes and relationships for the graph database: ```cypher CREATE (client:Client) CREATE (stylist:Stylist)-[:HAS_CLIENT {start_date: date() }]->(client) // Relationship types used in this query MATCH (s:Service), (c:Client) WHERE s.name = 'Haircut' AND c IN [client] MERGE (s)<-[r:CONFIRMS_SERVICE]-(c); // Other relationship types could also be added here as needed ``` 2. Query to determine whether client has given their explicit consent to receive specific services: ```cypher // Get all services provided by stylists to clients MATCH (s:Stylist)-[r:PROVIDES_SERVICE*0..5]-(:Service) WITH collect(distinct s) AS stylists, r UNWIND stylists AS s OPTIONAL MATCH (c:Client)-[:HAS_CLIENT]->(sc:ServiceConsent{service:r}) RETURN s, count(*), sum(CASE WHEN sc IS NOT NULL THEN 1 ELSE 0 END) AS num_consents ORDER BY num_consents DESC; ``` 3. Example of how to use the above query to check which service a particular client has already agreed to: ```cypher // Check if client has previously granted consent to any services MATCH (s:Stylist)-[r:PROVIDES_SERVICE*0..5]-(:Service) WITH collect(distinct s) AS stylists, r UNWIND stylists AS s OPTIONAL MATCH (c:Client)-[:HAS_CLIENT]->(sc:ServiceConsent{service:r}) WHERE id(c) = <id of client> RETURN s, count(*), sum(CASE WHEN sc IS NOT NULL THEN 1 ELSE 0 END) AS num_consents; ``` 4. Code to add new consent for a new service: ```cypher // Add new consent for a new service MERGE (c:Client {id: '<id of client>'}) ON CREATE SET c.created_at=timestamp(), c.updated_at=timestamp() MERGE (s:Service {name: '<new service name>'}) ON CREATE SET s.created_at=timestamp(), s.updated_at=timestamp() MERGE (c)-[:GIVEN_SERVICE_CONSENT {consent_given: true}]->(sc:ServiceConsent {service: s}); ``` 5. Code to update existing consent for an existing service: ```cypher // Update existing consent for an existing service MATCH (c:Client {id: '<id of client>'}), (s:Service {name: '<existing service name>'}) MERGE (c)-[:GIVEN_SERVICE_CONSENT {consent_given: false}]->(oldSc:ServiceConsent) MERGE (c)-[:GIVEN_SERVICE_CONSENT {consent_given: true}]->(newSc:ServiceConsent {service: s}); DELETE oldSc; ``` 6. Code to delete consent for a service: ```cypher // Delete consent for a service MATCH (c:Client {id: '<id of client>'}), (s:Service {name: '<service name>'}) REMOVE (c)-[:GIVEN_SERVICE_CONSENT {consent_given: true}]->(sc:ServiceConsent {service: s}); ``` This approach usesNeo4j's native cypher language to define the database schema and perform queries and mutations on the graph. <|USER|>
inference:
parameters:
temperature: 0.8
do_sample: True
top_p: 0.14
top_k: 41
max_new_tokens: 250
repetition_penalty: 1.176
---
## Uses
This model is intended to be used to create instruction-following datasets by predicting a question by passing an answer to it.
### Out-of-Scope Use
<!-- This section addresses misuse, malicious use, and uses that the model will not work well for. -->
[More Information Needed]
## Bias, Risks, and Limitations
<!-- This section is meant to convey both technical and sociotechnical limitations. -->
[More Information Needed]
### Recommendations
<!-- This section is meant to convey recommendations with respect to the bias, risk, and technical limitations. -->
Users (both direct and downstream) should be made aware of the risks, biases and limitations of the model. More information needed for further recommendations.
## Training Details
### Training Data
<!-- This should link to a Dataset Card, perhaps with a short stub of information on what the training data is all about as well as documentation related to data pre-processing or additional filtering. -->
[More Information Needed]
### Training Procedure
<!-- This relates heavily to the Technical Specifications. Content here should link to that section when it is relevant to the training procedure. -->
#### Preprocessing [optional]
[More Information Needed]
#### Training Hyperparameters
- **Training regime:** [More Information Needed] <!--fp32, fp16 mixed precision, bf16 mixed precision, bf16 non-mixed precision, fp16 non-mixed precision, fp8 mixed precision -->
#### Speeds, Sizes, Times [optional]
<!-- This section provides information about throughput, start/end time, checkpoint size if relevant, etc. -->
[More Information Needed]
## Evaluation
<!-- This section describes the evaluation protocols and provides the results. -->
### Testing Data, Factors & Metrics
#### Testing Data
<!-- This should link to a Dataset Card if possible. -->
[More Information Needed]
#### Factors
<!-- These are the things the evaluation is disaggregating by, e.g., subpopulations or domains. -->
[More Information Needed]
#### Metrics
<!-- These are the evaluation metrics being used, ideally with a description of why. -->
[More Information Needed]
### Results
[More Information Needed]
#### Summary
## Model Examination [optional]
<!-- Relevant interpretability work for the model goes here -->
[More Information Needed]
## Environmental Impact
<!-- Total emissions (in grams of CO2eq) and additional considerations, such as electricity usage, go here. Edit the suggested text below accordingly -->
Carbon emissions can be estimated using the [Machine Learning Impact calculator](https://mlco2.github.io/impact#compute) presented in [Lacoste et al. (2019)](https://arxiv.org/abs/1910.09700).
- **Hardware Type:** [More Information Needed]
- **Hours used:** [More Information Needed]
- **Cloud Provider:** [More Information Needed]
- **Compute Region:** [More Information Needed]
- **Carbon Emitted:** [More Information Needed]
## Technical Specifications [optional]
### Model Architecture and Objective
[More Information Needed]
### Compute Infrastructure
[More Information Needed]
#### Hardware
[More Information Needed]
#### Software
[More Information Needed]
## Citation [optional]
<!-- If there is a paper or blog post introducing the model, the APA and Bibtex information for that should go in this section. -->
**BibTeX:**
[More Information Needed]
**APA:**
[More Information Needed]
## Glossary [optional]
<!-- If relevant, include terms and calculations in this section that can help readers understand the model or model card. -->
[More Information Needed]
## More Information [optional]
[More Information Needed]
## Model Card Authors [optional]
[More Information Needed]
## Model Card Contact
[More Information Needed]
## Training procedure
The following `bitsandbytes` quantization config was used during training:
- quant_method: QuantizationMethod.BITS_AND_BYTES
- load_in_8bit: False
- load_in_4bit: True
- llm_int8_threshold: 6.0
- llm_int8_skip_modules: None
- llm_int8_enable_fp32_cpu_offload: False
- llm_int8_has_fp16_weight: False
- bnb_4bit_quant_type: nf4
- bnb_4bit_use_double_quant: False
- bnb_4bit_compute_dtype: float16
### Framework versions
- PEFT 0.6.2 |